Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

В продолжение темы о создании собственного USB-гаджета.
Создание простого устройства.

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

Разбираясь с обозначенной в заголовке темой, попутно обнаружил, что в рунете она раскрыта довольно слабо, хотя с момента представления данного протокола прошло уже много времени. Хочу слегка заполнить этот небольшой пробел, поделившись опытом.
Напомню кратко, что PubSubHubbub (PuSH) — это протокол, предложенный Google и призванный сделать более эффективным процесс доставки данных по каналам типа RSS от издателей к подписчикам. Центральное место в схеме, обеспечивающей работу протокола, отводится независимым хабам, выполняющим роль посредников между непосредственными источниками данных и конечными их получателями. При этом, хаб оповещает всех зарегистрированных у него подписчиков канала о поступлении новых данных сразу после их появления, одновременно передавая новую порцию данных.
Таким образом, если вы создаете приложение, занимающееся обработкой фидов в формате RSS или Atom, то можете заметно облегчить себе жизнь, возложив «черную» работу на хаб. Конкретные плюсы такой схемы:

• возможность «интеграции» множества внешних каналов в единый поток данных общего формата, поступающий на вход приложения: хаб может позаботиться об этом;
• отсутствие необходимости отделения новых данных от старых: хаб доставит только новые;
• не нужно постоянно отслеживать канал на предмет новых данных: хаб сам сообщит когда надо;
• минимальное время с момента публикации до момента оповещения вашего приложения.

Другими словами, вы можете получить оперативную доставку данных, заметно сэкономив как на объеме входящего трафика, так и на процессорном времени приложения. Для приложений на App Engine, ограниченных квотами, эти моменты могут оказаться принципиальными. Кроме того, вы сэкономите свое время, поскольку придется написать меньший объем несложного кода.
Ниже приведены минимально необходимые фрагменты кода на Java, которые были успешно мною опробованы на одном из хабов. Кода совсем немного и он несложный.

На написание этого опуса меня сподвиг данный пост, так как в нем некоторые моменты освещены недостаточно подробно. Ниже я опишу на собственном примере реализацию автоматической качалки торрентов с Lostfilm-а пр помощи FlexGet и Deluge. Все будет проиходить под Ubuntu 9.10

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Не первое десятилетие продолжается спор между архитекторами настольных приложений на предмет, какой же подход, statefull или stateless, более предпочтителен, и в каких случаях.
Сейчас мы наблюдаем определенный тренд сдачи позиций апологетами statefull. Не в последнюю очередь в этом виноват даже не столько web, сколько банальный HTTP, вполне заслуженно занявший нишу «универсального протокола для всего». Причем возможность передачи Cookie весьма слабо влияет на его насквозь stateless природу.

Но что HTTP может нам предложить, в случае необходимости создания интерактивного приложения на вебе? Для того чтобы достичь «реактивности» оффлайнового statefull приложения, классического варианта с постоянным опросом состояния сервера короткими AJAX запросами по таймеру явно недостаточно. HTML5 несет нам технологию WebSockets, призванную решить эту проблему. Но ведь нужно чтобы работало «здесь и сейчас» на всех браузерах выпущенных в текущем тысячелетии.

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

Итак, знакомьтесь. Клуб интеллектуальных игр «Трельяж»
trellis-club.com

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

Еще одной проблемой битторрента является частичная централизованность. Нет серверов — нет сети (DHT не в счет, т.к. не полностью самостоятелен). Очевидно, будущее за полностью децентрализованными сетями — сетями третьего поколения. Об одной из таких я и хотел бы рассказать.

Сказка

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

К счастью, транспортная компания (которая не удосужилась составить четкого расписание) содержит сайт, на котором в реальном времени с помощью Google Maps можно узнать, где сейчас находится тот или иной автобус. И вот в один прекрасный день Ваше терпение лопается и Вы садитесь писать скрипт, который будет отправлять ту желанную SMS-ку. Но все не так просто. Придется долго повозиться, чтобы по карте и маленькому кружочку на ней оценить скорость и время прибытия реального транспортного средства на Вашу остановку. Вы ведь не можете просто написать: «хочу получать SMS, когда вот эта точка попадет вот в этот прямоугольник на карте». Или все-таки можете?

Прошелся по закладкам и образовалась такая толстенькая подборочка ресурсов с бесплатными и качественными иконками, с которой спешу поделиться с тобой %username%!

Iconfinder

Уже было несколько статей, где авторы рассказывали о том как скрасить консольные будни с git. В последней приведенной ссылке автор предлагает создавать алиасы, для работы c git, непосредственно в shell. Это не очень хороший способ, хотя бы потому, что, например алиас gc будет конфликтовать с одноименной командой пакета graphviz. git сам прекрасно умеет работать с собственным алиасами.

Не так давно мы анонсировали на Хабре проект UniverTV, который был отлично воспринят Хабрособществом. Однако, было множество комментариев об отсутствии на сайте раздела «Информационные технологии»…

В HTML5 есть замечательный атрибут placeholder.

<input placeholder="inbox@disney.com">

Сейчас он работает только в webkit-браузерах (Safari, Google Chrome).

С помощью JS, не изобретая велосипедов, placeholder.js делает этот атрибут кроссбраузерным.

<input placeholder="inbox@disney.com" id="some_input">
<script type="text/javascript">
  inputPlaceholder( document.getElementById('some_input') )
</script>

placeholder.js (1.3 килобайта)

Хочу поделиться одним наблюдением, которое я сделал в процессе тренировки скорочтения (таким и таким способом).

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

Привычка разворачивать окно на весь экран идет, видимо, со времен первых мониторов с разрешением 640x480, где умещалось очень мало текста. Сейчас делать так совсем не обязательно. Причем и на стандартных 3:4 экранах, думаю, тоже можно ограничить ширину окна.

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

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

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

О новом планировщике задач для Linux на Хабре уже написали вот тут. Весьма эпатажный «трейлер» с xkcd к новому планировщику, и не менее веселый FAQ, пробудили интерес. Расспросил знакомых, кто ставил, чтобы поделились впечатлениями — никто не ставил, ибо «влом ядро новое ставить» или «я подожду, пока оно в мейнстриме появится». Поставил и попробовал сам, и для тех кто хочет сделать то же самое — краткое руководство для Ubuntu 9.04, с описанием потенциальных граблей.

В качестве тизера, скажу лишь, что полноэкранное видео на youtube действительно не тормозит и система стала отзывчивее и шустрее.

Итак, дабы не быть голословным, приступим. Предполагается, что у вас установлена Ubuntu 9.04 (Jaunty).

Задача

Итак, вам приходит макет, а в нём (о ужас!) блок картинок дизайнером старательно выровнен по обе стороны. Примерно так:

Ну в верстаем мы только резину!

Есть два варианта:
Сверстать без выравнивания, а дизайнеру сказать что по обе стороны выровнять нельзя, либо

Автор проекта и топика — TheShock, карму и благодарности слать ему.

Хочу представить вам альфа-версию нового проекта – console-like форума.

Комментариев будет мало — проект говорит сам за себя.

Адрес: http://freecr.ru/

Надеюсь, всем, здесь присутствующим, не составит труда разобраться в нем.


(по ссылке скриншот полностью)



P.S. Не забывайте, что это альфа-версия и потому возможна не совсем корректная работа.

В Кремниевой долине сейчас популярны встречи думающих людей которые собираются вместе и за 1-2 дня доводят свои идеи до прототипов. Возможно, вы что-то слышали о Yahoo! Hackday, Google Campout, SuperHappyDevHouse или DevCamp'ах.