Тег ‘программирование’

Еще раз про GNU GPL

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

Например, довольно легко понять, что Кремниевая долина в Калифорнии превратилась в олицетворение передовых технологий вовсе не из-за названия, и не из-за хорошего климата, и даже не только из-за находящегося поблизости кампуса Стенфордского Университета, а, как это не странно, по гораздо более прозаическим причинам. Просто в районе Санта-Клары находилось несколько “исследовательских” структур сначала ВМС США, а затем и NASA – и “высокотехнологические инкубаторы” поначалу занимались производством всяких ништяков для американских военных и околовоенных структур.

В сущности, Кремниевая Долина – такой же “продукт” Холодной войны, как операционная система Unix, Интернет и спутниковая навигация. Все эти штуки обязаны своим рождением если не военным (в лице DARPA), то “оборонным” компаниям – а к “оборонке” что в Штатах, что у нас, можно отнести почти все “высокие технологии”. Это только потом, когда “высокие технологии” превратились в обыденность, а Холодная война закончилась, стало можно заниматься всякими “доткомами” – но не раньше.

Про Unix я вспомнил не зря – потому что с этой операционной системой связана определенная “культура” в программировании и околопрограммистских вопросах. Например, само представление об open source и традиции лицензирования программного обеспечения возникли потому, что Unix с самого начала рассматривался не как коммерческий, а как исследовательский – читай “финансируемый DARPA” – проект. Довольно неожиданным для “советского” человека оказывается то, что “оборонными” разработками в области зарождавшейся тогда Computer Science в США занимались “гражданские” исследователи, да еще и не “секретили” свои разработки – но факт остается фактом, DARPA щедро выделяла деньги в виде исследовательских грантов.

Наследие “исследовательских” традиций и “научной этики”, пришедшей из американских университетов, в мире Unix – это культура open source. Написал полезную программу, реализовал оригинальный алгоритм, разработал протокол обмена данными – поделись с коллегами. Но что характерно – это “исследовательская этика” не ограничивала возможное в будущем коммерческое использование. Собственно, наиболее ярко ее иллюстрируют те лицензии, под которыми распространялось ПО, разработанное в рамках исследовательских программ – так называемые лицензии BSD и MIT.

Нынешний open source отравлен движением Free Software Foundation под руководством сомнительного чувака Ричарда Столлмана и придуманной в рамках этого движения лицензией GNU GPL. Я уже обращал внимание на две проблемы ПО, использующего эту лицензию, которые вытекают из ее “вирусной природы” – оно с трудом “стыкуется” с ПО под “коммерческими” лицензиями, а просто поглядев на лицензированный под GPL код, разработчик сталкивается с тем, что все, что он напишет впоследствии, может оказаться “производным произведением”.

Немного поясню последнее утверждение. В Штатах уже был прецедент (я могу путаться в деталях, буду благодарен за уточнения и пруфлинки), когда человек ушел из Microsoft в организацию, занимавшуюся разработкой чего-то GNUтого, на его беду – прямого конкурента того продукта, над которым он работал в Microsoft. Последние, не будь дураками, подали в суд, утверждая, что тот видел майкрософтский код и теперь “перерабатывает” его в смысле законодательства об авторских правах. Американский суд с этими доводами согласился. Но замените здесь Microsoft на Free Software Foundation в “зеркальной” ситуации и получите совершенно мерзкую ситуацию. GNU GPL – это, по выражению Столлмана, “хак законодательства” – способ использовать всю силу закона против тех, кто делает что-то, не нравящееся Free Software Foundation. “Свободы” в ней не больше, чем в “обычном” EULA любого софтопроизводителя.

Но об этих ограничениях и несуразностях GNU General Public License мало кто задумывается – а зря. Как отмечают в статье, на которую я сослался в своей старой записи, многие авторы лицензированного под GPL кода попросту не понимают условий лицензии, ограничиваясь плохими ее пересказами. Как реагирует неискушенный автор на слово “Free” в “Free Software Foundation”? “Замечательно! Я же хотел поделиться своим кодом со всеми!” – думает он и попадает в страшную ловушку. После этого его код может быть полезен лишь авторам проектов с той же лицензией. Но об этом люди просто не подозревают, после чего рождаются вот такие перлы:

This program is written under GNU General Public License in C programming language. PLEASE NOTE THAT THIS PROGRAM VERSION DOES NOT HANDLE POTENTIALLY OCCURRING INTERRUPTIONS OF COMMUNICATION OR NETWORK CONGESTION SITUATIONS. It may stimulate those intending to write their own client program.

Самое ужасное здесь то, что эта программа – не что иное, как эталонная реализация клиента некоего сетевого протокола, и здесь “вирусная природа” GPL просто вынуждает идти на нарушение GPL. Представьте, что под GPL был бы лицензирован код наподобие такого:


int main(){
return 0;
}

Нетрудно догадаться, что после этого любая программа на C, C++ и куче других языков может быть признана “производным произведением”? Если кто-то увидел бы этот код с припиской “лицензировано под GPL”, то он мог бы забыть о работе программистом и идти в дворники (особо впечатлившиеся могут сейчас пойти помыть глаза с мылом). Аналогично и в этом случае – протокол настолько прост, что лишь посмотрев на “эталонный” клиент, и написав свой, уже можно быть уличенным в создании некошерных производных произведений.

Конечно, намерения автора довольно очевидны – но будучи в плену иллюзий о Free Software Foundation и его “великой светлой миссии”, он подложил немалую свинью всем, кто занимается разработкой любых аналогов данного ПО.

