суббота, 30 июня 2007 г.

RoboCup 2007

C 1 по 10 июля этого года в Атланте пройдет очередной чемпионат роботов RoboCup 2007. В этом году на ряду с роботами футболистами, роботами спасателями и домашними роботами будут выступать роботы размер которых исчисляется микрометрами.
Интересно, что как замечают сами устроители выставки, все большую и большую роль в усепшном поведении роботов играет не механика и не электроника, а программные мозги роботов. Подчеркивается, что некоторые команды вообще практически не меняют аппаратную начинку своих железных друзей, совершенствуя лишь ПО.

Как уже отмечалось выше изюминкой данного чемпионата в этом году станут роботы размером в несколько микрон. Интересно, что эти роботы были произведены по технологии MEMS(wiki), эта же технология легла в основу ранее описанного микро пьезогенератора. MEMS робот и комар
По сути дела MEMS это часть того что у нас называют нанотехнологиями. MEMS - интеграция продуктов механики и электроники на кристалле размеры, которого имеют порядок 10-6 метра и выше (т.е. до "нано" не дотягивает). Наиболее широко MEMS применяется при производстве сенсоров. Пример такого MEMS-робота вы можете видеть на рисунке (с ним рядом пристроилось какое-то насекомое, комар, вроде бы :) ) Примеры других микророботов показаны здесь.
Полный список стран участников представлен здесь. Присутствуют команды из Ирана, Чили, Китая..., обидно - наших нет. Насколько я понимаю некоторым аналогом RoboCup в России является фестиваль "Мобильные роботы", проводимый МГУ.

"Виброток"

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

Пьезоэлектричество известно уже достаточно давно, однако для его успешного применения требуется преодолеть ряд проблем (в частности проблему резонанса пьезоэлемента - в момент резонанса продуцируемая мощность возрастает в 200 раз), что и было успешно сделано в Нидерландах. Тем более интересно, как точно была выбрана область применения для разработанного источника питания - питание беспроводных микродатчиков. Примерами таких датчиков могут служить сенсоры в крадиостимуляторах, авиационных двигателях, а также других встроенных системах малого масштаба.
Новый источник питания продуцирует мощность в 40 микроватт при частоте 1.8 КГц, что вполне достаточно для питания беспроводных сенсоров. Интересно, что общим направлением исследований IMEC Holst Centre является создание электрогенераторов превращающих градиент окр.среды любой физической природы в электрический ток.

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

пятница, 29 июня 2007 г.

Intel. Блог новый, проблемы теже

В семействе блогов Intel пополнение - появился новый блог http://blogs.intel.com/research/. Новый блог наряду с ISN blog(Intel Software Network) создает хорошее с точки зрения программиста впечатление о компании... не такое hardware-ное что ли :)

И что же вы думали, в одном из первых сообщений этого блога вновь поднимается проблема распространения многоядерных процессоров и слабой поддержки их со стороны программистов.
Я имею ввиду заметку Али-Реза Адл-Табатабаи (Ali-Reza Adl-Tabatabai,Senior Principal Engineer in Intel’s Programming Systems Lab), которая так и называется - "Многоядерные процессоры: переломный момент для программирования". Думаю ничего нового читатели моего блога в этом сообщении не найдут - почти все сообщения от разнообразных авторов и мои собственные замечания посвящены этой теме. Поэтому тезисно -

  1. Раньше программист писал программу, а каждые 18 месяцев она работала почти вдвое быстрее (закон Мура). Больше такого не будет. Грубо говоря, если программист хочет, чтобы его программа работала быстрее на новом процессоре, то он должен разрабатывать её в параллельном (и масштабируемом) стиле.

  2. Современные языки программирования для решения задачи 1 не годятся. Они позволяют лишь использовать многопоточные библиотеки. Потоки по сути дела являются современными аналогами "goto".

  3. Для решения задачи 1 нужны высокоуровневые языки программирования с поддержкой параллелизма.

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


