Чтобы стать популярным в околокомпьютерном "сообществе" (ну какое это сообщество, на самом-то деле?), достаточно неожиданно выскочить на любого зазевавшегося пользователя и громко закричать "Патенты!!!" 

(варианты беспроигрышных криков - "Империя Зла!", "Функциональное Программирование Рулит!", "Экстемальное Программирование Рулит!", "Кругом Руткиты!!!", "Проблема 2xxx Года!", etc).

И это действительно действует. Потому что "людина завжди цікавилася трьома речами. По-перше - своїм калом, по-друге - питками та казнями, і уродами. Дайте їй все це, і вона буде відчувать, шо живе не напрасно" ( © живой классик).

Ну а если всё-таки задуматься?

Да, - количество патентов, идентифицируемых методом поиска Бессена-Ханта как "программные", растёт:

(красная линия - всего патентов, малиновая - опознанных с помощью метода поиска Бассена-Ханта)

Но.

Или даже не так.

И?

Во-первых, - растёт и количество патентов вообще.

Во-вторых, - несмотря на всевозможные опасения, традиционная патентная система худо-бедно, но справляется с ситуацией, не допуская развития апокалиптических сюжетов (например, - требования отчислений от всех разработчиков ПО, использующих запатентованный "связный список").

И о чём это говорит?

Мне пока очевидно одно - производство программного обеспечения давно перестало быть чистым искусством (да и, по сути, никогда им не было, поэтому все сравнения программирования с мирами "высокой моды" и прочими сугубо творческими, индивидуалистскими системами порождения артефактов - чепуха), и уже давно является инженерией. Да. Нравится вам (мне) это, не нравится ли, - это факт. А в инженерии давно уже "утряслись" отношения между правообладателем ("головой") и производителем ("руками"). И, кстати, весьма разумно "утряслись" - в противном случае мы бы не видели и десятой доли того материального, что сегодня нам доступно. Кстати, - эти отношения далеко не так просты, как многим кажется. Вот, например, - свежайшее из серии "лучшие практики", написанное инженером для инженеров - "Наброски бриллиантовой идеи на салфетке", самый первый пункт:

"Принятие решения о раннем патентовании может оказаться дорогостоящей ошибкой..."

Между прочим, - это тоже одно из множества правил сосуществования правообладателя и производителя, работающее, что очевидно, вовсе не в пользу столь ненавидимого правообладателя.

Второе очевидное соображение - раз речь идёт об индустрии, значит, работают все инженерные правила. В том числе и дуализмы. А программа и аппаратные средства - дуальны: любую программу принципиально возможно реализовать "в железе", любое "железо" принципиально возможно имитировать программно. Соотвественно, в виду эквивалентности, раз есть патентное право на аппаратные средства, должно быть и патентное право на дуальные им программные. Никак иначе не получается.

Третье же моё соображние неочевидно и малоприятно. Оно зиждется на фундаментальной разнице между "программированием" (разработкой ПО) и "кодированием" (реализацией ПО на основе созданных сторонними разработчиками допускающих реализацию спецификаций). Я запасаюсь смелостью и утверждаю: создание спецификаций - очень дорогой процесс. Если бы это соображение было ложным, мы бы имели не движение open source (в основе которого - явно и неоднократно выраженная идея повторной реализации спецификаций POSIX), а движение open specifications. Но последних-то, открытых спецификаций, как раз, - кот наплакал, а к сугубо "открытым" (то есть. - создававшимся как открытые), проектам я бы отнёс разве что японский Tron.

Так вот, - вопрос взаимоотношений между правообладателем и open source кодировщиками - вопрос очень больной и пока безответный.

Поставьте себя на место правообладателя X: вы наняли лучших дизайнеров для создания интерфейса вашей будущей программы Y, задействовали три десятка высокооплачиваемых специалистов из нескольких стран для отработки эргономики программы, сформировали структуру, анализирующую реакцию потенциальных потребителей на ещё не существующий интерфейс на потенциальных рынках, etc. Всё это - деньги и время. Причём - немалые деньги и много времени. И вот, после выхода вашей программы на рынок, кодировщики, вооружённые "экранными линейками" и утилитами склёвывания цветов, за две недели удовольствия ради настучали нечто, на удивление похожее на выстраданное вами. Вам это понравится и вы сочтёте это законным? Очень сомневаюсь.