PS Лично я, если бы меня в данном случае приперли к стенке угрозами судебного разбирательства с FSF, попытался бы вывернуться описанным [info]infowatch способом в рамках отечественного законодательства.

Про слово “семафор”

Подведены, но еще не опубликованы итоги “Тотального диктанта”. Организаторы комментируют допущенные участниками орфографические ошибки:

«Чаще всего участниками допускались ошибки в словах: «гармошка», «перрон», «семафор», «палисадник» и «расхристанный». Эти ошибки связаны не столько с незнанием правил русского языка, сколько с реалиями, в которых они употребляются. Например, сейчас немного изменилась культура и формат путешествий, и если слово «семафор» постепенно уходит из речи, то и из письма тоже», – объясняет ситуацию Наталья Кошкарёва, председатель экспертной комиссии Тотального диктанта.

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

Интересно, когда железнодорожный семафор настолько превратится в музейную редкость, что юные программисты будут воспринимать это слово примерно так же, как какой-нибудь “мьютекс”, без привязки к “прототипу”?

Пара слов про heartbleed

На днях прочитал такое мнение по поводу известного бага в OpenSSL:

Yes, tell me more about how crypto should only be written in memory unsafe languages.

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

К сожалению, дело не в языке. Начну хотя бы с того, что используемые сегодня процессоры и операционные системы нельзя назвать memory-safe. Любая загруженная библиотека имеет доступ ко всей памяти процесса – и неважно, на каком языке она написана. Предлагается просто поверить в то, что реализация “правильного” языка подобных ошибок не содержит, фактически – перенести ответственность с авторов библиотеки на авторов компилятора или интерпретатора. Напоминает сказку про кашу из топора? Правда, я как-то писал про это, только в другом контексте.

На C, кстати говоря, тоже можно писать в стиле memory-safe. По большому счету это требование – лишь набор некоторых ограничений, которые можно либо соблюдать, либо нет. По большому счету, все упирается в еще одно “критическое” место – реализацию некоторых функций из стандартной библиотеки. Если мы можем предположить, что malloc() и free() реализованы корректно, то можно попробовать доказать или опровергнуть то, что то или иное обращение к памяти будет безопасно. Второй путь, “практический” – реализовать эти функции так, чтобы некорректная работа с памятью приводила к ошибкам и “падению” программы. Так сделано, например, в libc – но…

http://article.gmane.org/gmane.os.openbsd.misc/211963

Оказывается, что в OpenSSL реализованы свои функции распределения памяти, и реализованы они криво (как показывает существование этого бага). А зачем это сделано? Оказывается, на “некоторых платформах” штатные malloc() и free() работают, по мнению авторов OpenSSL, “медленно”.

После этого вы хотите поговорить о “memory-safe”? Уверен, что в таком случае талантливые разработчики OpenSSL найдут еще с десяток причин нарушить это ограничение, как бы вы не старались. Страуструп писал в своем талмуде по C++ (по поводу ключевых слов private и public):

Защита закрытых данных базируется на ограничении использования имен членов класса. Эту защиту можно обойти манипулированием с адресами и путем явного преобразования типа. Но это, конечно, уже жульничество. C++ защищает от случайного, а не умышленного нарушения правил. Защиту против злонамеренного доступа к закрытым данным в языке высокого уровня можно осуществить только на аппаратном уровне, и даже это является довольно сложной задачей в реальной системе.

То же самое можно сказать, наверное, о любых ограничениях любого языка. От “грязных хаков” может спасти лишь соответствующее к ним отношение в процессе разработки, своеобразная дисциплина разработчиков – а с этим в OpenSSL туговато. Еще раз призываю перечитать слова Тео де Раадта по ссылке выше и убедиться, что даже с тестированием у них печаль-беда:

On ALL PLATFORMS, because that option is the default, and Ted’s tests show you can’t turn it off because they haven’t tested without it in ages. <…> OpenSSL is not developed by a responsible team.

Печально, что такие безответственные люди разрабатывают одну из важнейших библиотек (и дело даже не в криптографии – скажем, даже в нынешнем виде OpenSSL вполне мог бы удовлетворять российским сертификационным требованиям для класса КС1 или даже КС2).

Слышали звон

Имел удовольствие прочитать вот такой текст:

При исправлении учтите пожалуйста сценарии использования поворота экрана, переключения оконного режима. Телефонный сафари очень любит издеваться над пользователями, а наибольший трафик на сайт идёт именно со свзяки iphone/safari 7.

Вы заметили слова “сценарии использования”? Вам ничего не показалось странным? Правильно – “поворот экрана” и “переключение оконного режима” – это не сценарии использования в их обычном понимании. Без чего не бывает настоящего сценария использования? Без цели. “Поворот экрана” и “переключение оконного режима” не служат для решения проблем пользователя, которого он ждет от разрабатываемой системы (в данном случае – сайта; естественно, в случае оконного менеджера все было бы по-другому).

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

При исправлении учтите, пожалуйста, поворот экрана и переключение оконного режима.

Удивительно, но совет учиться грамотной письменной речи я видел только в одной книжке по “околопрограммистским” вопросам – в “Практике программирования” Кернигана и Пайка. А ведь написание документации, комментирование кода или общение в системе учета ошибок требуют точности формулировок не меньшей, чем в случае подчиняющегося формальным правилам кода программ – с той лишь разницей, что вместо выскакивающих сразу ошибок компиляции здесь будут выявляющиеся не сразу ошибки непонимания между “писателем” и “читателем”.

PS Кстати, вопрос на засыпку “писателям” – чем цель отличается от задачи?