Продолжает эту тему пост Тимоти Маттсона(Timothy Mattson), озаглавленный как "Параллельные вычисления: сделаем последовательное ПО исчезающей редкостью". Маттсона, которому по работе приходится встречаться с различными группами разработчиков, занимающихся вопросами параллельного программирования, раздражает, что с аппаратчиками он может обсуждать конкретные проекты и понятные четко определенные, практические проблемы. Он говорит, что они буквально смакуют решения тех или иных проблем (we are sweating the details). Когда же он работает с программистами, то все тухло... Вместо конкретики они вынуждены барахтаться в хаосе. Причинами такого положения дел по мнению Маттсона являются следующие нерешенные вопросы:

  1. Нужны ли новые языки программирования? Или достаточно каким-то образом расширить существующие языки?
    [от себя добавлю, что, например, Эдвард Ли предлагает альтернативное этим двум подходам решение - создание нового языка программирования, который бы не заменял старые языки, распространенные сейчас, а был бы ортогонален им. Такой язык не был бы универсальным, а наоборот был призван дополнить существующий язык, оставаясь независимым от него, подробнее здесь, стр 14.]

  2. Способны ли языки, с поддержкой распараллеливания по данным (data parallel programming languages) удовлетворить потребности прикладных программистов? Удобны ли и понятны ли такие языки прикладных программистам, или же для них это очередной HPF (High Performance Fortran)?

  3. Любой масштабируемый параллельный код основан на посылке сообщений... или на общей памяти с которой работают в стиле посылки сообщений. Можем ли мы сделать посылку сообщений частью мейнстрима? Или же это слишком сложно для не HPC-программистов (HPC-High Performance Computing)?

  4. Фреймворки подобные Visual Basic значительно упростили создание прикладного ПО. Может ли мы использовать подобный, framework-based подход в параллельном программировании?

  5. Каким образом мы можем научить программистов "думать параллельно", решать задачи в параллельном стиле?

PRAM. Немного подробностей

На этой, уже подходящей к концу, неделе про многоядерность и параллельное программирование говорили часто и много (не все к сожалению удалось осветить в блоге). Тем кого заинтересовало сообщение о "многопроцессорном чуде" из Мирланда советую прочитать комментарий Clay Breshears на ISN. В кратце он критически оценивает подход Узи Вишкина к параллельному программированию. Как мы уже знаем, Узи большой поклонник PRAM-подхода. В дополнении к статье на Вики, Clay Breshears отлично объясняет сущность PRAM - по сути PRAM это абстракция, которую в нашей литературе называют концепцией неограниченного параллелизма. Концепция родилась на заре суперкомпьютеров и смысл её предельно прост - будем рассматривать параллельную машину как систему с неограниченным множеством процессоров, каждый элемент которого подсоединен к RAM памяти с бесконечно малым временем доступа. Между RAM и процессорами находятся модули контроля доступа (memory access unit (MAU)). Эти модули "рулят" операциями чтения(Read(R)) и записи(Write(W)) - в зависимости от типа MAU разрешает(Concurrent(C)) или запрещает(Exclusive(E)) параллельное выполнение чтения\записи. Соответственно мы имеем 4 типа MAU. До недавнего времени PRAM оставался лишь концепцией, но усилиями Узи Вишкина PRAM обрел форму языка программирования (XMT-С). Фишка, как говорится в том, что в PRAM синхронизация (или точнее то, что в многопоточном программировании называется потокобезопасностью) возлагается на программиста - скажем если мы используем CREW-MAU (Concurrent Reading Exclusive Writing), то программист должен таким образом составить алгоритм, что уж если алгоритм выполняет параллельную запись в память, то запись эта должна вестись по разным адресам(в разные ячейки памяти). Выглядит страннова-то. Чтобы не показалось, что PRAM это совсем оторванная от жизни модель, отмечу, что разумный подход к PRAM предполагает составление библиотек таких распараллельных алгоритмов и их последующее использование, т.е. в этом плане PRAM ближе к OpenMP\IntelTBB, а не скажем к акторной модели параллелизма или ещё какой-либо модели параллельного программирования, целью которой является взаимодействие\интерактивность\повышение пропускной способности системы, а не пиковая производительность.
Более подробно о PRAM вы можете прочесть в статье Узи Вишкина и в уже упомянутой заметке Clay Breshears.

Куда-катиться-мир ?!

1. Глобальный форум от Гугл - "Вопросы и ответы"

2. Создатели фильма "Великие Тайны Воды" (помните по ОРТ шел одно время) создают фильм о Дарвине в том же стиле... - открытое письмо Александра Макарова.

Мне лично по душе прищлось это:

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