Вот ещё один пример - лицензионное соглашение на... систему команд нового семейства процессоров ARM - Cortex. ARM - компания, "живущая" не с производства материальных кристаллов, а с отчислений за интеллектуальную собственность, которой являются пригодные к синтезу описания процессоров. Иными словами, - со спецификаций, пригодных для кодирования настолько, что процесс кодирования может быть автоматизирован (и он автоматизирован на самом деле).

Так кто вправе осудить ARM за пункт лицензионного соглашения 2.ii, запрещающий использовать спецификации системы команд для разработки моделей процессоров?

Для меня очевидно следующее:  хотите конкурировать с ARM - создавайте свою архитектуру, добивайтесь её признания производителями и разработчиками ПО, но не занимайтесь кодированием спецификаций, созданных ARM.

Крупнейший репозиторий и набор сервисов для разработчиков программного обеспечения с открытыми исходными текстами, SourceForge, провёл очередное голосование среди участников сообщества для выявления лучших проектов.

Примечательно даже не то, что в лидеры попали программы для платформы Windows. И даже не то, - какие именно программы, это-то  как раз вовсе и не примечательно, потому что и архиватор 7-Zip, и "запускалка" Launchy (в каком-то смысле аналог QuickSilver из мира MacOS X и нового меню Start из Windows Vista), в дополнительных рекомендациях и представлениях не нуждаются (я сам к Launchy давно привык, и от этой привычки не избавило даже появление Vistart - точного аналога великолепного Start-меню Vista). Примечательно же то, что и 7-Zip, и Launchy - проекты не кросс-платформенные, а "чисто Windows", при этом активно живущие и даже развивающиеся (хотя, казалось бы, куда уже развиваться 7-Zip...).

И просто как по заказу, практически синхронно, Microsoft открыла... open source раздел корпоративного сайта. Ответов на часто задаваемые вопросы (ну мы же помним, что RTFM, RTFM и ещё раз - RTFM!) и самих вопросов здесь немного, но они заслуживают внимания.

"Open source - вовсе ни прихоть индустрии, ни серебряная пуля. Методы разработки, обычно объединяемые термином "open source",  дают и потребителям, и разработчикам некоторые дополнительные ко многим доступным в разных технологических экосистемах, возможности...

750 тысяч партнёров (Microsoft) во всём мире... зарабатывают суммарно $8 на каждый заработанный Microsoft $1...

...более 79 тысяч open source приложений создано разработчиками для платформы Windows (репозитории SourceForge и CodePlex)..."

Что же происходит? 

Очевидно, что огромная пользовательская база ОС семейства Windows представляет не только интерес для амбициозных разработчиков, но и даёт возможность прямо зарабатывать авторитет, а, косвенно,  - и деньги, - на популярности своих бесплатных open source программ. Также очевидно, что битва за десктоп существует разве что в отдельных горячих головах - на деле же это не битва, а затянувшаяся возня с сезонными обострениями (я не выдумываю - почитайте "исповедь" автора популярных "настольных" пачей ядра Linux Кона Коливаса "Почему я ушёл", и это только одна сторона медали). Соотвественно, - свято место пусто не бывает, и для разработчиков open source ПО "настольного" характера платформа Windows неизбежно будет становиться всё более интересной. Платформы *nix, в свою очередь, будут неизменно популярны среди разработчиков системного ПО и сервисных (серверных) программ - это видно уже сейчас, по голосованию на SourceForge.

Кстати, я лично с удовольствием проголосовал бы за (кроме Launchy) виртуальный десктоп для Windows - VirtuaWin, программу стабильно развивающуюся (особенно приятно, что разработчики быстро реагируют на сообщения об ошибках и с каждой новой версией программа работает всё лучше и лучше) и очень неплохо делающую то, что она должна делать. И ещё - за менеджер системного буфера обмена, Ditto - это также образцовая open source программа, без которой трудно обойтись.