Про вики, SVN и всякое управление проектами

В рамках внедрения в коллективе погромистов модных штук типа системы тикетов и контроля версий остановил свой взгляд на Trac как на веб-морде для всей этой лабуды. Пощупал, понравилось – намного лучше отдельных Media или DocuWiki, websvn и Mantis (всех возможностей которого мы никогда не использовали, а написать инструкцию по его использованию “для идиотов” вообще не представляется возможным).

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

А вообще, чем дальше, тем больше прихожу к мысли, что все легкодоступные “системы управления проектами” типа Trac или Redmine удовлетворяют моим требованиям, хотелкам и заморочкам в лучшем случае на “удовлетворительно”. Вот скажите, почему нельзя нажать в каком-нибудь Trac одну кнопочку и получить в вики страницы типа “Руководство программиста” и все остальные документы, предусмотренные ГОСТами 34 серии? Я же даже не прошу о другой кнопочке, которая распечатает эти страницы в соответствии с ГОСТами 19 серии, переплетет и отнесет в нормоконтроль :)

Нет бога, кроме 3NF, и Тед Кодд пророк ее

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

И кто-то ведь доверяет деньги этим людям, неспособным понять слова “функциональная зависимость” и “нормальная форма”.

Японский автоматический лифчик

Пишут, что японцы изобрели саморасстегивающийся по команде через Bluetooth лифчик:

http://lenta.ru/news/2014/01/27/bra/

Очевидно, что обработку данных о ЧСС, уровне гормонов и прочем состоянии нервной системы надо проводить на самом лифчике, не добавляя в систему лишнего устройства – смартфона с каким-то “приложением”, которое можно подменить. Интересно, одному ли мне пришла в голову мысль об уязвимости устройства перед злохакерами?

Айтишный русский

Я очень не люблю невыносимо-отвратительное слово “функционал” – не имеющее никаких преимуществ перед “функциональностью” – в чем я, оказывается, не одинок. Но вообще, мне не очень нравится примерно 9/10 современной русскоязычной “околокомпьютерной” терминологии.

Возьмем, например, простое слово “директория”. Всякие линуксоиды употребляют его к месту и не к месту – при этом не вполне понимая, что это довольно грубая калька с английского термина directory – что буквально переводится, как “справочник”. И в самом деле, в файловой системе UNIX directory – это особый тип файла, содержащий список файлов, содержащихся “внутри” него. В книгах 80-х годов этот термин переводили словом “каталог”, что достаточно точно передает смысл. Слово “директория” или даже “директорий” (то же самое, но в мужском роде) появилось скорее в относительно массовой околокомпьютерной литературе 90-х, а через некоторое время превратилось в своеобразный “маркер”, отличающий настоящего компьютерщика от виндузятника (последний употреблял слово “папка”).

Из-за определенного снобизма я сейчас стараюсь везде и всюду использовать слово “каталог” – потому что “Директория“, если пользоваться определением из БСЭ, к файловым системам отношения вообще не имеет. Разумеется, я не хочу изобретать Язык Предельной Ясности, подобно Сологдину из “В круге первом” Солженицына – потому как тогда я должен был бы пользоваться словом “справочник”, а не птичьим словом “каталог” – но и не хочу опускаться до уровня брайтонского еврея, говорящего на странной смеси русского и английского.

Сейчас меня немного волнует тема всяких систем контроля версий. Есть ненулевая вероятность, что мне придется написать в недалеком будущем некую инструкцию для начинающих похапешников по использованию SVN или Git (пока склоняюсь к первому). Но обилие слов типа “репозиторий”, “коммит”, “ревизия” – хорошо, что branch перевели словом “ветка” – мне не вполне нравится. Мне кажется, что бездумное заимствование иностранного термина там, где, немного подумав, можно подобрать русский – свидетельство некоего скудоумия и лени.

Впрочем, признаюсь, что я пока что только задумался о таком “словарике” – и, например, еще не подобрал четкого перевода слова “commit”. Repository вполне официально (в svn-book, например) переводят словом “хранилище”, “ревизия” мне не нравится из-за отсылок к сантехнике. В общем, я хотел бы через некоторое время обсудить такой словарик – чтобы вы не удивлялись, с чего это вдруг я начал изобретать свою, ни на что не похожую терминологию.

А что вы финкаете про коммиты в репозиторий?

Все правильно сделал

Наблюдаю в интернетиках очередную истерику по поводу найденного Навальным документа, где глава ростовского Минсвязи Герман Лопаткин рекомендует не использовать некоторые сервисы Google. Могу прокомментировать действия Лопаткина разве что заголовком этой записи.

Про обновления софта

Ссылка раз:

http://blogs.msdn.com/b/oldnewthing/archive/2013/10/31/10461992.aspx

Ссылка два:

http://dxdt.ru/2013/11/05/6290/

Если вы читали разборы причин катастроф на сайте НАСА, то несомненно нашли хотя бы один случай, где было нарушено прекрасное “общеинженерное” правило – “работает – не трогай!”. Применительно к софту один из его частных случаев звучит так – “не глючит – не обновляй”. И главное отличие Microsoft от разработчиков хистерского говнософта (к которому я отношу и Wordpress) – в том, что они это правило иногда соблюдают.

Я более чем уверен, что “современный” программист в ответ на претензию типа “в новой версии операционки не ставится очень Важная Программа версии 1996 года” сказал бы что-то типа “А вы ее обновите!” Сломали совместимость? Не беда, все быстренько поправят. Вопрос в том, кто будет поправлять и кто это оплатит. Подход “наплевать на совместимость, даешь новую версию” в глобальном масштабе приводит лишь к издержкам.