Он обратил внимание на то, что в наши дни, к сожалению, вышли из моды две старые, банальные идеи: 1) Истина существует, и целью науки является ее поиск; 2) В любом обсуждаемом вопросе профессионал в нормальном случае более прав, чем дилетант. Им сегодня противостоят новые, гораздо более модные положения: 1) Истины нет, есть множество мнений; 2) Ничье мнение не весит больше, чем мнение кого-то иного. «Девочка-пятиклассница имеет мнение, что Дарвин неправ, и хороший тон состоит в том, чтобы подавать этот факт как серьезный вызов биологической науке»

четверг, 28 июня 2007 г.

Многоядерность. Несколько событий в области

Несколько не особо связанных событий, на которые тем не менее хотелось обратить внимание:

1. Свершилось: Intel начинает глобальную обучающую программу, призванную научить-таки программистов многопоточному программированию для многоядерных компьютеров. О недостатках этого подхода достаточно много и понятно говорит Эдвард Ли. Например, здесь.

2. Студенты университета Мериленд(США,Maryland) возглавляемые профессором Узи Вишкиным(Uzi Vishkin) создали прототип материнской платы для поддержки множества процессоров, суммарная производительность которых будет эквивалентна 64 ядерному процессору. Технических подробностей данной системы не приводится. Что ещё больше заинтриговало специалистов в области параллельного программирования. В частности Clay Breshears (Intel) в очередной раз поднимает вопрос о том, что если уж студенты способны создать такой вычислительный агрегат, то значит основные проблемы в будущем будут лежать не в области аппаратного обеспечивания(проектирования микропроцессоров), а в области параллельного программирования. Как пишет Lorin Hochstein (магистр из университета Мериленд) Узи Вишкин ярый поборник модели параллельного программирования PRAM, под его руководством был даже создан диалект С для PRAM-машины. И созданный в Мериленде прототип процессора явлется частью PRAM-исследований Вишкина.

Источники - InsideHPC, Clay Breshears ISN Blog

понедельник, 25 июня 2007 г.

Встроенная многоядерность и кубик Рубика

Производители встроенных систем (и специализированных процессоров (DSP, коммуникационные, мультимедийные процессоры и т.д.) больше не могут наращивать тактовую частоту своих выч.устройств из-за все тех же проблем с выделяемой мощностью и энергопотреблением. Поэтому они решили пойти по проторенной дорожке и наращивать производительность за счет многоядерности. Собственно логичное развитие событий, просто не где не встречал документального подтверждения такого положения дел, а тут как раз появился обзор на EETimes.
Зачем наращивать выч.мощность? Ученые из Северо восточного университета США наглядно продемонстрировали ответ на этот вопрос: Производительность нужна для того чтобы доказать, что кубик Рубика можно собрать за 26 шагов, а не за 27(как было доказано в 1997 году). Для решения этой задачи, кубик-рубикистам потребовалось 128 процессоров, 20 терабайтов дискового пространства и 7 терабайтов оперативной памяти. На решение задачи было потрачено 8000 часов процессорного времени и 200.000 зеленых долларов США.
Источник - Clay Breshears's ISN Blog

Про языки программирования и их создание

В достаточно, надеюсь, известной статье "A view from Berkeley", в которой приводится обзор современного состояния и проблем параллельного программирования, выдвигается гипотеза, что при создании новых языков и моделей программирования мы в первую очередь должны руководствоваться не математическими абстракциями (машина Тьюринга, лямба Черча) и не эффективностью аппаратного исполнения той или иной конструкции языка, а результатами исследований в области психологии. Только простой и интуитивно понятный (надежный, если хотите) язык параллельного программирования будет инструментом, с помощью которого программист сможет обуздать параллелизм. Видимо эти же идеи подтолкнули Marc Ordinas к написанию своей статьи Programming language interaction (в принципе ничего нового, но может показаться интересным), а okante к созданию языка Д.

И ещё на закуску-
Заметка про первый в мире язык программирования - небольшой пост про язык Plankalkül. Источник - Алена С++.

Рефакторинг Линукса ради энергосбережения

Следуя общей тенденции энергосбережения и снижения потребляемой мощности, разработчики Linux модернизируют ядро этой операционной системы. Собственно очевидно, что снижение энергопотребления является конкурентным преимуществом как для серверных систем (ибо сервера работают 24х7 и даже незначительное снижение потребления электроэнергии экономически выгодно), так и для встроенных систем (меньше потребляем - дольше работаем). По словам Линуса Торвальдса основные изменения в Linux уже проведены, остались незначительные доработки. Одним из методов снижения энергопотребления вычислительной системы является устранение её тактируемости (tickless) и именно этот метод будет применен в случае Linux.

Источник - ZDNet

суббота, 23 июня 2007 г.

Пентагон покидает OnLine

Непрекращающиеся хакерские атаки вынудили Пентагон и Министерство Обороны США отключить 1500 Пентагонских ПК от Интернета. В этот четверг Роберт Гейтс (МО США) заявил, что email серверы Пентагона подверглись атаке и некоторые элементы "email-системы Пентагона" были выведены из строя. Разумеется самоизоляция Пентагона от Интернета продлится совсем не долго, а лучшие умы Америки уже ведут борьбу с этими дерзкими хакерами... бла-бла-бла :). Кстати сам Р.Гейтс email'ом не пользуется и вообще старается держаться по дальше от всех этих high-end технологических штуковин.

