Два года назад, работая над Awesome, я присоединился к разработке XCB, который является частью инициативы Freedesktop. Мне пришлось изучить тайны протокола X11 и весь древний и таинственный мир, окружающий его.

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

13 мая компания CloudMade (со-основатель компании — основатель OpenStreetMap Стив Кост) объявила о новой open source JavaScript-библиотеке для любых карт под названием Leaflet.

Как написал Mourner (он же на Хабре — Mourner), автор этой библиотеки, живущий в Киеве (кстати, он будет рад услышать отзывы и ответить на ваши вопросы на форуме OpenStreetMap и здесь на Хабрахабре):

«Leaflet задумана как библиотека, одинаково хорошо работающая и на десктопных браузерах, и на мобильных устройствах (iPhone/iPad, Android) — очень быстрая, легковесная, с простым API, красивым и понятным ООП-кодом. В отличии от OpenLayers (самого популярного выбора на сегодняшний день) мы не пытаемся впихнуть в нее все фичи, о которых только можно помыслить, раздувая код до немыслимых размеров — только самое основное, минимальный набор, который удовлетворяет нужды 99% применений карт в онлайне (тайлы, маркеры, векторы, попапы), но реализовывая их максимально лучшим образом.»

После покупки своего первого смартфона люди обычно замечают, что расходы на мобильную связь немного увеличиваются. Обычно это происходит за-за того, что «умный» телефон «ходит в Сеть» без ведома хозяина. Конечно, решить эту проблему просто — установить специальные утилиты для блокирования подключений к точкам доступа GPRS/HSDPA либо купить безлимитный тариф на доступ в Интернет и забыть. Столкнувшись с описанной ситуацией, я в первую очередь заинтересовался и тем, что телефон ищет в Сети и, самое главное, что передает в Сеть. Последнее особенно актуально в связи с недавними новостями.

Собственно идея летает давно и начала свои корни с публикации компании backblaze как сделать дешевое петабайтное хранилище.

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

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

Продолжим настройку нашего шлюза, про который я говорил в предыдущей статье. Напомню, там мы настроили правила маршрутизации, теперь нам надо заняться iptables. Сейчас мы настроим сеть состоящую из шлюза и сервера. На шлюзе будет работать SSH и DNS, а сервер у нас будет виндовый на нем у нас RDP и SMTP. Сеть будет настроена таким образом, что через любой из внешних айпишников мы сможем подключаться к любому из серверов, а SMTP сервер будет выходить наружу через основного провайдера.

Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

По сути Synergy является кумулятивным Open Source расширением Spree, ориентированным на создание интернет-магазинов в России.
Миссия проекта состоит в том, чтобы предоставить весь необходимый фунционал, специфичный для российских интернет-магазинов, а также упростить интеграцию рекомендуемых расширений.

В свою очередь Spree – это полнофункциональная платформа электронной коммерции, работающая на фреймворке Ruby on Rails 3. Она создана с целью упростить разработку интернет-магазинов путем включения в нее всего базового функционала, необходимого разработчикам.

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

Сформулируем определения и задачу.
Графом будем называть несколько точек (вершин), некоторые пары которых соединены отрезками (рёбрами). Граф связный, если от каждой вершины можно дойти до любой другой по этим отрезкам. Циклом назовём какой-то путь по рёбрам графа, начинающегося и заканчивающегося в одной и той же вершине. И ещё граф называется взвешенным, если каждому ребру соответствует какое-то число (вес). Не может быть двух рёбер, соединяющих одни и те же вершины.
Каждый из алгоритмов будет решать какую-то задачу о кратчайших путях на взвешенном связном. Кратчайший путь из одной вершины в другую — это такой путь по рёбрам, что сумма весов рёбер, по которым мы прошли будет минимальна.
Для ясности приведу пример такой задачи в реальной жизни. Пусть, в стране есть несколько городов и дорог, соединяющих эти города. При этом у каждой дороги есть длина. Вы хотите попасть из одного города в другой, проехав как можно меньший путь.

Произошло то, чего многие ждали давно и, фактически, уже имели: музыку теперь можно слушать бесплатно, но при этом абсолютно легально.
В рамках комплексного обновления старейшего легального магазина www.Fidel.ru появился новый тариф «Открытый». Теперь каждый зарегистрированный пользователь может абсолютно бесплатно, легально и всегда слушать любое количество музыки с битрейтом 320 кб/сек без рекламы и чего-либо надоедливого!

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

Выступление Стива Рамбама на конференции Hackers On Planet Earth (часть I)

Это выступление Стива Рамбама на последней конференции H.O.P.E. (Hackers On Planet Earth)

Стив выступает на каждой хакерской конференции H.O.P.E. с 1994 года.
Если вы не знаете про Стива и не видели его выступления — обязательно посмотрите это видео.

Покажите его тем, кто плохо знаком с миром IT: бухгалтерам, продажникам, маркетологам…
Обычным людям.

Видео с русскими субтитрами на Universal Subtitles
(хабр не позволил вставить скрипт):
Ctrl+ www.amara.org/ru/videos/YSEgofMg2wgv/info/steven-rambam-privacy-is-dead-get-over-it-part-1

Это же видео без наложенных субтитров, для англоговорящих:

Вполне понятно, что факт покупки ссылок доказать сложновато. И речь не об этом. Уже несколько месяцев мы наблюдаем, как теряют свою эффективность в продвижении под Яндекс молодых проектов ссылки с бирж и внешние факторы поисковой оптимизации в целом. И это очень радует.

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