У операционных систем Oberon и Plan 9 есть одна очень важная общая черта - их пользовательский интерфейс строится на модели "любой фрагмент текста может трактоваться как множество команд". Для реализации этой модели было использовано сквозное проектирование (всей системы - в случае Oberon, текстового пользовательского окружения Acme - в случае Plan9).

Мне трудно ответить на вопрос - всем ли пользователям нужна такая возможность, и насколько часто она нужна. Зато я точно знаю, что программистам такая возможность необходима.

Теперь, благодаря стараниям Леона Бамбрика (Leon Bambrick) и идеям Дона Сайма (Don Syme), все пользователи Visual Studio получили доступ к этой "фишке" двух замечательных систем из совсем другого мира.

Итак, -

• если вы используете VS 2005, - распакуйте в каталог "C:\Documents and Settings\{Your Username}\My Documents\Visual Studio 2005\Addins" содержимое этого файла (если указанного каталога на вашей машине нет, - создайте его самостоятельно);
• если вы используете VS 2003, - инсталлируйте это приложение.

Собственно, - всё. Теперь вы можете выделять любой фрагмент кода и одной клавишей передавать его на исполнение!

Я беззастенчиво утянул с сайта Бамбрика эту анимированную картинку только потому, что идея утилиты Exec-Inline мне понравилась сразу, это любовь с первого взгляда, а ближайшая инсталляция Visual Studio - дома, так что не вытерпел:

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

На всякий случай - все ссылки на связанные с утилитой ресурсы (в обратном хронологическом порядке):

анонс версии для VS 2005;

анонс версии для VS 2003;

анимированный скриншот и краткое описание принципа работы.

Замечательная штучка, просто замечательная!

Сейчас модно говорить о том, что не нужно знать техническому специалисту. И раз уже и математику записали в список ненужностей для программистов, автора следующей цитаты придётся указать явно - Плутарх (древнегреческий мыслитель, 46-120 гг. н.э.):

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

Несколько неожиданное начало, не правда ли? То ли ещё будет...

Предположим, что вам показали следующий фрагмент кода:

00  if (условие_1)
01        goto got_lock;
02  if (условие_2) { /* тело блока */ }
03  got_lock: функция_1();

и спросили, - можно ли избавиться в этом фрагменте кода от goto?

Что бы вы ответили, точнее, - не что, а как бы вы стали отвечать на такой вопрос?

Мне кажется естественным, что ответ на него во многом зависит от кода, находящегося за пределами фрагмента - вполне возможно, что goto здесь совершенно логичен и даже полезен. В конце концов, классики времён структурного программирования боролись не с самим оператором goto, а с бесконтрольным и тотальным его использованием.

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

Так в чьей голове мог зародиться такой ответ на совершенно невинный вопрос:

"Вам промыли мозги люди из CS (Computer Science), которые думают, что Никлас Вирт действительно знает, о чём говорит. А он не знает. У него нет никаких (beep) знаний".

Знаете в чьей?

Линуса Торвальдса.

Я же предупреждал, - заготавливайте минусы для этой заметки.

Вот ветка обсуждения "Using goto in Kernel Code", в которой, собственно, эта фраза и прозвучала (второй ответ Торвальдса). Прочитайте-прочитайте, а выводы делайте сами.

Я своих выводов не скажу, я Плутарха лучше перечитаю в очередной раз.

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

Хороший пример, - "новое" пользовательское рабочее окружение (десктоп, если хотите) Pyro.

Начнём с того, что новизны в нём, уж извините, но - кот наплакал.

Потому что вот эти диалоги в ОС Windows на моей памяти были и в старом добром "винтукее" (а то и раньше, просто с более ранними Windows я дела не имел, поэтому гадать не буду):

Пару раз для развлечения я сам такое делал - создавал десктоп из настроенной персонализированной страницы одного из развитых web-сервисов. И тут же от этой "продвинутости" отказывался ввиду бессмысленности и неудобства.

Правда, разработчики Pyro пошли дальше обычного Active Desktop, добполнив и без того не очень востребованную идею (не видел ни разу, чтобы кто-то реально использовал возможности диалогов с приведенного выше снимка экрана) совершенно гениальными решениями. Например, - отрисовкой окон приложений... фактически средствами лежащего в основе Pyro браузера (это Firefox). Если быть точным, то Pyro десктоп создаёт DOM-описание настольного окружения с окнами работающих приложений и "отдаёт" его браузеру для отображения.

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