Источник - EETimes

суббота, 16 июня 2007 г.

Вейвлеты и их приложения. Обзор

Вейвлеты в JPEG 2000

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

четверг, 7 июня 2007 г.

Ужасный Google или Непростое поглощение PeakStream

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




Кому нужны нефть и газ, когда есть google-ads?

Дерзкое, если не сказать эксцентричное, поглощение стратапа PeakStream компанией Google должно было напугать основных участников микропроцессорного рынка, производителей серверов и прочего железа. Google, занимающаяся прежде всего рекламой, сожрала ценную компанию, продукты которой имели потенциально большую важность для ИТ-индустрии в целом. При этом целью пожирателя было простое удовлетворение собственных потребностей и ничто иное. В результате был нанесен существенный урон, я бы даже сказал, удар по разработчикам высокотехнологичных серверных приложений, последствия которого ещё только предстоит пожинать в течение нескольких следующих лет.

Мы уверены, что такие поглощения будут продолжаться и дальше, если индустрия будет столь недальновидна. Стратап PeakStream, существующий на рынке около 2 лет, занимался разработкой инструментов, облегчающих распараллеливание однопоточных приложений на многоядерных x86 процессорах Intel и AMD, а в будущем и на GPGPU() карточках от Nvidia и AMD\ATI.

Защитники PeakStream’a и его технологий, а также технологий, которые разрабатываются сейчас пока ещё независимой компанией RapidMind, говорят об этих компаниях как об ангелах воплоти, которые уберегали программистов от жесткого ручного хардкодинга многопоточных моделей. Критики же такого подхода говорят о том, что такие технологии по сути дела являются морфием для программистов, что они реально не решают стоящих перед ИТ-сообществом проблем и что такая халява все равно долго не продержится.

Согласно нашим данным, на протяжении двух последних месяцев PeakStream вела активные переговоры о поглощении с несколькими крупными игроками ИТ-рынка. Мы не можем назвать полный перечень этих компаний, но разумно предположить, что в этот список вошли Intel, AMD, Nvidia, Sun Microsystems, IBM, HP и Microsoft. Неправда ли, именно производители ПО и микропроцессоров выглядят наиболее подходящими кандидатами на заключении такой сделки, поскольку они могли обеспечить значительную поддержку инструментам PeakStream’a и как следствие оказать благотворное влияние на индустрию в целом.

Вместо этого инженеры PeakStream’a отправились оказывать благотворное влияние на Google.

Недавно из достоверных источников нам стало изветсно, что Google не собирается заниматься распространением и продажей инструментов, разработанных PeakStream. Причина, думаю, вам понятна – основной бизнес Google сосредоточен в области рекламы и поисковых сервисов.

Вдобавок ходят слухи, что развитие GPGPU технологий не интересует Google, а ведь именно GPGPU инструментарий был изюминкой PeakStream. Вместо этого компания, съевшая талантливых параллельных программистов, собирается пустить их в оборот при разработке многопоточного кода для x86 процессоров.