Про возврат денег за венду

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

Естественно, в этой ситуации в проигрыше оказалась отнюдь не Microsoft – а оказавшиеся “крайними” продавцы – ведь именно к ним бежит недовольный энд-юзер, жаждущий и поставить пиратку, и вернуть деньги. Продавец, разумеется, не горит желанием возвращать деньги – а потом получать возмещение своих расходов от поставщика и так далее.

И вот в этой ситуации я склонен понимать “охуевших барыг”, которые попросту не связываются с этой программой, а решение Microsoft считаю совершенно неправильным – не только по этой причине, но и исходя из несколько других соображений. Предлагаю попробовать осознать – что, если говорить бюрократически-гостовскими терминами, стоит на полках в ближайшем компьютерном магазине.

Лично я склонен считать, что любая “персоналка” прекрасно определяется термином “аппаратно-программный комплекс”. Но если речь идет о “комплексе” – в который входят, скажем, интеловский процессор, нвидиевская видеокарта, майкрософтовская операционка (а также еще куча софта типа BIOS, “прошивок” разных там контролеров и так далее – их просто нельзя купить за 70 рублей на ближайшем рынке, и они “идейных” как-то особо не интересуют) – то подразумевается, что “комплекс” – это нечто большее, чем все его компоненты, взятые по отдельности.

Согласитесь, что диковато выглядит ситуация, когда при покупке ноутбука покупатель просит – “А выковыряйте отсюда процессор, он мне не нужен, у меня свой есть”. Для “аппаратных” составляющих обычно не предусмотрено возможности замены “по выбору покупателя” – тогда почему так хотят поступать с “программными”?

Естественно, что подход “продаем аппаратно-программные комплексы” – не единственно возможный в торговле персональными компьютерами. Но он достаточно широко распространен, а на “смежных” рынках – типа мобильников или планшетов – вообще принципиально единственный. Из “мира ПК” хотелось бы обратить внимание на политику Apple – которая не продает ОС и “железо” только “в совокупности”. Конечно, можно поставить хакинтош на компьютер, собранный из дешевой комплектухи с Савеловского рынка, или вкорячить Windows на последний iMac, но ни один из вариантов Apple не одобряет и разумеется, не будет возвращать деньги за Mac OS, если вы решите ее “снести”.

А какие бывают другие подходы? Можно торговать комплектующими или – как промежуточный и более распространенный вариант – “сборка из комплектующих”. Как мне кажется, его просто путают с тем, что я описал. Да, если приравнять ОС к другим комплектующим – то возможность выбора таковой или покупки ПК “без ОС” (то есть с DOS или кастрированным Linux) не кажется такой уж дикой. Но выбор между двумя этими “режимами” осуществляет не пользователь – а производитель компьютера.

Чем какой-нибудь Asus или Acer хуже, чем Apple? Они имеют точно такое же право рассматривать ОС Windows в составе их продукции, как неотъемлемый компонент. А с другой стороны – даже некоторые производители ноутбуков, скажем, тот же Lenovo в той его части, которая “бывший IBM”, рассматривают свои ПК, как “комплектующие изделия” – и готовы продавать их без ОС. В случае так называемых “бизнес-ноутбуков” это происходит сплошь и рядом, в отличие от “массового” рынка. Там это, разумеется, оправдано – потому что иногда встречаются специфические требования к ПО, которые производителю компьютера выполнять неудобно.

Что я хочу сказать? “Возврат денег за предустановленный Windows” превращает рынок “Wintel-систем” в торговлю “наборами для сборки”. Чем хорош тот же iMac и вообще техника Apple, по рассказам ее фанатов? Там нет всяких “несовместимостей драйверов” и прочей знакомой пользователям Windows ерунды – и это достигается именно за счет того, что ОС и железо рассматриваются, как составляющие “комплекса” – который и предлагается пользователю целиком, без каких-то намеков типа “а вот это можно выкинуть и поменять”.

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

Вам, программистишки

Все равняемся на Диму Маликова: https://github.com/dmalikov, автора крайне полезных программ HaCh и loh. Кстати, вот он же на Stack Overflow: http://stackoverflow.com/users/570689/.

:)

Как я разговаривал с создателем Google Maps

[info]infowatch написал сегодня про “доморощенные” IT-сервисы и айтишную ревность:

Есть такая айтишная ревность. Нет пророка в своём отечестве, нет знатока на своём предприятии. То, что сделали далёкие незнакомые дядьки и продают за деньги, всегда воспринимается лучше, чем то, что бесплатно сварганили знакомые ребята в соседней комнате. “Ну, это же Лёха, я с ним пиво пил. Он, конечно, хороший парень, но куда ему до Гугла!” Лицезрение процесса изготовления ИТ-продукта не прибавляет уважения к результату. А внушительная цена – таки прибавляет. При прочих равных. А эти “прочие” чаще всего примерно равны, поскольку чего-то кардинального и революционного изобрести трудно, все продукты и сервисы очень близки по эффективности.

А я вспомнил, что как раз недавно пил пиво с таким вот “Лёхой”, который единолично создал целый Google Maps. История очень простая. Есть Предприятие, из тех, что выпускают исключительно Изделия, а на предприятии – локальная сеть. Выхода в интернет нет, за чем неукоснительно следят. По некоторым слухам, кстати, в такого рода локальных сетях очень модно использовать IP-адреса из диапазонов, принадлежащих американским госучреждениям. Скажем, бухгалтерия сидит на IP-адресах Минфина, отдел режима – Минобороны и так далее.

