January 2008 Archives

Несколько дней назад, когда мы с уважаемым reedcat@lj собрались за стаканчиком, он рассказал мне хороший анекдот про Носика и оказался прав. Я понимаю, что Носик - занятой человек, и читать то, на что он ссылается, ему некогда. Вот он и занес меня в расстрельные списки Вербицкого. Что я могу сказать? dolboeb.

Впрочем, я не сильно бы переживал, если б я действительно был в том расстрельном списке. Я только отказываюсь быть в нем на одной строчке с Мариной Литвинович. Миша, может быть ты перепишешь меня на отдельную страничку? :)

А в Йоханнесбурге лето. Cолнце, зелень, небо южнополушарное. После Москвы контраст потрясающий. И dolboeb'ы в 10000 км отсюда. Не может не радовать.

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

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

На этом жена успокоилась, а я пошел читать ЖЖ деятеля (нет, ник не скажу, пусть останется в тени). И чего вижу? Записи про прививки, конечно же, а еще рак мозга от мобильных телефонов и доморощенную кустарную теорию про почему WTC мог взорвать только сами американцы. Говорю: "Дорогая, это ж натуральный фрик, причем мультифрик. Попомни мое слово, он тебе про Фоменко еще расскажет". Напоминаю, Маринка - искусствовед, историк искусства, закончила истфак. Та посмеялась, и на этом разговор закончился.

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

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

К предыдущему посту. Еще немного keywords.

MUST+    Если вы это не реализуете, мы придем к вам с дубинкой и научим читать RFC.
MUST+-   Надо реализовать эту фичу или по крайней мере сделать вид, что она реализована.
MUST-+   Мы в нерешительности между MUST и MUST NOT.
SHOULD+? Мы бы очень хотели, чтобы вы это реализовали, т.к. без этого все сломается. Но мы знаем, что вы затрахаетесь это делать.
MAY--   Если хотите, вы можете это сделать, но ваши пользователи вас проклянут. И не говорите, что мы вас не предупреждали.

Дополняйте. Потом переведем и засабмитим как настоящий первоапрельский RFC.

Первое апреля в этом году наступило неожиданно.

Some document authors want to express requirement levels using the traditional definitions of "MUST" and "SHOULD" from RFC 2119, but also want to express that there is an expectation that later versions of the document may change those requirements. For example, they may want to express "this SHOULD be implemented now, but we expect that this will become a MUST requirement in a future update to this standard". This document defines three new keywords, "MUST-", "SHOULD+", and "SHOULD-" to facilitate such definitions.

http://tools.ietf.org/html/draft-hoffman-additional-key-words-00

Я бы сказал, это doubleplusgoodthink. Огромные просторы открываются.

Я всегда знал, что это враги. Но это уже вообще за рамками.

Network Solutions is under fire this week for domain "front running," or for purchasing and holding certain domains after they're searched for at the company's website, thereby not letting anyone buy the domain at other registrars. For example, should you be in the business of eating aardvarks and try to search for the availability of the domain eataardvark.com at Network Solutions, the website will show you that it's available.

Within seconds, Network Solutions subsequently registers the domain for five days, preventing users from buying it anywhere other than Network Solutions. Places where, in many instances, you might be able to get a better deal should you want to shop around.

http://www.dslreports.com/shownews/Network-Solutions-Holding-Domain-Names-Ransom-90862

Мало того, что это злодейство, это еще глупое злодейство. Ибо не достигает декларируемой цели защиты от сквоттеров и фронраннеров.

Сижу на кухне ужинаю. Подбегает ко мне дочка, ей 2 года и 8 месяцев, и ласковым голосом молвит: "Папа! Сходи к бабушке и принеси мне, пожалуйста, книжку про Люцифера".

Я чуть не подавился. "Что же это за книжка про Люцифера?", - спрашиваю. "Тебе бабушка читает про Люцифера?". "Да", - отвечает дочь - "бабушка. Мне очень эта книжка нравится".

Ну, думаю, тещу чего-то занесло. Как-то не по возрасту оно ребенку. Да и что именно можно читать про Люцифера? Вульгату, там где про вавилонского царя? Потерянный рай Мильтона? The Book of Mormon? Malleus Maleficarum - Молот ведьм?

Хорошо, догадался спросить у дитенка, кто же такой этот Люцифер. Оказалось, что это кот. Теща купила внучке книжку по мотивам диснеевских мультиков. Там и оказался такой персонаж в сказке о Золушке.

Давным-давно в беседе на IRC с одним коллегой из циски я сказал, что BGP - давно уже не только и не столько routing protocol, собеседник помялся-помялся, но согласился. Сейчас вот мне эта беседа чего-то вспомнилась и я решил написать немного подробней.

Почему же BGP не только routing protocol. Дело в том, что этот замечательный протокол давно уже приспособили для переноса очень разной информации (я как-то упоминал отличный Google Tech Talk с Яковом Рехтером - он там про это немного говорит). Действительно: QoS Policy Propagation, BGP-based VPLS, autodiscovery всех типов, you name it. То, что нынче ездит по BGP, с трудом можно назвать "маршрутом". Т.е. в современной сети BGP (iBGP, если быть точным, с eBGP есть ) - это не просто способ донести какие-то маршруты отсюда досюда, а универсальная инфраструктура для распространения практически произвольной информации в сети.

Рехтер утверждает, что BGP делает это эффективно. Я почти согласен. BGP, как инфраструктура распространения произвольной информации, очень хорош: можно переносить практически все что угодно, ограничений на количество переносимой информации практически не существует (важна частота изменений, но не само количество), можно всячески фильтровать, кто хочет, тот эту информацию слушает и хранит, а кому какая-то не информация не нужна - так не слушает и не хранит. Все здорово. Почти.

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

Дело вот в чем. Когда появляется очередное приложение BGP, разработчики протокола берут AFI/SAFI, изобретают NLRI с какой-то структурой, возможно придумывают еще один-два extended community со специальной семантикой - и вперед.

Естественно, для того, чтобы новый address family заработал, надо, чтобы его понимали оба BGP пира - ведь если один не понимает этот AF, то эта информация ему и не нужна. Казалось бы, логично. Но нет. Есть исключение - route reflectors. Им на самом деле пофигу на address family, их роль проста - принять анонсы, прогнать BGP decision process и раздать анонс, а что внутри, им по барабану. В нынешней схеме для поддержки новой address family приходится апгрейдить и конфигурить route reflector'ы  - во-первых лишняя, а во-вторых рискованная работа: баги, недосып, похмелье, кривые руки.

Что бы спасло положение? Wildcard address family capability. Все просто: отдельный AFI/SAFI для использования в capability advertisement и небольшое дополнение к decision process, типа просто пояснение о том, как его делать на неизвестном типе NLRI.

Написать драфт, что ли?

19:01 < avn> aadz_home: kill -9 -1
19:05 < user__> avn: а что предполагается должна делать дефективная команда
                "kill-9 -1"?
19:05 < avn> а ты попробуй ;)
19:05 < avn> в мане это кстати написано ;)
19:05 < user__> могу попробовать и заранее скажу, что будет - абсолютно ничего
19:06 < user__> во-первых, Вы хотите именно процесс "-1" убить?
19:06 < avn> ну если ничего _важного_ не делаешь ;)
19:06 -!- user__ [n=user@ppp85-140-242-99.pppoe.mtu-net.ru] has quit [Remote
          closed the connection]