Нам удалось проследить судьбу некоторых из бывших пикстримщиков, которые теперь работают в Google. Один из них также как и раньше работает над JIT’ом для многоядерных процессоров. Другой работает над компилятором для x86 платформы, а ещё один переключился на алгоритмы генерации случайных чисел с использованием GPU и CPU с упором на HPC(high performance computing) область.
Приобретение Googl’ом этих талантливых инженеров – это ещё один пример хитрого шага этой умной компании, которая все больше и больше обгоняет Yahoo! и Microsoft. Нет, ну вы можете всерьез представить, что Yahoo! или Microsoft будут приобретать компанию, наподобие PeakStream, для того чтобы улучшить свои поисковые сервисы или лежащие в их основе файловые системы. Вряд ли мы когда-либо станем свидетелями столь удивительных событий.
Вот где Google берет место для Gmail'a!
Хорошо, если говорить начистоту, то Google конечно интересует не только поиск, но и аппаратное обеспечение, что опять же является неплохой встряской для рынка железа.

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

И вот теперь Google запросто покупает недешевую PeakStream как будто бы просто потому, что пикстримщики могут ей пригодиться. Такая покупка про запас. Если бы у Google было столько денег лет пять назад, то вполне возможно, что VMware стала бы просто одной из примочек к Goobuntu, к счастью этого не случилось и сейчас VMware по сути дела дефакто одна из самых применяемых на практике систем виртуализации. И кто знает, может быть в следующем году Google захочется купить Sun, чтобы заполучить нескольких талантливых Java программистов или заграбастать Red Hat, для того чтобы Linux в Google работал получше, да постабильнее.

Вообщем если нас послушать, то покупка PeakStream’a совсем не рядовое поглощение, однако с другой стороны теперь на рынке осталась всего лишь одна компания подобного профиля(single-threaded-to-multi-threaded code) - RapidMind.

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

Вместо этого производители серверов вынуждены молиться на RapidMind, которой предстоит в одиночку решить все эти сложные проблемы, если конечно её не купит ещё какой-нибудь Google. И тогда уж точно в пору будет создавать супер-пупер машину, которая будет денно и нощно обучать программистов практике параллельного программирования.

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

Что ж можете и дальше наслаждаться быстрым поиском от Google, не думаю, правда, что это вам поможет.

Источник - The Register

среда, 6 июня 2007 г.

Наши на WTF