В принципе, в этой сети есть довольно оживленная жизнь – пара форумов, “для начальства” и не очень, FTP-шки с фильмами и варезом, жаббер-серверы, некоторое количество веб-серверов “для разработки” и так далее. Не знаю, есть ли доморощенный Tor, но вполне может быть. И вот как-то Лёхе – будем называть его так – понадобилось посмотреть на рабочем месте ролики с его видеорегистратора. Программа для просмотра (наверное, что-то типа Registrator Viewer) умеет показывать путь на гугловских картах, но за ненахождением оных нецензурно ругалась. Что сделал бы нормальный человек? Подключил бы йотовский модем и радовался бы жизни.

Но патологически честный Лёха простых путей не искал, к тому же, тратить деньги на йотовский модем его заела бы жаба. Вместо этого он решил сделать свой Google Maps. Для начала на одном из доступных Лёхе “бесхозных” серверов был поднят Apache, а знакомый админ за бутылку сделал на локальном DNS зону .com (отданную в полное распоряжение Лёхе). Сами же “карты” изготовлялись с помощью cgi-приложения на основе ГИС “Панорама” (в принципе, уже можно догадаться о направлениях деятельности Предприятия – нормальный человек с этим поделием добровольно связываться не будет). Метод запроса тайлов карты у Гугла довольно прост, и реализовать его особого труда не составило. Все это было дополнено парой утащенных у “большого” Google скриптов (зачем-то они были там нужны) и “главной страничкой” на основе Leaflet. Карту Лёха взял откуда-то из “закромов Родины”, с ней проблем было меньше всего (тем более, что для начала достаточно было только Москвы и окрестностей).

Все это заняло буквально два дня – после чего, разумеется, было забыто и заброшено. Но если что – то Лёха, с которым я пил пиво, еще и переплюнет этот ваш Гугл.

Про экзамены по ПДД

Вот давно хотел спросить, все как-то лень было. Общеизвестно, что экзамен по ПДД у нас сдается “технически продвинуто” – на компьютерах. И не менее общеизвестно, что за некоторую мзду можно сдать экзамен, вообще не готовясь. По форумным рассказам, выглядит это так: экзаменуемые заходят в класс, их рассаживают, проплатившего сажают за какой-то определенный компьютер (”третий от окна слева”). Он отвечает на вопросы как угодно, в итоговый протокол попадают правильные ответы, кроме двух случайно выбранных (чтобы не привлекать внимания “безупречным” результатом, две ошибки допускаются) – в итоге ставится оценка “ЗачОт!” “Сдал”.

Вопрос такой: откуда в программе, или даже аппаратно-программном комплексе для сдачи экзамена по ПДД такая крутая фича? Прописана ли она в ТЗ на разработку софта, отражена ли в документации или является “недекларированной возможностью”?

Интересное мнение про Яндекс и компьютерную лингвистику

Яндекс и Гугль многое сделали для материальной поддержки компьютерных лингвистов – только эта помощь не бескорыстная, как пытаются сейчас “представить дело” апологеты крупных поисковых систем, в связи со смертью Сегаловича. И как мне кажется, эта помощь очень сильно затормозила развитие программистских решений: потому что корпорации “подгребли” под себя значительную часть компьютерных лингвистов, и ориентировали программы на свои нужды, на нужды поисковых систем. У них есть деньги, у них есть воля, что сказать еще?

Отсюда: http://caps-lo.livejournal.com/187148.html. Как мне кажется, довольно оригинальный в наше время взгляд на “корпорации добра”.

Про операционные системы

В ходе обсуждения пользовательских привычек и механизмов их формирования у [info]infowatch плавненько перешли к обсуждению разнообразных принципов, реализованных внутри разных операционных систем. Мне кажется, что для ноосферы в целом будет скорее полезно описать мои взгляды на проблему.

Начнем, разумеется, с азов. Любое взаимодействие человека с компьютером укладывается в простенькую схему – человек вводит в компьютер команду, тот что-то делает и каким-то образом выводит результат. Очень важная для понимания сути происходящего вещь – богатство пространств команд и ответов, сравнимое с таковым у “естественного языка”. Это позволяет, например, применять к взаимодействию человека и компьютера слово “общение” – пусть даже и в переносном смысле.

Приведу сразу кучку примеров. Система “лампочка-выключатель” обладает всеми признаками “интерактивной компьютерной системы” – у нее есть устройство ввода, устройство вывода, и даже – какая-то реакция выхода на вход. Но так как пространства “команд” и “ответов” у нее минимально возможные – то и говорить об “общении” с ней – это адская шизофрения. Формально, шизофрения – это и общение с железным ящиком под столом, но оный ящик хотя бы может производить впечатление живого собеседника. Налицо, кстати, диалектический переход количества в качество :)

Перейдем к более содержательным примерам. Для начала – в духе книжки 1958 года “Автоматические цифровые машины“. Ввод здесь – это записанная на перфокартах последовательность команд, вывод – распечатка с цифрами. В разделе этой брошюры, посвященном описанию процесса программирования, описывается шесть команд некоей вычислительной машины. И уже эти шесть команд, вместе с правилами их записи, называются “языком” – пока в кавычках. В более современной литературе это слово вполне заслуженно пишется без кавычек, а “классические” примеры языков, на которых пользователь общается с компьютером – это “текстовые” языки – командная строка Unix, REPL в Lisp-системах, языки программирования типа C/C++/Java/whatever. Тут комментарии, в общем, не требуются. Скажу лишь только, что эти языки пытались даже исследовать методами лингвистики – и вполне успешно. Что более сложно – так это восприятие в качестве “языка” графического пользовательского интерфейса. Но если задуматься – то это тоже язык, состоящий из простых надписей и пиктограмм.