Об этом говорят и сам Яндекс и специалисты в области продвижения сайтов.

«Молодые» — это не те, доменам которых меньше полугода. Это сайты без «истории»: наработанной статистики для конкретных веб-документов, с небольшим возрастом страниц, числом полезных ссылок на эти документы и прочего.

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

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

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

Не секрет, что работу с профилями пользователей в Django иначе как несчастьем не назовёшь. Все мы сталкивались с монолитностью модели auth.User, неадкеватным набором полей у неё, а также всеми теми ухищрениями, к которым приходилось прибегать.

Извращаться приходилось всем: не только пользователям джанги, но и самим её core-разработчикам. Помните, например, как в Django 1.2 внезапно стало возможно использовать в поле username символы собаки (@) и точки? Знаете зачем? Чтобы в качестве логинов можно было использовать адреса e-mail.

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

В первой своей статье «измерение расстояния до объекта и его скорости» я рассмотрел захват изображений с веб-камер через Video4Linux2 и через DirectX. В следующей статье «захват видео с сетевых камер, часть 1» я рассмотрел как работать с сетевыми Motion-JPEG камерами. Сейчас я поведаю Вам о захвате изображений с сетевых RTSP камер, в частности поток Motion-JPEG по RTSP.

Задача эта более сложная нежели Motion-JPEG по HTTP, так как необходимо больше действий, больше подключений, но взамен мы получаем большую гибкость, скорость, функциональность и даже некую универсальность. Честно говоря, RTSP для простых задач избыточен, но я не сомневаюсь, что найдутся ситуации, где он будет необходим.

Виртуальные игры занимают все более важное место в жизни современных людей. Основатель SCVNGR говорит, что игры везде и всюду станут следующим феноменом, который повлияет на жизнь так же, как это сделала социальная революция в интернете. Мы хотим сделать освоение иностранных языков эффективной и увлекательной игрой. Сегодня вышел новый релиз LinguaLeo.ru. Долгожданное обновление затронуло большую часть сервиса, и главное — стало больше игровой динамики, которую так любят пользователи. Изучение иностранных языков должно быть занимательным, и вам скучно не будет! Играя в английский, зарабатывайте очки опыта, проходите задания-квесты, получайте игровые звания и повышайте уровень развития своих питомцев.

Hello everyone!

Все мы знаем что Django — очень мощный и динамично развивающийся фреймворк для создания веб-приложений. Однако, несмотря на наступление эпохи Веб 2.0, в нём всё ещё нет встроенных механизмов для работы с AJAX, в частности отправки и проверки форм. Возможно django просто не хочет навязывать пользователю какой-то js-фреймворк и хочет оставаться гибкой в этом вопросе, но так или иначе при разработке часто требуются формы, работающие через ajax, без перезагрузок страниц.
О создании таких форм и работе с ними и пойдёт речь в данной статье.

Сразу оговорюсь, что идея не нова, и существует несколько библиотек, реализующих требуемую функциональность, например одна из них — http://www.dajaxproject.com/.
Для тех же, кто предпочитает сам управлять взаимодействием клиента с сервером или тех, кто не хочет втягивать в проект дополнительную библиотеку и иметь дело с её багами, я расскажу как изобрести велосипед реализовать механизм самостоятельно и опишу различные способы решения проблемы.

0. Intro.

Ситуация следующая. Есть винт на 160Гб. На нем 2 раздела — 40Гб и 120Гб. С целью установки убунты как второй системы была произведена разбивка 120Гб -> 100+10+2+8.

Далее, с целью отката изменений, были объединены диски (10, 2 и 8) обратно в один 20Гб и отформатирован в NTFS. В нагрузку к этому, были проведены операции с MBR, результатом которой явилась ее смерть.

Итоги

1. При загрузке системы выводится сообщение MBR helper not found;
2. fdisk показывает один большой 160Гб диск.

Дураку понятно, что это начало веселой ночи.
Далее, под катом, решения вопроса.

Вчера столкнулся с небольшой проблемой — на машине с Win2k3 установлены 2 сетевых карты, 2 провайдера. Проблема оказалась следующая: подсети пересекаются (точнее — совпадают). Было решено использовать за основной шлюз 1го провайдера, а по внутрисетевым ресурсам гулять — через 2го. И всё бы ничего, но машина должна обслуживать входящие соединения с обоих интерфейсов. Но, благодаря статическим маршрутам, ответы на запросы из подсети 10.0.0.0/8, пришедшей со стороны первого провайдера уходили через канал второго провайдера, что было, мягко говоря, не тем, что нужно. Как решить эту проблему под линухом — я знал (и тоже поведаю в этой заметке). Немного погуглив был найден вариант решения (в msdn'e наткнулись на управления приоритетами соединений). Коллега (WAJIM, привет) подумал — и нашёл 2й вариант. Потом немного (совсем немного) подумал я — и по аналогии появился 2й вариант решения для линуха :)
Итого, под катом вас ожидает 4 варианта решения задачи маршрутизации по 2м провайдерам — 2 под виндовс и 2 под линукс.

Есть замечательная статья, в которой рассказывается, как это делается на Cisco. Но мы не хотим тратить $100500 на приобретение штампованных оттисков «Cisco Systems» на корпусе маршрутизатора.

Описание проблемы

Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.

Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.

Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.

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