В общем, в блоге разработчика Pyro совершенно прекрасен первый же комментарий (некоего Peter) к анонсу изделия:

Oh boy! A window manager which leaks more memory than metacity! :D

Ох, парень! Наконец-то оконный менеджер, жрущий больше памяти, чем metacity! :D

По моему мнению эта курьёзная поделка не заслуживает более серьёзного обсуждения, но злые блоггеры и мелочами кормятся, и вот ещё одно мнение, которое я во многом разделяю - "Оставьте web в браузере!". Кстати, - да, оставьте!. И пользователей в покое - тоже. А то только лопнул мыльный пузырь "всеобщих тонких компьютеров", как началась новая волна - web2.0-приложений.

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

Итак, - Burrogh. Конечно, - знаменитый Барроус, один из первых серьёзных западных производителей вычислительных систем, оборудование которых поставлялось в СССР официально, а не чёрным импортом, через третьи страны, сквозь кордоны CoCom (было такое образование во времена [пред?]последней холодной войны).

Модель 5000. Машина, специально созданная для поддержки на аппаратном уровне ПО, созданного я языках высокого уровня - Algol и Cobol тогда уже были, и по сей день кажутся далеко не такими плохими языками.

Особенности архитектуры центрального процессора: вместо регистрового банка - аппаратно реализованный стек, с доступными для каждой команды вершиной и лежащей под ней ячейкой, причём как ячейками длиной в слово, так и двойными, - для команд расширенной точности. Посдсистема памяти также преподносит сюрприз - каждое машинное слово B5000 сопровождалось группой из трёх битов - меткой слова (word tag), определяющей класс, к которому относится это слово. Например, - для кодов команд был свой класс, при этом на аппаратном уровне как коды программы были защищены от модификаций, так и было запрещено передавать управление на блоки данных.Три бита позволяли описать восемь классов слов, - и кроме "кода", к этим классам относились данные одиночной и двойной точности, а также специальные "управляющие коды", например, вынесенные в отдельный класс команды манипуляции аппаратным стеком. Метки слов, используемые как модификаторы команд, позволили реализовать самоконфигурирующиеся машинные команды, то есть, - единая команда ADD определяла классы своих операндов (например, один из них - число с одинарной точностью, второй - с двойной) и затем уже выполнялась. Забавно, что использование меток слов приводило всего к 6%  перерасхода оперативной памяти (исключительно дорогой в те времена), - сегодня 6% от 1GB,  составляющие прримерно 64 MB, стоят сущие гроши (центы?).

Но главной архитектурной особенностью машины было то решение архитекторов Барроус, из-за которого машина получила кодовое название "The Descriptor". Дексриптор - специальная команда, обеспечивающая аппаратно поддержанный (!) механизм доступа к областям памяти с автоматической проверкой невыхода за границы доступа и битовой меткой, индицирующей факт загрузки области памяти в ОЗУ. Иными словами, - фактически с аппаратной поддержкой оверлеев и... виртуальной памяти.

Изюминок у B5000 было немало. Чего стоит, например, машинная команда завершённой транзакции "чтение-запись слова данных", облегчающая реализацию семафоров в многозадачных приложениях, Барроус даже продумал интерфейс к этой команде (и сопутствующим) из языков высокого уровня - тип данных "событие" (event) и генерируемые по требованию программиста программные прерывания. А машинная команда... итератора связных списков LLLU (Linked List LookUp), также поддержанная аппаратно?

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

Конечно, - виноваты в этом масоны, потому что они виноваты вообще во всём.

Шучу.

Одна из главных причин - в стековых машинах очень трудно реализовать развитые механизмы оптимизации потока вычислений, доступные разработчикам регистровых архитектур (исполнение out of order и проч.). Соответственно, - как только достигается предел тактовой частоты, возникают нюансы с производительностью.

Правда, физические стековые машины так и не достигли предела тактовой частоты.

Вторая причина как раз заключается в том, что разработчики последующих стековых машин забыли опыт Барроус и пытались создавать стековые процессоры, а не полноценные архитектуры, - а это две большие разницы.

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