В принципе, сейчас мы вплотную подошли к одному из фундаментальных свойств операционной системы. Все современные компьютеры (за довольно редким исключением) недалеко ушли в плане “машинного языка” от существовавших в 1958 году. Но “язык”, на котором пользователь общается с машиной изменился до неузнаваемости. Не нужно набирать программу с помощью кучи тумблеров или пробиванием перфокарт. Не нужно, в большинстве случаев, заниматься “программированием”. Более того, программирование распалось на “низко-” и “высокоуровневое”. Можно прекрасно пользоваться современным компьютером, умея лишь тыкать мышкой или даже пальцем в нужные места на “экране”. Можно предположить, что в компьютере живет “что-то”, что принимает ввод на одном языке, переводит его на “машинный”, а затем – проделывает обратный процесс с “ответом”. Это “что-то” и называется “операционной системой”. Вот, скажем, определение из книжки Таненбаума:

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

Замечу, что оговорка о “виртуальной машине” очень важна – в очень многих случаях “языки” ввода и вывода в машине, реализуемой с помощью операционной системы, не являются “расширениями” таковых на аппаратном уровне. При этом о ней иногда попросту забывают – например, заголовок раздела, где приводится это определение, у Таненбаума звучит “Операционная система как расширенная машина”. В этом определении можно дойти до определенного “экстремизма”. Например, Windows с установленной Visual Studio – это отличная от “голой” Windows операционная система. Входной язык ее расширяется с помощью некоторого диалекта C++ – поэтому они и разные :) В принципе, ничему это не мешает – так что не будем заморачиваться.

Попробуем теперь описать “языки”, которые поддерживает, скажем, относительно современный дистрибутив Linux “из коробки”. Оказывается, что таковых – довольно много. Для начала – какое-то подобие машинного языка в исполняемых файлах. Затем – C (и даже C++) с POSIX и еще некоторыми расширениями. Обычно доступен и какой-нибудь “скриптовый” язык – типа Perl, Python – да хоть Emacs Lisp! Нельзя забывать и о языке командной строки, и о языке “коротких надписей и пиктограмм”, реализованном в графическом интерфейсе пользователя.

Но все эти “языки” очень серьезно отличаются своими “базовыми” понятиями – в “машинном” языке речь идет о ячейках памяти, в C – о процедурах, переменных и структурах, в Emacs Lisp – о функциях, в командной строке – о каталогах, файлах и командах, в графическом интерфейсе – о папках и документах (несмотря на то, что рьяные линуксоиды отрицают существование последних двух понятий). Эти вещи поддерживаются в архитектуре операционной системы по-разному. Например, во всех Unix-подобных (читай “современных”) ОС “файловая система” с файлами и каталогами – одна из фундаментальных частей архитектуры. А вот документы и папки из графического интерфейса – они реализованы с помощью файловой системы. Следовательно, применительно к “относительно современному дистрибутиву Linux” абстракцию “файловой системы” следует считать более “фундаментальной”, чем абстракцию “рабочего стола”.

В некотором смысле “наиболее фундаментальные” абстракции современной операционной системы лучше всего описываются с помощью языка, который можно условно назвать “C + POSIX” (Windows API с его понятиями тоже в некоторой степени похож на него). Но, как несложно догадаться, можно объявить “фундаментальным” любой более-менее приличный язык взаимодействия человека с компьютером и его абстракции взять за основу. Вернемся к примеру с “рабочим столом”. В “оригинале” – как его видели в Xerox PARC – графический интерфейс типа “окошечки и значки” довольно сильно отлдичается от современных реализаций. На “рабочем столе” находятся значки, представляющие “папки” и “документы”. При щелчке мышкой на значок либо “документ”, либо содержимое папки показывается целиком, в виде “окна”. Вроде бы все прекрасно? Но ровно до тех пор, пока кто-то не углядит параллелей между папками и документами с одной стороны и каталогами с файлами – с другой.

Разница между каталогом и папкой, может быть, и не так ужасна – благо в развитой ФС вполне можно представить и “виртуальные папки” Windows в виде каталогоа, но вот отличия файла в смысле Unix-подобной файловой системы и документа – просто катастрофические. Например, html-файл – это документ? А является ли он документом без кучки картинок (файлы jpg, gif и т. п.)? А один и тот же текст в Word, PDF и HTML – это один документ или три разных? А кучка html-файлов, представляющих собой страничку Васи Пупкина на narod.ru – это один документ или несколько? Можно дать ответы на эти вопросы в рамках абстракции “рабочего стола” – но тогда потребуется отказаться от кучи вещей, которые существуют в “файловой системе”.

Ужасная катастрофа в области всех теоретических наработок в области операционных систем – это появление и триумф UNIX. Его довольно примитивные, расчитанные прежде всего на простоту реализации, решения стали определяющими во всех современных ОС. Более того, трудно даже помыслить “непохожую” на Unix операционную систему (за исключением разве что каких-то IBMовских динозавров). Например, замечательная концепция “обменивающихся сообщениями объектов” и весь связанный с ней объектно-ориентированный подход (в варианте Smalltalk, а не C++/Java) прекрасно ложатся на техническую реализацию в виде микроядерной ОС. Лямбда-исчисление Лиспа, одинаковое представление “программ” и “данных”, изменчивость и первых, и вторых – это лисп-машины или Emacs. Да-да, последний тоже можно и нужно называть “операционной системой”. Но “микроядро” в современном понимании превратилось в “еще одну реализацию Unix”, лисп-машины – в Emacs, появившийся в Xerox PARC прекрасный пользовательский интерфейс с метафорой “рабочего стола” – в его ужасные подобия в Windows и нынешних Linux. Все более-менее жизнеспособные идеи попросту натягиваются на порой слабо совместимые с ними принципы Unix – а затем все голосят о “дырявых абстракциях”.

Из более-менее современных ОС, предлагающих (да пусть даже и на “пользовательском” уровне) альтернативы Unix-подобной файловой системе можно назвать разве что PalmOS – с ее желанием “запихать все в базы данных”, да Apple iOS – где над “файловой системой” надругались самым беспощадным образом. Но в сравнении с теоретическими разработками начала 80-х – это маленькое изменение.

Короче говоря, восприятие Unix как “единственно правильной” операционной системы остановило всякое “экстенсивное” развитие этой области Computer Science на десятки лет. “Интенсивное” развитие – то есть попытки сделать “еще лучший Unix” продолжается, но есть ли в нем смысл – я сказать затрудняюсь.

Про криптографию и программистов

Мне кажется, статейка заcлуживает внимания:

http://happybearsoftware.com/you-are-dangerously-bad-at-cryptography.html

Собственно, об этом писал [info]sporaw:

стали неумело применять “тяжелую криптографию”, воспринимая ее как “серебряную пулю”, но ничерта не понимающие в ней и в особенностях ее использования

Нет, функция md5() в PHP не решит ваших проблем.

Railway Oriented Programming

В подтверждение записи о том, что работа программиста – это придумывание языков программирования. В одном англоязычном блоге обнаружил пример этого подхода, так сказать, в действии. Рассматривается простая задачка, элементарная последовательность действий, каждый шаг в которой может привести к какой-либо ошибке. Постановка задачи и начало ее решения, прямо скажем, не впечатляют. Но во второй части, как раз и названной “Railway Oriented Programming” – как раз и происходит самое интересное.

Диаграммка типа “поток данных” в принципе, выглядит вполне привычно для многих. Слева вход, справа выход(ы), в квадратиках написаны какие-то функции – все замечательно. Но для того, чтобы перевести ее в реальный программный код на “классическом” ЯП – нужно выполнить некоторую формальную процедуру. Предлагается что-то типа “универсального” языка – который одновременно и изображает конструкции с диаграммы (используются железнодорожные аналогии – типа “стрелка”, “тупик” и т. п.) – и одновременно позволяет записывать программы. Что это, если не язык программирования?

Не так давно мне пришлось освоить одну систему “программирования мышкой”. Нет, это не мейнстримное “визуальное программирование”, обычно понимаемое, как “накидать компонентов на форму”. Та система, с которой мне пришлось столкнуться (что-то типа “русского LabVIEW на коленке”) – это в чистом виде “программирование мышкой”, но идеологически очень близкое к вышеописанному подходу. Изображенные на некоей двумерной схеме “виртуальные приборы” соединяются линиями (”виртуальными проводами”). Авторы утверждают, что с помощью подобной системы можно разрабатывать какие угодно SCADA-приложения (SCADA – это Supervisory Control and Data Acquisition, “диспетчесрское управление и сбор данных”). Как может убедиться практически любой, “каркас” такой системы реализуется на подходящем языке программирования с помощью нескольких десятков строк кода.

Автопилот

Фирма Cisco провела опрос потребителей в разных странах – доверяют ли они “автоматизированным автомобилям и автомобилям без водителей”, а также – посадили бы они своего ребенка в такой автомобиль.

driverless-cars

На сайте Cisco приведен такой вот довольно смешной, учитывая результаты опроса, текстик:

Пользователи доверяют автоматизированным автомобилям и автомобилям без водителей

Автомобили без водителей. 57 процентов опрошенных заявили о своей готовности ездить на автомобилях, полностью управляемых не человеком, а техническими средствами. Больше всего таким автомобилям доверяют в Бразилии (95 процентов опрошенных), Индии (86 процентов) и Китае (70 процентов). В России – 57 процентов. В этом отношении самые осторожные – немцы и японцы.

Дети в салоне автомобиля. При ответе на вопрос о том, готовы ли респонденты посадить в автомобиль с автопилотом своего ребенка, уровень доверия к таким машинам сократился до 46 процентов. Наибольшую осторожность в этом плане выразили японцы, французы и немцы. В этих странах лишь 6 процентов опрошенных решились бы посадить своего ребенка в автомобиль с автопилотом.

Обратите внимание, что в более развитых странах уровень доверия к технике намного ниже. Почему? Я бы выдвинул довольно простую гипотезу – это прямое следствие относительно более высокой “компьютерной” и “технической” грамотности населения этих стран. Вообще, по моим наблюдениям, среди специалистов в области IT доверие к компьютерным системам существенно ниже, чем “в среднем по популяции”. Среди активных пользователей персонального компьютера – ниже, чем среди пенсионеров, верящих, что с “занесением в компьютер” все их проблемы решатся. Какой-нибудь индус или китаец, возможно, в жизни не видел “синего экрана смерти” – поэтому и доверяет какому-то абстрактному “компьютеру” совершенно безоговорочно.

Могу в качестве примера привести и одну из баек преподававшего на мехмате “программирование и работу на ЭВМ” А. Г. Кушниренко, который рассказывал о своем ужасе, когда увидел в Копенгагене вагон метро без машиниста, и вчерашнюю же статью А. Венедюхина “Автомобиль для разумных“, где тот приводит несколько “нехороших” для автоматики сценариев и даже утверждает: “Почему-то менее радужный сценарий представляется наиболее вероятным.”

