`

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

Архив номеров

BEST CIO

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

Человек года

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

Продукт года

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

 

Робота построить - это не ешака купить

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

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

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

Но.

Разве удивительные в своём совершенстве природные системы управления (например, - нервная система стрекозы, позволяющая ей _так_ летать) обладают всеми этими свойствами?

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

Это было, скажем, - "раз".

"Два" будет примерно таким - в книгах по искусственному интеллекту любят сравнивать число вентилей современных СБИС (сверхбольших интегральных схем) с числом нейронов головного мозга. В этом году цифры сравнения выглядят уже очень близкими, по крайней мере, - в порядках. Ну и что? Разве нейрон и базовый вентиль (например, - 2И-НЕ) - устройства одного класса сложности? Судя по описаниям моделей нейронов - вовсе нет. Так что до реализации "искусственного мозга" даже на уровне необходимого количества элементов ещё очень далеко (а о количестве связей лучше вообще не упоминать).

Ну и "три".

Робототехника потихоньку становится очень аппетитным сектором для инвестиций. В Южной Корее, например, не мудрствуя лукаво, решили потратить на будущее $530 миллионов - этих средств достаточно, чтобы к 2013 году создать новый... город "Robot Land" - этакую "роботодолину", в которой будет расположен фактически замкнутый цикл исследовательских, проектно-конструкторских работ и производственных процессов исключительно в сфере робототехники.

Из этих трёх фрагментов можно попробовать собрать нечто целое.

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

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

Ну и, наконец, - последнее. Сейчас, похоже, самое время начинать заниматься робототехникой всерьёз - через 10 лет будет очень-очень поздно, поезд в очередной раз уедет вдаль. А в этой области вполне допустимо и "диссидентство", и использование ресурсов классической академической науки.

PS

Ну и про плашки, само собой. на три восьмых дюйма.

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

Странно всё это

4 октября, во Фрайбурге (Германия), пройдёт очередной семинар коммерческих пользователей  функционального программирования (CUFP, Commercial Users of Functional Programming). Название неудобоваримое, конечно, "пользователь программирования" - это что-то странное. Ну да ладно.

Семинары CUFP проводятся с 2004 года, и ретроспектива их даёт возможность получить "вытащить" информацию о динамике этого самого странного коммерческого использования функционального программирования.

В 2004 году семинар начался в 9 утра и закончился в 17-30. Чистого "семинарного" времени было меньше из-за трёх перерывов (45 минут, 30 минут, 45 минут). Выступили 9 докладчиков, в том числе двое - от Microsoft (из команды разработки ядра Windows и от проектировщиков протоколов для распределённых файловых систем), один - от Linspire (об использовании OCaml при создании дистрибутива Linspire ОС Linux), еще двое - от именитых компаний из мира EDA (автоматизации проектирования электронных утсройств) и вычислительной статистики.

В 2005 году докладчиков было 8, непосредственно об индустриальных применениях ФП по сути говорили только представитель Freescale (компания, купившая большой "кусок" полупроводникового производства Motorola), один докладчик из мира EDA и ещё один - из банковских структур.

В 2006 году формат семинара, по-видимому, окончательно "настоялся" - всё те же 8 докладчиков, то же самое время, да и действующие лица, по сути, почти те же - двое из мира EDA (от Intel), один - из банковской системы (Credit Suisse), появился представитель военных, а именно, - исследовательского центра ВВС, разработчики ПО представлены постоянным участником - Linspire.

Очередной семинар будет немного более насыщенным - 12 докладов (за то же время). Но ничего принципиально нового, судя по анонсам докладов, ожидать не следует - возвращается Microsoft (F# набирает популярность), всеядная EDA-индустрия устойчиво находит ФП применения, да вместо военных теперь выступают фактически медики гражданской обороны.

И что?

Вот действительно, - что?

Сколько эмоций выплеснуто сторонниками ФП, сколько бумаги изведено на учебники, (N+1)-ое руководство по монадам убедительно непонятнее N-го, но написано более живо, лёгким и весёлым языком, да ещё и с иллюстрациями, вокруг нового стандарта Scheme не утихают баталии, а на выходе - "такое" (как в анекдоте: - Продавщица, это у вас сметана или кефир? - Та такое!).

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

Но, погодите, - разве C - такой уж прекрасный язык, разве его нельзя улучшить, сохранив его достоинства, и разве по сей день индустрия не нуждается в действительно хорошем императивном языке программирования (обычном, не объектно-ориентированном)? Похоже, при востребованности даже C (который безусловно хорош, но и также безусловно исключительно далёк от доступного на сегодняшнем уровне возможного совершенства), - подобный язык нужен. Ну и где он? Modula 2? Прекрасный язык, но очень уж "C-неподобный", потому и не прижившийся. И? И...

Странно всё это.

Красота и целесообразность

2560 блейд-серверов, каждый - с двумя 64-битовыми двухъядерными процессорами PowerPC 970MP, в сумме - 10240 процессоров, 20 TB (терабайтов) ОЗУ, 280 TB дисковой памяти, собираемые в единый сверхвычислитель с помощью SUSE Linux.

Кого-то впечатлит, кому-то согреет сердце.

Но это - скучные спецификации.

А вот это - настоящая Красота (здесь - в большем разрешении):

Красота и целесообразность

И ведь спецификации и Красота - одно и то же.

Потому что это - девятый в мировом рейтинге и первый - в европейском, - испанский суперкомпьютер MareNostrum (что значит -  "Средиземное море"), 94.21 терафлопса.

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

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

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

Для садомазохистов - достаточно полный набор фотографий MareNostrum. Почему для садомазохистов? А потому что кому эти суперкомпьютеры, да ещё и красивые, сдались - не до них нам, ой как не до них.

Барьер между lo-tec и hi-tec как мерило уровня развития?

lo-tec - это вещи простые, в каком-то смысле даже "низменные" (по крайней мере, - для почитателя hi-tec "фенечек" - так уж точно). Прищепка - типичный образец lo-tec. И швабра, пока она из двух кусков дерева сделана. И т.д.

hi-tec - с этим тоже вроде как всё понятно: встроенная цифро-аналоговая электроника, развитые системы управления, спрятанные от пользователя, etc.

По идее, при одновременном расширении ассортимента встраиваемых вычислителей и датчиков, снижении их стоимости и повышении доступности средств разработки, барьер между lo-tec и hi-tec должен неуклонно сокращаться. Что означает, - должны появляться какие-то интересные штуки совершенно lo-tec назначения, но в самом неожиданном hi-tec исполнении. Вот, например, как это чудесная вещичка - "Прошло дней". Кстати, - вот уж действительно что может быть более очевидным - соблюдать рекомендованный производителем режим хранения еды. Да тот же аптайм посчитать - сколько сил потрачено, утилит написано, аппаратных приблуд напаяно - не счесть, аптаймами уже меряются даже, а  несвежим регулярно желудок гробят.

Так вот я что думаю - информационное общество (то, в которое логикой развития трансформируется пост-индустриальное) _всерьёз_ начинается тогда, когда lo-tec остаётся lo-tec'ом на уровне задач, но превращается в hi-tec на уровне реализации, и этот процесс становится массовым. Не с объединения информационные ресурсов (оно, кстати, уже не раз было в докомпьютерные эпохи) и даже не с появления доступных hi-tec устройств типа бытовых компьютеров.

И вторая составляющая - придание классике lo-tec мира совершенно новых свойст за счёт hi-tec составляющей, причем таких свойств, которые без hi-tec были бы недостижимы.  Например, - обычное колесо. Сделать его таким, как это получилось у Airtrax, без hi-tec составляющей просто невозможно.

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

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

Как полюбить Cygwin

Раньше я как-то не очень был влюблён в Unix-имитатор Cygwin. Впрочем, и по сей день не очень - хотя бы из-за документации столь примечательной, что её надо использовать в качестве образца.

"Как, у Cygwin ещё и документация есть?" - спросят недогадливые. Да, - отвечу, - её нет. То есть, - нет, она как бы есть, но, всё-таки, - да, её нет.

Именно так непонятно у меня получается ответить на впорос - есть ли у Cygwin документация. Потому что с самого начала в том, что должно ею быть, начинается забавное.Разделы "Быстрый старт для тех, кто более опытен в Windows" и "Быстрый старт для тех, кто более опытен в Unix" отличаются настолько политкорректно, что читатель буквально залипает в поисках тончайшей разницы.

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

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

А управление пакетами?
Это безусловно прекрасно, что оно есть, и земной поклон тем, кто сделал базовый набор пакетов, пусть несколько странно отображаемый инсталлятором, но всё же устанавливаемый по умолчанию. Но почему бы сказавши "А", не сказать хотя бы "Б" - большинство пользователей ведь ставят Cygwin вовсе не для восстановления привычной среды обитания в Windows, а для средств, которыми располагает имитируемое Cygwin'ом. То есть, в первую очередь, - средств развитого скриптинга и разработки. Поэтому как минимум пакет "С/C++ developer" кажется весьма желательным. Ну да Бог с ним, - при желании и пакетов можно наставить вручную, благо зависимости отслеживаются автоматически (ну, случайно закачаете X Windows c кучей сопутствующих библиотек - не беда, трафик нынче дёшев).

Две очевидыне реакции на сказанное выше предугадываю.

Первая - "возьми и сам сделай". Да, логично. Было. Когда-то. Когда пользователь - студент, а программа - из домена .edu.

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

Короче, - не нравился мне Cygwin и я его на машине не держал.

Пока не отыскал эту программку. Документация её ещё лучше, чем Cygwin'овская. Но это в силу достаточной очевидности (ага, - той самой, о которой выше уже было) программы это не так уж и важно.

В общем, Poderosa - в каком-то смысле аналог Xterm, только развитого, с табовым интерфейсом (Kterm из KDE), с возможностью отображать в одном табе сразу несколько терминалов (деление экрана по горизонтали и вертикали), с механизмом плагинов (их немного, но они весьма полезны), со встроенными "вкусностями" типа обеспечения на уровне архитектуры работы с Cygwin, равно как и с Telnet и SSH.

Как полюбить Cygwin

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

В 2005 году проект Poderosa был замечен и включён в списки получателей государственного финансирования.

Странные они, эти японцы...

Впрочем, - за это им спасибо, в комплекте с Poderosa Cygwin мне уже даже вроде как и нравится.

По крайней мере, - прижился уже на двух машинах.

Как социализация убивает блоггеров

Вечером, да еще и в воскресенье, да еще и занудно-заумно.  Но ведь самое время, однако, настучать пару слов – потом времени на них не будет.

Плохо, что заголовок на «заголовок выходного дня» никак не тянет. Есть такое. Посему придётся вдаваться.

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

Ну а блоггеры – это те, кто по ряду причин пишут в блоги, определение которых столь же великолепно в своей ясности, сколь и безукоризненно определение навсегда устаревшего Web 2.0, который уже сменяет ещё более ясный Web 3.0.

Итого, - социализация блоггера, - это процесс усвоения блоггером… (дальше по определению). Всё понятно, и потому не шибко-то и интересно. Кроме последних двух слов определения социализации. А именно, - «данного общества».

Какое оно, - «данное общество», к которому неизбежно «подстраивается» блоггер в своих исканиях «где глубже и лучше»?

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

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

У Стерлинга своё видение причин этого предсказания, я же имею право на своё.

А именно, - на видение социализации причиной неизбежного «де-блоггинга» (хотел записать себе плюсик за придумывание нового слова, как же, - что deblogging’у, что de-blogging’у, гугль ведёт счёт на сотни тысяч страниц).

О ней я говорю потому, что блоггеры пишут не для себя.

Это писатель может работать «в стол», это поэт может писать для предмета своего обожания, себя или, вообще, - для каминного пламени. Блоггер же не может писать для себя - и потому, что делает написанное публично доступным, и потому, что доступность написанного блоггером наступает не после его смерти, и даже не тогда, когда «ещё чернила не засохли», а буквально по мере написания. А все прочие варианты для блоггера – это «слишком поздно». Почему слишком поздно? Да даже не потому, что кругом - тьма других блоггеров (о чём говорит Стерлинг), амбиции, обязанности, поисковые машины, рейтинги и ссылкопомойки. Дело не в этом, а в том, что читатели блогов бывают вроде как нескольких типов.

Вот, например, представители первого типа. Они ждут от блоггера то, что хотят услышать.

А вот представители второго типа - они ждут того, что им интересно.

А это, как будто, третий тип, - они ждут чего-то, что им полезно.

Задумайтесь (только хорошенько) сами – какая между ними разница? Вы её видите? Я, если честно, - не очень. Потому что «мне интересно», «мне полезно» и «я хочу услышать» - для меня практически одно и то же.

Итак, - аудитория от блоггера хочет услышать именно то, что ей хочется услышать (всё остальное - вариации).

Вот блоггеры и говорят. В блогах о языке Ruby – как рулит Ruby на фоне других языков (включая Python), в блогах о  Python - как рулит Python на фоне других языков (включая Ruby), в блогах о  Java - как рулит Java на фоне других языков (включая Ruby и Python), в блогах о Linux – как рулит Linux, в блогах о…

Когда-то, когда и слово «блог» ещё не попало в лексикон, я придумал первоапрельскую чепуху - вектор «дайте нам то, что мы хотим услышать» (почему вектор? Да потому, что большинство текстов – вектора, содержащие некое «направление мысли»), описываемый в системе координат «неудовлетворённая гордость» примерно так (A,B,C,D – некоторые коэффициенты, их выбор зависит от…):

  • A*орт «все они хотят нас обмануть»
  • B*орт «мы очень умные»
  • C*орт «у нас золотые руки»
  • D*орт «Справедливость – это туда»

В результате получилось нечто вроде «они нас обманывают, выпуская одинаковые процессоры с искусственно ограниченной тактовой частотой, но мы – умные, поэтому мы золотыми руками и алмазным сверлом удалим кусок кремния со схемами блокировки повышенной тактовой частоты, и восстановим Справедливость». И, надо сказать, - получилось.

Это ещё был не блоггинг, но уже – игра с социализацией.

А какой вывод?

Хм… Вот непременно нужен вывод.

Вывод один – можно социализироваться, но разве обязательно всерьёз, а?

Читать и плакать!

Вскрылась очередная "чудесатость" реализации FTP в Internet Explorer - если вы c локального компьютера отправили по FTP c помощью IE html-страницу, Explorer заботливо вставит ей в заголовок примерно такую прелесть:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(*)ftp://логин:пароль@путь/имя.html -->

Казалось бы, - давно все знают, что использование IE для работы с FTP - это то самое третье извращение, которого ещё не было при жизни Фаины Раневской (извращений тогда было всего лишь два - хоккей на траве и балет на льду).

Но если проверить? Поискать заветную строчку "saved from url=(*)ftp://" гуглем?

Ой...

Два миллиона с лишним логинов-паролей, бери - не хочу!

Даже и не знаю, что сказать.

Разве что поблагодарю "за наводку" пользователей LJ inquisitor_ua и mambaram, разработчиков IE - за не устающую удивлять реализацию FTP, а администриторов сайтов из "списка двух миллионов" - за то, что они есть.

Прелестно!

Кстати, - теги вовсе не от балды!

Потому что именно что...

О математике и программировании

Это так, - всего лишь попытка осмысления, не более того.

Для «чистоты мысленного эксперимента» вычеркнем разработчиков наукоёмкого ПО из списка – хотя бы потому, что по спецификациям можно писать любые программы, включая и очень наукоёмкие, и при этом не иметь понятия о прикладной области.

Будем рассматривать простую задачу. Очень простую и обыденную.

Предположим, есть некая механическая кнопка, связанная с контактом, состояние которого  (замкнут-разомкнут) надо прочитать из программы. Например, - кнопка клавиатуры.
Кодировщик, «пасущийся» на вершине программно-аппаратных архитектур, решает эту задачу теми средствами, которые для него оставлены на поверхности. А именно, - с помощью соответствующего API в рамках реализованной архитектурной модели. К слову, - выбор этих моделей невелик: или это нечто мониторно-примитивное, вынуждающее кодировщика самостоятельно опрашивать состояние кнопки каким-то вызовом, назовём его ReadKeyState(), или это традиционная для современных ОС модель просмотра очереди сообщений о событиях, или же более редкая модель назначения определяемых кодировщиком обработчиков разных событий. Вне зависимости от модели, для кодировщика нажатие кнопки – процесс невидимый, точнее, - существующий не как процесс, а только как проявление, свидетельствующее о том, что кнопка точно была нажата.

 

Перед системным программистом, в свою очередь, уже совсем иные виды – его волнует протокол обмена клавиатуры, в которую встроена кнопка, но он всё равно не видит собственно процесса её нажатия, а только проявление этого процесса – некое сообщение в установленном протоколом формате, подтверждающее тот факт, что кнопка точно была нажата.

Я два раза употребил слово «точно» и выделил его не случайно. Потому что замыкание контактов кнопки на самом деле… является очень непростым процессом, и характеризуется таким явлением, как «дребезг» (contact bounce).

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

Естественно, виден этот процесс работающему на самом нижнем уровне программисту. И если его более высокоуровневым коллегам математика при решении задачи определения нажатия кнопки была не нужна, то здесь случай особый. Потому что без знания математики, причём серьёзной математики, сразу нескольких её прикладных областей, решить задачку красивого и качественного устранения «дребезга» весьма непросто. Зато если знать теорию электронных цепей, аналоговой и цифровой фильтрации, можно написать рекуррентную формулу цифрового фильтра (для знающих электронику – выполняющего роль триггера Шмитта:

Выход(t) = (1/4)*Вход(t) + (3/4)*Выход(t-1)

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

Вот так примерно и получается, - прикладная область навязывает требования к программисту, и надо знать свой уровень абстракции: кодировщикам – языково-библиотечно-инструментальный, системным программистам – спецификации и протоколы, embedded-программистам («железячникам») – специфику физические объектов, принципов обработки сигналов, математическую статистику, теорию систем etc. 

А не так уж и страшно, на самом-то деле

Книга «19 смертных грехов программной безопасности» построена, по сути, на фразе Амита Йорана, выпускника военной академии Вест-Пойнт, на гражданке получившего степень магистра computer science в Университете Джорджа Вашингтона:
«95% ошибок программного обеспечения вызвано одними и теми же 19 недостатками».

Перечень этих недостатков весьма забавно сначала отсортировать по «популярности» их проявлений ( данные с сайта CVE, Common Vulnerabilities and Exposures), а, затем, - по условной, но вполне очевидной классификации «недостатки используемого языка программирования – недостатки конструкции (архитектуры) реализуемой программы – недостатки рода  человеческого». Немного «поковырявшись» в электронной таблице с пересчётами частоты упоминаний «болячек» на CVE в процентные вклады, получил следующую картину:

87% всех программных проблем порождаются всего четырьмя «болячками», только одна из которых относится к недостаткам языков программирования (и, что характерно, избавиться от неё элементарно – есть множество отработанных приёмов и готовых библиотек), две – к недостаткам архитектуры и ещё одна – к недостаткам человечества вообще. Пресловутое переполнение буфера, являющееся причиной 29,6% программных аварий – «болячка», по большому счёту, свойственная не столько С и C++, сколько «болячка» в каком-то смысле социальная, разве что подвержены ей представители определённого социума – программисты: как только они начинают мнить себя Творцами Своих Миров, так сразу и появляется латентное допущение «в моём Мире никогда и никто не введёт здесь строку больше чем из 128 символов». А в реальном мире – вводят.
На втором и третьем месте первой четвёрки – архитектурные хвори: XSS, cross-site scripting, подагра web-приложений, и впрыскивание SQL-кода (SQL Injection), врождённый дефект многих систем, основанных на трансляции SQL-запросов.
Четвёртое место – общечеловеческий недостаток: где от человека требуют запоминания пароля, там он хорошо запоминает пароли «Бомба» и «12345», остальное же запоминает или плохо, или вообще не запоминает. Плюс, - люди разговорчивы и доверчивы. В общем, - брешь всегда там, где вводится пароль.
В перечне оставшихся 15 «болячек» (их суммарный вклад в дело ненадёжности ПО около 13%) на первом месте опять идёт родовая травма С/C++, на самом деле также зависящая всё-таки больше от культуры работы программиста – строковые шаблоны форматирования ввода-вывода, так что правило опять же простое: реальный мир отличается от мира Творца, и где есть возможность вводить не то, что должно вводить в идеальном мире, там и будет введено не то. Причём, - самое не то из всего возможного не того.
Второе место – переполнения при целочисленных вычислениях. Это от языка не зависит, это – болячка фундаментальная, потому и исключительно интересная (рекомендую почитать вот это).
С третьего места во втором эшелоне начинается «архитектурщина». Впрыскивание команд – если контроль доступа к механизму исполнения команд несовершенен, можно найти способ заставить его исполнять всякие нехорошие команды.  Затем, – гонки. Естественно, - гонки за общий ресурс. И стоит его «пощекотать» со стороны, как начинается… да что угодно начинается. Это хворь тяжёлая, хроническая, поражающая многопоточные и «параллельные» архитектуры.
Дальше же – всякая мелочевка, от общеархитектурных расстройств (кривые обработчики ошибочных ситуаций, беспечный подход к «несущественному» времени модификации файла, дающий возможность атакующему «подсунуть» вместо реального файла какую-нибудь гадость) до ужасов конкретных API (SSL и TSL, например).

Главная же, «19-я болезнь», действительно страшная, потому что собирательная и в симптомах, и в латентных факторах: безопасность всегда усложняет жизнь не только разработчикам, но и пользователю. Это означает, что даже огромные затраты на разработку подсистемы безопасности будут сведены на нет её сложностью для пользователя.

А 20-я скрытая болезнь, поражающая программистов в самый их главный нервный узел, уже дважды "вылезла" в этой записи. Да, - мощный и одновременно гибкий инструмент очень трудно сделать одновременно совершенно безопасным, потому что мощность+гибкость и безопасность - взаимоисключающие критерии. Но ведь есть же методы, есть - достаточно посмотреть на код gpsd, чтобы понять, что такое ведь доступно всем желающим:

"gpsd is high-quality, carefully-audited code. It is regularly checked with the standard mode of splint, audited with Valgrind, and an extensive regression-test suite is used to check correct behavior before each release. This care has paid off in an exceptionally low defect rate; our first Coverity scan, in March 2007, turned up only two errors in over 22,000 LLOC."

А если без истерик?

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

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

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

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

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

 А если без истерик?

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

Но.

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

И?

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Slack подает жалобу на Microsoft и требует антимонопольного расследования от ЕС

 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT