Новости

В начале этой недели завершилась громкая история, связанная с похищением в Москве Ивана Касперского, сына Евгения Касперского, основателя и руководителя известной антивирусной компании.

Иван Касперский, 20-летний студент-программист, был похищен 19 апреля в Москве недалеко от места его работы в офисе компании матери, Натальи Касперской, которая некоторое время назад разошлась с мужем и руководит сейчас несколькими компаниями, также занимающимися вопросами ИТ-безопасности.

Как сообщают теперь правоохранительные органы, похищение организовала семья неких Савельевых - глава семейства Николай, его супруга Людмила и их сын Николай вместе с двумя его друзьями. Причина, по которой они пошли на такое преступление, банальна до невозможности. Оказывается, таким образом семья Савельевых хотела рассчитаться с взятым банковским кредитом!

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

За освобождение заложника похитители потребовали 3 миллиона евро. Следует отметить, что Евгений Касперский, закончивший в свое время высшую школу КГБ, сразу же обратился в правоохранительные органы. Те, в свою очередь, организовали крупномасштабную операцию по выявлению преступников и их обезвреживанию. В том числе, 22 апреля через СМИ была запущена дезинформация, что родители согласились отдать выкуп.

А 24 апреля похитителям была назначена встреча для передачи денег. В результате, пока вся семья Савельевых в полном составе ехала на эту встречу, их остановили сотрудники ГИБДД под видом проверки документов и спецназ произвел задержание.

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

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

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

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

Одна из важнейших драматических линий в этом фильме - противостояние Марка Цукерберга и братьев-близнецов Кэмерона и Тайлера Уинклвоссов. В свое время они заявили, что Цукерберг украли у них идею создания социальной сети и, естественно, потребовали за это солидную денежную компенсацию. В результате нескольких судебных тяжб такая компенсация им была выплачена. По условиям соглашения, которое было заключено в 2008 году, Уинклвоссы получили от Facebook в общей сложности $65 млн.

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

Но в этот раз братьям не повезло. Как сообщило издание Financial Times, 11 апреля федеральный апелляционный суд отклонил претензию братьев Уинклвоссов, в которой они требовали пересмотреть условия их мирового соглашения с Facebook. В качестве основания для отказа судьи отметили, что близнецы, подписывая предыдущее соглашение, консультировались с высококвалифицированными адвокатами, в том числе с их собственным отцом, специалистом по оценке имущества.

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

Максим СЕРЕБРОВ

Один из ключевых протоколов Интернета FTP (file transfer protocol) отметил свой 40-летний юбилей. Студент Массачусетского технологического института Абхай Бушан (Abhay Bushan) опубликовал первые спецификации RFC 114 16 апреля 1971 года, задолго до появления HTTP, и даже за три года до TCP (RFC 793)!

Простой стандарт для копирования файлов с годами начал поддерживать более сложные модели контроля, совместимости и безопасности (сейчас существуют различные расширения). Удивительно, но и спустя четыре десятилетия FTP нельзя назвать устаревшим, он до сих пор довольно широко используется. Даже с технологиями P2P старичок выдерживает конкуренцию. Чего стоит одна только функция FXP, принятая в 1985 году, с помощью которой по FTP можно копировать напрямую файлы с одного удаленного сервера на другой. Для своего времени это было очень круто.

За сорок лет FTP сумел устоять перед многочисленными конкурентами, в том числе fsp, scp, rsync, uucp, WAIS, gopher и ftpmail, хотя некоторые из них превосходили FTP по ряду параметров и имели лучший интерфейс.

На смену оригинальному RFC 114 пришел стандарт RFC 765 (июнь 1980), а затем RFC 959 (октябрь 1985), который действует до сих пор с учетом дополнений, касающихся поддержки IPv6 и SSL/TLS.

Поддержка криптографических протоколов была необходима, чтобы устранить самое слабое место FTP: изначально он не умел шифровать трафик и все данные, включая имена, пароли и команды, передавались открытым текстом и легко перехватывались сниффером. Один из вариантов решения этой проблемы - туннелирование через SSH или использование криптографических протоколов TLS и SSL, что предусмотрено стандартом FTPS (FTP Secure или FTP-SSL), описанным в RFC 2228.

FTP не думает уходить со сцены и продолжает развиваться. Например, сейчас обсуждаются расширения draft-ietf-ftpext2-hash по использованию хэшей для проверки целостности файлов и draft-peterson-streamlined-ftp-command-extensions с целым списком дополнительных команд, в том числе запрос уменьшенных копий изображений, операции с целыми ветками директорий со вложенными папками, запрос доступного дискового пространства, размера папки и ее содержимого.

Нынешний руководитель Google Ларри Пейдж во времена студенческой юности не был выдающимся программистом. Журналист и писатель Стивен Леви в своей книге "In the Plex" рассказывает об истории создания программ Backrub и PageRank.

Пейдж никак не мог добиться нормальной работы краулера и индексатора из-за большого количества багов в коде и еще по причине использования нового и нестабильного языка Java. Система все время падала и не годилась для реальной работы. В архивах ньюс-группы comp.lang.java за 1996 год сохранились вопросы Пейджа. Он пытается выяснить у знающих людей, как назначить User-Agent для заголовка HTTP.

Чтобы исправить многочисленные ошибки в коде, Пейдж обратился за помощью к своему другу, стэндфордскому аспиранту Скотту Хассану (Scott Hassan). Тот также был хорошим другом Сергея Брина, с которым познакомился на студенческих играх Ultimate Frisbee (бесконтактный вид спорта, когда игроки команды должны передать друг другу летающий диск).

Скотт Хассан говорит, что количество багов было слишком большим. Поначалу он попытался их исправить, но вскоре понял, что это бесполезная трата времени, поэтому переписал код на Python. В течение последующих двух лет Пейдж и Брин обнаружили, что новый движок можно использовать в вебе, и пытались лицензировать его Excite или Altavista, но неудачно. В итоге они приняли решение основать свою компанию.

Подняв собственный сервер, молодая компания вскоре столкнулась с проблемами масштабируемости. Питоновский код обрабатывал не больше десяти запросов в секунду, так что некоторые пользователи вообще не получали ответа от сервера. Новый сотрудник компании Google, профессор Урс Хельцле (Urs Hulzle), был гораздо профессиональнее в с области разработки. Он в очередной раз переписал код с нуля, уже на C++.

Конечно, впоследствии компания наняла на работу еще больше программистов высочайшего уровня. А сейчас поисковая система Google представляет собой образец самой масштабируемой и высокопроизводительной системы в мире. Но к нынешнему состоянию компания шла многие годы, постоянно переписывая и улучшая систему. Все это время главным драйвером успеха была идея использования PageRank для ранжирования веб-страниц, в успехе которой Пейдж был, судя по всему, уверен на 100%. Его знаний Java хватило, чтобы написать кое-как работающий прототип и проверить идею, а остальное уже было делом техники (стартовый капитал и хорошие программисты).

Хотя свободных адресов IPv4 у ICANN больше не осталось (последние блоки /8 были отданы 3 февраля 2011 года), доля трафика по протоколу IPv6 в Интернете составляет всего 0,25% [Arbor Networks]. Хуже того, за последние шесть месяцев объем трафика IPv6 уменьшился в относительном выражении на 12%, тогда как трафик IPv4 вырос на 40-60%. Интернет-провайдеры продолжают извращаться с NAT, игнорируя IPv6. Это удручающий результат, учитывая, сколько усилий пришлось положить на продвижение IPv6 за последние пятнадцать лет.

Специалисты Arbor Networks считают, что неприятие индустрией стандарта IPv6 связано с техническими проблемами и сложностями в дизайне сетей, отсутствии экономических стимулов и нехватке контента IPv6.

Крупнейшими приложениями IPv6 являются пиринговые сети, которые обеспечивают 61% всего объема данных, передаваемых по IPv6. Для сравнения, в сетях IPv4 пиринговые сети обеспечивают всего лишь 8% трафика, то есть мы видим явную диспропорцию, которая указывает не незрелость остальных приложений IPv6. Трафик по HTTP составляет 19% для IPv4 и 4,6% для IPv6. Онлайновое видео (Netflix, YouTube и т.д.) - почти половина трафика IPv4 и абсолютный ноль для IPv6. Это довольно ироничная ситуация, потому что Netflix.com - один из немногих крупных сайтов, доступных в адресном пространстве IPv6.

Компании и частные пользователи, чьи интернет-провайдеры не поддерживают IPv6, могут использовать туннелирование. Специалисты Arbor Networks за 24-часовой интервал в один из дней в феврале обнаружили в Интернете более 250 тыс. таких туннелей. Более 90% из них обслуживались пятью крупнейшими брокерами, включая Hurricane Electric, Anycast и Microsoft Teredo.

3 февраля 2011 года корпорация ICANN распределила последние пять блоков адресов IPv4 региональным регистраторам, и вот сейчас пришло время, когда адреса начинают заканчиваться уже у них. Так, 15 апреля начал раздавать последний блок /8 азиатский центр Asia Pacific Network Information Centre. Он теперь выдает максимум по 1024 IP-адреса в одни руки. По прогнозам, до конца нынешнего лета все регистраторы начнут делать так же.

Готов ли Интернет к переходу на IPv6? Скоро мы это проверим. На 8 июня назначен Международный день IPv6, когда состоится глобальный стресс-тест сетевой инфраструктуры на максимальную нагрузку IPv6-трафиком. Об участии в тесте уже объявили Facebook, Google, Yahoo, Akamai, Limelight Networks и Internet Society. В этот день все они включат IPv6 в своих основных сервисах на 24 часа.

Texas Instruments выпустила чип для беспроводного приема электроэнергии, который называет не иначе как "революционным". Микросхема bq51013 миниатюрна (корпус 1,9 х 3 мм), дешева ($3,50 в количестве от 1000 штук) и обладает КПД до 93%, что сравнимо с обычными AC/DC-адаптерами.

По мнению производителя, технология наконец-то созрела для применения в любых электронных устройствах: мобильные телефоны, MP3-плееры, цифровые камеры, игровые приставки, GPS-навигаторы, пульты Д/У, электрические зубные щетки, автомобильные аксессуары, медицинское оборудование и т.д. Зарядное устройство bq51013 выдает мощность 5 Вт, входное напряжение - до 20 В.

Приемник bq51013 размещается на печатной плате bqTESLA150LP размерами 15 х 5 мм. Это вполне приемлемые размеры для любой даже самой портативной электроники.

Сейчас Texas Instruments рассылает образцы микросхем и комплекты SDK (ресивер bq51013 вместе с контроллером передачи bq500110) для производителей устройств. Можно надеяться, что очень скоро беспроводная подзарядка станет общепризнанным стандартом.

Красивый сервис Hashify.me берет контент веб-страницы и хэширует его в URL. В результате вы получаете огромную ссылку, в которой закодирован текст и картинки. Эту ссылку можно пропустить через Bit.ly - и получите короткую ссылку. На самом деле на сайте Hashify уже поддерживает интерфейс Bit.ly API, так что короткая ссылка генерируется автоматически.

Создатели Hashify обошли ограничение Bit.ly на максимальную длину URL в 2048 символов. Документы большего размера они просто разбивают на куски в Base64 (до 15 штук), которые посылают в Bit.ly единым запросом. Ответ затем хэшируется в Hashify и снова отправляется в Bit.ly, так что на выходе получается одна-единственная ссылка. Таким образом, Hashify может генерировать короткие ссылки для документов длиной примерно до 22500 символов.

Редактор HTML-страниц Hashify поддерживает не только текст, но и нормальное форматирование, списки, заголовки, изображения.

На практике это можно использовать, например, для трансляции больших текстовых сообщений в Twitter. Но создатели сервиса искали не практического использования. Они проверяют саму концепцию, что веб-страница = URL. При этом Bit.ly используется для кэширования и раскодирования контента.

Анатолий АЛИЗАР

Reuters, ссылаясь на некие анонимные источники, утверждает, что запуск облачного музыкального сервиса компании Apple уже не за горами. Причем Apple планирует запустить свою новую онлайновую службу раньше Google, которая сейчас готовит аналогичный проект.

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

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

Точную дату запуска нового облачного сервиса информационное агентство не сообщает. Однако Reuters утверждает, что Apple почти наверняка удастся обогнать Google.

Александр СНЕГИРЕВ