Но похоже, что решение о необходимости автопилота кому-то очень выгодно – отсюда и заголовки типа “Больше половины водителей поддержали автопилот”.

Адские самодельные языки программирования

У [info]metaclass наметился срачик по поводу “самодельных” языков программирования. Естественно, вся прогрессивная общественность в едином порыве осуждает эту порочную практику. Я же хочу предложить взгляд на проблему с несколько другой стороны – а именно, начать с замечания о том, что деятельность программиста как нельзя лучше описывается фразой “разработка языков програмирования” и разобраться, к чему приведет эта посылка.

Разумеется, что она выглядит несколько провокационно. Поэтому придется ее несколько прокомментировать. Начну со своих личных впечатлений от изучения некоего подмножества Computer Science на мехмате МГУ. Студенты мехмата по отношению к этой науке делятся на две части – первым она дается легко и непринужденно, вторым – с большим трудом (но зачет эти вторые все же как-то сдают). Отличить первых от вторых можно по тексту тех программ, которые они пишут. В большинстве случаев студент, которому программирование дается легко, определит в программе какое-то количество функций и процедур, иногда – пару-тройку макросов для часто встречающихся конструкций, попытается разбить задачу на независимые части. Его не любящий программирование коллега скорее обойдется единственной функцией main().

В чем различие? Первый студент просто владеет главным методом процедурного программирования – “реши, какие требуются процедуры, используй наилучшие доступные алгоритмы”. Как только определен набор процедур для решения задачи – то мы просто пользуемся ими наравне со “штатными” средствами языка программирования. Например, в типичной для третьего курса мехмата задаче “обратить матрицу методом Гаусса” можно выделить следующие элементарные действия с матрицей – “вычесть из строки n строку m, умноженную на какой-то коэффициент” и “поменять местами строки n и m“. Если мы храним матрицу, как массив размера N*M, то логично будет написать макрос, вычисляющий индекс элемента an,m в этом массиве. В общем, реализовав несколько таких процедур, мы получим удобный “язык программирования” для работы с матрицами. Фактически, отличие “программиста” от “не-программиста” сводится к умению такой язык построить.

Каждый раз, когда мы выделяем повторяющуюся последовательность действий в “подпрограмму” – мы повторяем эту операцию. Хороший набор таких подпрограмм – это “библиотека” или “фреймворк”. Учебную задачу из предыдущего пункта вполне можно развить аж до полноценной системы линейной алгебры. От полноценного языка программирования она будет отличаться лишь использованием синтаксиса и управляющих конструкций языка реализации. Но никто не запрещает нам говорить, скажем, о языке “C с линейной алгеброй” – в конце концов, “стандартная библиотека” – это тоже часть языка, и расширяя ее – мы расширяем и язык.

Что же ограничивает программиста, который занят созданием такого языка? Его ограничивает только “расширяемый” язык. Скажем, если мы вдруг вспомним, что матрица – это линейный оператор, и операция называется не “умножить матрицу на вектор”, а “применить оператор к вектору” – то в случае языка типа C или Pascal мы попали, причем конкретно (это не говоря о том, что написать y = Ax мы все равно не можем, а можем писать лишь y = multiply(A, x)). C++ предоставляет новую возможность – определим Matrix::operator*(Vector) и слегка упростим себе жизнь. В более “абстрактных” языках программирования доступны и другие средства манипуляции с объектами из определенного нами языка, в том числе – делающие его действительно частью исходного (это возможно не всегда, приведу чисто “программистский” пример – при всем богатстве std::string в C++ мы не можем написать string s = "foo" + "bar").

Так или иначе, но “главный метод программирования” можно сформулировать в виде (спертом у [info]lionet):

Когда программист пишет модульную программу для решения задачи, он сначала разбивает задачу на подзадачи, затем решает подзадачи, и в конце концов объединяет решения.

…а затем прочитать продолжение:

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

Соответственно, если в проекте возникает необходимость в выделении какого-то “внешнего” по отношению к нему скриптового языка, то можно сделать простой вывод – “основной” язык недостаточно хорош и гибок. В подавляющем большинстве случаев – это ошибка при выборе этого языка (я сразу же исключаю из рассмотрения патологические случаи типа 3D-шутеров со сложными внутренними скриптами – как только в каком-нибудь Lua можно будет обеспечить быстродействие графики на уровне нынешних движков iD Software, Quake N+1 будет написан именно на нем).

Теперь выводы. Вместо того, чтобы заниматься разработкой “скриптового языка”, желательно попытаться описать API проекта – и сделать его доступным для всех желающих. Вариант второй. Если применение чего-то неповоротливого и низкоуровневого неизбежно (допустим, мы пишем Quake), а API хочется реализовать по принципам высокоуровневых языков – то следует разделить “механизм и политику”. При этом вся функциональность должна быть реализована на “удобном” языке. При этом в последнем случае всегда можно дать пользователям возможность менять код, реализующий ее – во всяком случае, при наличии большого числа высококвалифицированных пользователей или же при наличии у последних “крайне специфических” требований, это очень удобно.

Кстати, очень интересно выглядит в свете этого “десятое правило Гринспена” – про то, что каждая достаточно сложная программа на C содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp. Замените этот “глючный и медленный” Common Lisp на “настоящий” Lisp, Python, Lua, Javascript – да на все что угодно! – и получите огромное количество удобств. Выдайте пользователю REPL этого языка – и получите полноценный скриптовый язык в вашем приложении “малыми силами”.