Этим стулом мастер Гамбс начинает новую партию мебели. Да. Итак, начинаем потихоньку о Ruby.

""Вскоре после того, как я впервые столкнулся с компьютерами в начале 80-х годов, я стал интересоваться языками программирования. С тех пор я стал "языковым гиком" (я бы переводил это слово как "шизанутый фанат", АЗ).

В 1993 году... я не был удовлетворён возможностями существующих (скриптовых) языков, таких как Perl или Python. Я не мог отыскать идеального языка, поэтому решил создать свой.

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

Поэтому, при проектировании Ruby, оринетированного на использование человеком языка программирования (human-oriented language), я следовал принципу Минимума Сюрпризов. Я считаю, что всё, что не является для меня сюрпризом (то есть, - неожиданностью, и не всегда приятной, АЗ) - это неплохо. В результате пользования этим принципом, мне удалось придать языковым конструкциям ощущение естественноcти от программирования на Ruby, даже ощущение радости от этого занятия. Многие программисты всего мира подтверждают справедливость этого моего утверждения.""

Юкихиро "Матц" Матсумото

автор Ruby

001. Установка

Пока обойдёмся без лишних вопросов, ограничимся готовыми ответами. Инсталлируем Ruby из бинарного файла (если для Windows) или собираем (из портов) - если для *nix. Так как в *nix все эти мелкие детали должны быть тривиальными для пользователя (иначе зачем он вообще пользует *nix), я их даже не буду касаться.

После установки в Windows бинарного дистрибутива вроде получается всё что нужно и как нужно (не зря он называется "инсталлятор одним кликом"). Но. Изучать язык лучше в интерактивном режиме - это очевидно. И Ruby располагает всем необходимым для полноценной интерактивной работы - таким себе собственным шеллом. Если вы установили Ruby, например, в каталог C:/ruby, то полное путевое имя файла этого шелла будет следующим: c:\ruby\bin\irb.bat. Пока не будем заглядывать в его содержимое (там всего несколько строк).

Я бы посоветовал запускать irb в ConEmu (несколько слов об этой программке было сказано в ранней записи блога). Причём делать это так: тырцнуть в иконку в левом верхнем углу ConEmu, выбрать Settings.

Появится окно настроек консоли.

В нём нам действительно важно прописать командную строку  того, что будет запущено при запуске ConEmu. В поле Command Line надо поместить следующее: C:\ruby\bin\irb.bat -r irb/completion
Можно (я бы сказал и нужно) выбрать шрифт Consolas, размер 14x0 - но это на любителя.
После этого жмём кнопку "сохранить установки" (save settings), и можно считать рабочее место минимально подготовленным к изучению Ruby.

Что мы сделали?
При запуске ConEmu программа передаёт cmd.exe указанную нами командную строку, соотвественно, - запускается интерпретатор Ruby в режиме интерактивного шелла. При втором (после конфигурирования) и последующих запусках CmdExe мы получим в своё распоряжение Ruby-шелл. Но в командной строке есть ещё какие-то параметры. Они указывают шеллу, что мы инициируем механизм автодополнения.

Теперь сразу опробуем и шелл вообще, и механизм автодополнения.
Введём арифметическое выражение 1+2 и нажмём Enter. Интерпретатор ответил результатом сложения - очень хорошо, никаких сюрпризов.

А теперь попробуем понять, что такое эта самая цифра "три" в Ruby. Введём два символа 3. и дважды нажмём Tab - интерпретатор расскажет нам всё о том, что цифра 3 позволяет делать с собой. Иными словами - мы получаем перечень методов, которыми обладает объект "цифра" в Ruby.

Механизм автодополнения работает и с именами методов, например, если ввести 3.to_ и дважды нажать Tab, получится более короткий список имён методов, имена которых начинаются с подстроки "to_".

Теперь попробуем вполне очевидную по названию команду (принцип Минимума Сюрпризов!) to_s, в имени которой угадывается "в строку" (to string) - набираем 3.to_s, жмём Enter, убеждаемся, что результат похож на строку, содержащую один символ "3".