Надеюсь многие из вас читают WTF (Worse Than Failure или в другом прочтении What's the F*ck). Для тех кто по каким-то непостижимым причинам этого не делает предлагаю обратить внимание на перевод этой статьи. Автор Алекс Пападимулис, перевод от замечательного переводчика Евгения Виговского.

C# на Linux и не Mono!

Сегодня компания Mainsoft анонсировала релиз своего продукта Mainsoft for Java EE 2.0 (раньше он назывался Visual MainWin for J2EE). Этот инструмент (а по сути кросскомпилятор) позволяет создавать приложения на C# и Visual Basic, компилировать их под JVM и запускать на Linux. В принципе мы и раньше могли запускать .NET приложения на Linux с помощью Mono, однако теперь за дело взялся и Mainsoft. Без помощи Mono-вцев тут правда не обошлось...
Гарантируется поддержка .NET FW 2.0, ASP.NET 2.0, Microsoft's Visual Studio 2005 IDE.

Источник DDJ.com

Google купил Peakstream

На днях Google заявил о поглощении компании Peakstream. Стартап Peakstream занимался разработкой инструментария для параллельного (многопоточного) программирования. Аналитики склонны расценивать этот шаг Google как ещё один стимул к продвижению параллельного программирования в мейнстрим. О деталях и целях поглощения официальные лица Google ничего не сообщают. Интересный комментарий этой новости вы можете найти в блоге Джо Лендмана, известного вам по моим прошлым постам. Примечательной также является точка зрения Адама Беберга (тех.директор Mithral Communications & Design), который считает, что главной проблемой многоядерных процессоров станет низкий спрос на них со стороны основного покупательского сектора ПК (домашние пользователи). Беберг считает, что Intel с сотоварищами будет крайне сложно убедить пользователей в полезности многоядерности.

Источник - EETimes

вторник, 5 июня 2007 г.

Bots on The Ground | Когда роботы как люди

«Нашел мину – наступи на неё» - эффективные способы разминирования ©.

Результаты такого разминирования могут разочаровать некоторых из нас… Однако вместо человека на мину может наступить и робот, у которого ног будет больше чем у сороконожки. Оторванная нога у робота и одноногий человек разница более чем ощутима, не правда ли ?! Именно поэтому Марк Тилден, робототехник лаборатории Лос-Аламоса, сделал такого робота. После чего он провел серию испытаний своего многоногого
робота-сапера в Аризоне. Думаю, Вам будет интересно узнать - как это было.

Рассказывает Марк Тилден:

«Робот, полтора метра высотой, похожий на насекомое, отлично справился с работой в реальных условиях. Каждый раз, когда он находил и подрывал мину, он терял одну из своих ног, а затем старался перегруппироваться таки образом, чтобы доползти на оставшихся ногах до базы, оставляя при этом на земле дорожку, ведущую к взорванной мине. В конце концов, у него осталась всего одна нога, но он продолжал тащить свое тельце на базу. Это было восхитительно! Машина отлично работает.
Правда, полковник, наблюдавший за тестированием робота, приказал прекратить испытания. Я спросил его – «что случилось? Вроде бы все отлично работает…»
Оказалось, что полковник, военный, между прочим, человек не мог спокойно наблюдать за тем как робот, словно раненый солдат волочит свое истерзанное взрывами тело по земле и раз за разом отправляется на верную смерть. По его мнению, такие эксперименты бесчеловечны».

Война в Ираке и боевые столкновения в Афганистане выявили необычные грани отношений человека и интеллектуальных машин. Впервые в истории человечества тысячи боевых и служебных роботов использовались в реальных боевых действиях. Использовались как достаточно большие беспилотные самолеты, так и небольшие роботы «орлы», некоторые наземные роботы размером с небольшой танк, другие словно двухкилограммовые гантельки специально, предназначенные для того, чтоб солдат мог забросить их в здание через окно и контролировать ситуацию в помещении с помощью камеры. Роботы занимаются поиском бункеров в горах, мин на дорогах, обезвреживанием взрывчатки, слежкой и, иногда, убийствами.
EOD in Tikrit, Iraq
















Но что ещё более поражает, так это не технически разнообразные возможности роботов, а их влияние на своих хозяев… Под час солдаты награждают своих подопечных пурпурными сердцами или присваивают им очередное звание. «Мы называли его сержант Тейлон,» рассказывает Михаил Максон сержант 737 инженерной роты. «Мы всегда хотели, чтобы именно Тейлон сопровождал нас во время операции. Когда он был с нами –все шло отлично. Он всегда все здоровски делал. Несколько раз рядом с ним разрывались снаряды, а он все продолжал работать. Однажды, когда Тейлон зазбоил, его заменили каким-то другим роботом – этого новичка разнесло на кусочки в первую же операцию. Казалось, мы все предчувствовали, что без Тейлона произойдет что-то нехорошее». Солдаты присвоили Тейлону звание сержанта, это почетное звание, которые получают не все солдаты, ведь сержант обычно - лидер подразделения. Кроме того Тейлон был награжден тремя медалями «Пурпурное сердце».

У людей с давних пор наблюдается тесная эмоциональная связь с вещами, которые создал сам человек. Теперь же когда наши рукотворные создания начинают проявлять некоторые зачатки интеллекта, внешне похожие на разумное поведение, человек ещё больше привязывается к роботам. Стоит ли говорить о ситуациях, когда робот спасает жизнь человеку, а именно это постоянно происходит на войне.
EOD Detachment in Fort Story






















Тед Богош частенько вспоминает один случай, который произошел с ним, когда он работал военным механиком на одной из военных баз, неподалеку от Багдада.

В этот день в мастерскую Богоша заглянул солдат из EODa (саперы). Солдаты и их роботы из EOD занимаются уничтожением черной смерти иракских дорог – самодельных фугасов. Этот солдат держал в своих руках небольшую коробочку. Это было все что осталось от робота - робота, которого ребята называли Скуби-Ду (Scooby-Doo).

«От Скуби осталось действительно немного» - вспоминает Богош - «Лучше всего сохранилась голова робота – коробочка с камерой, примерно 6х6х8 см. С одной стороны этой коробочки виднелись надписи, нанесенные краской – солдаты записывали успешные миссии, выполненные Скуби. Видать, этот робот был действительно дорог для них». Было видно, что сапер, хозяин Скуби, был сильно расстроен. «Казалось он потерял лучшего друга», вспоминает механик - «он говорил, что ему не нужен новый робот - ему нужен его Скуби».

«Иногда они слишком привязываются к роботам, словно к собакам» - говорит Богош - «Видя как надежно роботы выполняют свою работу, как они идут на выполнение задания и как они возвращаются, солдаты постепенно начинают воспринимать их как часть команды. Почти всегда у робота есть имя, а когда с ним что-то случается вся команда переживает за его судьбу… Солдат чувствует, что он может положиться на робота, и это связывает их ещё крепче».
«К тому же каждый робот немного отличается от других роботов, в каждом из них есть что-то личностное, персональное… К примеру, любой робот ведет себя по своему, вы приноравливаетесь к его поведению, когда используете его. Иногда робот словно пританцовывает, когда что-то делает, иногда начнет выдавать такие выкрутасы, что по неволе задумываешься о его скверном характере». После выполнения задания операторы всегда делятся друг с другом впечатлениями о том, как их роботы выполняли то или иное задание… вы понимаете, они говорят, о том как роботы выполняли задания, никак оператор управлял роботом, а как сам робот что-то делал! Помниться был один случай, когда одному из роботов взрывом повредило гусеницу, дак солдат-оператор выполнил задание и после дотащил робота на себе, рискуя погибнуть вместе со своим железным другом. Это было возвращение героя…»
«Я не знаю, правда это или нет, но говорят, что неподалеку от нашего лагеря на реке Тигр, оператор часто выводил своего робота на рыбалку. Он усаживал робота с удочкой в тенечке, а сам уходил… правда, клева обычно в том месте не было…»

Продолжение следует…

Источник - Washington Post
Автор - Joel Garreau, Washington Post Staff Writer
Перевод мой.

.NET на микропроцессоре Blackfin






Сегодня Microsoft и компания Analog Device анонсировали версию .NET Micro Framework для процессоров Blackfin (AD). Теперь у разработчиков появился удобный каркас для разработки мультимедиа и прочих специализированных приложений. Более того, разрабатывая ПО для Blackfin программисты смогут использовать MS IDE Visual Studio.
Каркас .NET Micro Framework – это платформа, разработанная Майрософтом для устройств, базирующихся на 32-х разрядных процессорах, с учетом жестких требований к памяти, потребляемой мощности и прочих ресурсов. Процессоры Blackfin имеют как 16-и, так и 32-х разрядную архитектуру и, в том числе, предназначаются для управления обработкой мультимедиа данных в реальном времени.
Кроме полноценной интеграции с Visual Studio .NET Micro Framework поддерживает эмуляцию целевого устройства для тестирования разрабатываемой функциональности и отладки.
«Мы рады, что именно Blackfin стал первым DSP с .NET Micro Framework на борту, » заявил Джерри МакГуйер(Jerry McGuire), вице-президент General Purpose DSP Group компании Analog Device. «Мы уверены, что этот продукт поможет разработчикам в создании новых интересных приложений процессора Blackfin, эффективных как с точки зрения производительности, так и с точки зрения цены и потребляемой мощности. Для примера, скажу, что в рамках одного из наших проектов мы использовали Windows SideShow для отображения информации о настройках мобильных ПК и прочих портативных устройств, таких как плейры и т.д, даже когда эти устройства работали в «спящем» режиме».

Среди прочих достоинств Micro Framework можно подчеркнуть столь необычное для embedded-платформ наличие сборщика мусора и встроенной обработки исключений. Native-код будет по прежнему доступен с помощью Interop-механизмов.

Источник - Dr. Dobb's Portal

пятница, 1 июня 2007 г.

По пивку?

Уже давно в сети существуют разнообразные плугины (или гаджеты, кто как их называет), которые можно повесить на страничке своего блога и позволить своим читателям перечислить немного денег на счет владельца блога (это не намек!:)). Обычно эти плугины выглядели как кнопки с надписями типа "Поддержите нас!", "На хостинг", "На развитие сайта", и т.д. Но кто?, кто скажите мне будет отдавать свои кровные на развитие чужого сайта?! Теперь же любой может проявить свои компанейские, дружеские чувства, купив понравившемуся автору блога кружечку пивка. Именно такую услугу с недавних пор предоставлять сервис PayPal и плугин "Buy Me a Beer". Популярность этого плугина по мнению его автора очень высока.

Источник - Quick Online Tips