Итак, командная среда irb позволяет нам ориентироваться в системе методов объектов аналогично тому, как обычные командные оболочки позволяют ориентироваться в файловой системе. Это первый очевидный вывод.

Второй вывод менее очевиден. Мы только что имели дело с цифрой три. С литералом. Или, если хотите, - просто со значением. Не присвоенным никакой переменной с типом "число", не помещённой ни в какой типизованный "контейнер". И, между тем, у объекта "цифра три"  есть свои методы. Целая куча. Это главная особенность Ruby как объектно-ориентированного скриптового языка - тип (как множество операций, допустимых для данного объекта) является частью самого объекта, а не переменных.

Следующий выпуск серии - в четверг. так и будем писать-читать по два выпуска в неделю, до тех пор, пока не сравняемся, - тогда интервалы выхода выпусков будут увеличены.

До встреч в эфире,
АЗ

Об этом уже и говорить как-то неудобно, после финансовых перипетий компании Xybernaut. О wearable-компьютерах. То есть, - компьютерах настолько персонализованных, что их носитель не расстаётся с ними в идеале никогда.

Итак, с одной стороны, имеем:

• единственный серьёзный производитель wearable-компьютеров, компания Xybernaut, чудом и не без скандала избежала банкротства;
• ресурс по wearable-компьютерам Массачусетского технологического не обновлялся с 2005 года.

С другой стороны, -

• розничная стоимость компонента, некогда считавшегося ключевым элемента wearable-компьютера, микродисплея, упала ниже отметки $100;
• микроконтроллеры с ядром ARM, с маленьким энергопотреблением, с приличной тактовой частотой, и в копеечном ценовом диапазоне, сегодня не выпускает только ленивый;
• стоимость энергонезависимой памяти (flash) также резко упала, а такая память носимому персональному компьютеру просто необходима.

В результате же никаких wearable-компьютеров не существует. За исключением разве что настоящих курьёзов и устройств более чем сомнительной полезности (особенно при учёте цены).

В чём же дело?

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

Вот, например, хорошая идея "глоггинга" - непрерывной видео-фиксации всего, попадающего в поле зрения носителя wearable-компьютера. Кстати, глоггеры уже есть, и даже делятся своими "глогами". Пока это даже ещё не идея, а так, - зародыш. Но если добавить к ней позиционную информацию, высокоуровненвые сервисы типа Google Maps, мониторинг физического состояния носителя, мониторинг бесконтактного информационного поля (например, ZigBee-сигналов от других носителей или вообще ZigBee-меток, встроенных в объекты, - представьте себе картину в музее, в которую посетители могут сбрасывать свои впечателения, цитаты, и знакомиться с оставленным другими посетителями "наследием"), и ещё Бог знает что - ведь получится очень интересная штука. А программы интерактивного распознавания слитного текста, когда машинка в случае нечёткого распознавания слова переспрашивает носителя? А средства распознавания жестов, которые можно использовать вместо клавиатур и указательных устройств? А уличные беспроводные "доски объявлений", в которых можно оставить сообщение всем, желающим прочитать их содержимое - я не знаю, зачем всё это может быть нужно, но пока такого нет, никто так и не узнает, зачем.

Вот чего, по-моему, не нужно wearable-компьютеру, так это:

• многооконной графической подсистемы;
• сложной операционной системы;
• разнообразия встроенных инструментальных средств, носимый компьютер - устройство для удобного запоминания макрокоманд для повторяющихся действий носителя, не более того.

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

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

Соревнование в этом году называется Mobile Rules! и состоит из двух "забегов". В первом будут соревноваться разработчики (программисты), создающие для платформы Nokia приложения, относящиеся к четырём классам:

1. многопользовательские игры и игры с подключением к централизованным сервисам (connected games);
2. мультимедийные приложения;
3. корпоративные задачи;
4. infotainment (информационно-развлекательные приложения).

Во втором забеге участвуют бизнесмены, стартапы и академические институты. И соревнуются здесь не продуктами, а бизнес-планами.

Призы скромны - миллионов никто не обещает, из материального в их перечне - разве что мобильные устройства производства Nokiа.

Зато победители получают возможность использовать ресурсы Nokia в продвижении своих программ и идей, а вот это уже дорогого стоит.