Это субжурнал для netch по тематике IT. Все вопросы - к оригиналу.

Старый принцип: чтобы настроить сеть на не-маршрутизаторе, надо знать IP адрес, маску и шлюз.
Новый: к этому добавилось MTU.
Ибо на первом 1500, на втором 2044, на третьем 4000, на четвёртом 9200.
Кто-то, может, в этом мире живёт давно, но мы влетели на днях.

Никакие способности софта держанию нагрузки не работают, если поток поступает быстрее, чем приёмный процесс вообще способен его принять. Если регулировки потока нет и должны всё принимать, система будет неустойчива и будет выходить в турбулентный режим при переполнении некоторого уровня нагрузки. И неважно, Erlang это или что-то другое: или есть механизм ограничения приёма, потока, или система идёт вразнос.

Жизнерадостное игнорирование этого фактора - основная причина неадекватного поведения наших ранних версий.

А один общий mailbox процесса на все случаи приводит к тому, что управление потоком надо или делать через порты (в частности, выводя толстые потоки в TCP/SCTP/etc., даже если взаимодействуют ноды в кластере), или уметь явно говорить отправителю остановиться. Если бы было несколько очередей, с возможностью настройки каждой из них - можно было бы делать умнее; но сейчас - любое решение получается некорректным.

А существующие костыли закономерно повторяют старые добрые методы работы с очередями, реализованные в маршрутизаторах, начиная с Cisco. Только вот и они не помогают, когда процесс задумался непонятно о чём, а во входной очереди у него 730 тысяч сообщений. Здесь не кран надо менять, а всю систему.

Хочу много очередей с политиками. Размер очереди, простой дроп при заполнении, RED, GRED и так далее. Интересно, NIF'ами это можно сделать? Так, чтобы работало между нодами?

Падает енода из-за того, что ETS таблица раздувается до 3GB, а на всю еноду целиком отведено 4GB.
На раздувание от старта до такого падения нужно около трёх минут.
И это всё на нужных и законных данных.

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

Из Infiniband Architecture Specification:


When initially powered up or reset, the value of all counters contained in PortCounters on all ports of a node shall be set to zero. During operation, instead of overflowing, they shall stop at all ones. At any time, writing (Set) zero into a counter shall cause the counter to be reset to zero.


Это - остановка по достижению предела, сброс только в ноль, отсутствие атомарного чтения и сброса - сделано одинаково и для 32- и для 64-битных счётчиков, только предел разный.
Вопрос: кто может мне объяснить глубокий смысл такого решения?

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

А то злой Кориолис мешает нарезать правильные траектории.

Когда вижу Karnaugh map, всё время хочется прочитать фамилию как "Карнаух".

В свежем daily security check output домашней машины обнаружились попытки подбора ключей по sshd. Удивился, проверил файрволл. Как и ожидал, там в принципе эти попытки допускаются для ограниченного количества хостов.
Просмотр /var/log/auth.log показал, что они были 5 лет назад, а ротацию лога я куда-то потерял.
Вернул ротацию и думаю, хорошо ли это, что система не менялась тут с 2001-го года (только апгрейдилась).

Который день подряд на secondary.net.ua идёт плотный поток запросов такого вида:

12:15:09.140941 IP 80.82.164.10.55750 > 195.149.112.1.53: 64562 A? ne08fwoeuhifn0ij.org. (38)
12:15:09.141387 IP 195.112.238.35.53418 > 195.149.112.1.53: 22014% [1au] A? nw98efhupnc98dshvui.org. (52)
12:15:09.141398 IP 91.143.63.9.49030 > 195.149.112.1.53: 27265 [1au] A? bef8iewuhfb.org. (44)

Знаю, что это какой-то троян, который через хэш получает доменное имя для центра управления, имя меняется каждый день. Конкретный троян неважен, их таких уже толпы.
Но имя зарегистрировано в DNS якобы с NS'ами primaryns.kiev.ua и secondary.net.ua и на обоих такая зона отсутствует.

Если кто-то убьёт бесплатный DNS, так это будут трояны.

Обнаружили, что там, где мы раньше просто передавали счётчик в 8 байтах, надо передавать ещё два значения — типа "ошибка снятия" и "отсутствие источника". Расширять некуда — грубо говоря, это embedded, протоколы и форматы в общем установлены. Но параметры не так быстро растут, чтобы переполнить 64 бита.

Так что выдвинул на внутреннее обсуждение предложение: "на ходу" сократить его до 63 бит, а случай старшего бита равного 1 применить на спец-значения. Вот жду до понедельника, будут ли фатальные возражения...

Чувствую себя сотрудником Microsoft — согласно уровню извращений — заказчикам тоже придётся перестраиваться (хоть и не срочно).

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

(А этот open64 забавный - у него мозги устроены совсем иначе, чем у gcc и clang.)

Если Воля слишком устойчиво работает, то динамический адрес долго не меняется и DynDNS начинает присылать предупреждения, что акаунт, вероятно, неактивен.

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

Наконец выяснили у автора. Один раз в 12 (прописью: двенадцать) часов.

Чему равно 84/5, если 8*8 = 54?

отсюда

В старой форме приходилось отвечать с заведомой натяжкой. Тут такого нет.

Отличный пример того, как происходят прорывы вроде бы в давно изведанных областях.

Гарантированно устойчивое O(n log n), с отличным постоянным коэффициентом и стабильным порядком. Хотя реализацию на пальцах не объяснить.

С гуглом творится что-то непонятное.

Сначала они начали спамить напоминаниями про new look, на который всем надо срочно переключаться, а не то ой. Посмотрел, отплевался, переключился обратно. По-моему, этот new look хорош только для планшетов, но мне он на десктопе не нравится. Написал им "уберите эту гадость" и теперь игнорирую предложения.

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

Сегодня мне напоминание про ежедневное событие пришло с указанием, что оно в 15 часов, хотя пришло в 14. В вебе календаря написано, что у меня GMT+3 и это Киев. Ладно, переставляю на 14. Сохраняю. В списке снова написано оно в 15 часов...

По-моему, его тоже съели венчурные инвесторы и пора срочно искать что-то новое.

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

Да, это проходной пост дежурной ненависти.

В связи с этим (как-то сия феерическая дискуссия прошла мимо меня) и рассказом про "тупые HOWTO с лиссяры" вспомнил разборки совсем недельной давности.
Есть один дружественный провайдер co**.net, к которому я регулярно хожу в гости на рюмку чая, где работал K+1 год назад и где у меня есть шелл. (Кто знает, тот уже понял, о ком речь.) В этот шелл регулярно попадают строки лога из ipfw, задалбывают.

Выжимка из диалога с сисадмином тазика.

Я: а это действительно надо чтобы на z*** сообщения о том, что его спрашивают по ntp, сыпались всем на экраны?
А: Там на таз идёт немерянный поток udp пакетов, в среднем 8000-10000 пакетов в секунду. Это не временно. Это давно и постоянно. Если ничего не делать, то на сервере невозможно работать - всё рывками. Поэтому у меня там сделано так: ipfw в лог пишет информацию обо всех udp пакетах на порт 123. И запущен скрипт, который добавляет в файрвол запрет для IP адресов, с которых пришло более 50 udp пакетов в минуту.
А: Вообще не понятно, откудя такая активность? Может это вирусня какая-то? Но что им нужно от ntp сервера?

О как. Стало интересно. Проверил по ntp.org. Такого нет. Тогда решил ввести hostname в поиск... и что я вижу? Сотни, нет, тысячи копипаст одной и той же хаутушки "как сделать время на сервере", в которую вбиты конкретные хосты без каких-то предупреждений типа "не пробуйте использовать это за пределами Киева".
Вбил его IP - то же самое. И таки где одна из первых копий? Ну конечно, на лиссяре.

(Если кто угадает с обоснованием в комментариях, о каком адресе речь, перенесу в основной постинг. Я не секретюсь до предела, но не хочется, если не просили.)

Далее пошло обсуждение того, как надо это лечить. Я предлагал жёсткие меры разного уровня радикальности. Например, отдавать всем за пределами сети провайдера время 5-летней давности или, наоборот, 25 декабря 2012 года. Или чуть помягче, например, каждые сутки на секунду медленнее, чтобы постепенно накапливать эффект. Но тот админ, похоже, страдает чрезмерным гуманизмом, и эти меры не были приняты.

Вот вам и вред от таких хаутушек - 10K левых запросов в секунду совершенно непричастным.

OpenOffice (libre или нет, неважно) упорно приближается к винде. В Impress случайно зацепил и перетащил панель Slides, она стала отдельным окном. Перетащить обратно - не становится панелью, в контекстном меню ничего нет, закрытие/открытие и перезапуск не помогают, в меню и диалогах настройки нет. Гугл молчит. Греп по конфигам в хомяке не нашёл ни одного подходящего слова.
Только локальный патч Бармина в виде rm -rf ~/.config/.libreoffice помог.

Как-то страшно теперь с ним связываться, вдруг ещё чего выкинет. Чувствую себя начинающим виндомороном.

UPD[2011-10-07]: похоже, он особенно не подружился именно с WindowMaker. Логика должна срабатывать при перемещении окна slide pane над основным, и это не детектируется. Но независимо от проблем WM, я думаю, что это должно настраиваться.

Был только на первом дне, впечатления разнообразные и неровные.
Ну девочек с рекламой описывать не буду, и так вся сеть в фотках. (Но на IT мероприятии я такого ещё не видел.)
Доклады нескольких видов. Заумь (включая мой - я только там увидел, насколько мы страшно далеки от основного народа). Несколько нормальных. Специально привезённые звёзды (по слухам в кулуарах, им бешено платят). Основная масса - муть или что-то сверхстранное. Например, от Mamba я ожидал более технического рассказа, а не прописных истин вроде "ломать надо в первой половине дня" (кто работал с телекомами, для тех это не новость, а прописные азы) или "саппорт должен быть качественный". Google тоже мутный, я еле удержался от едких вопросов "если вы такие моцные, то почему огромные проблемы надо решать через знакомых, а не штатные средства". Лапшин+erlyvideo, говорят, каждый раз слово в слово.
Много NoSQL, интересно, что не было ни одного доклада в стиле "ваши проблемы детские, мы с Postgres/MSSQL/Oracle такое решили K лет назад". Надо это ввернуть в качестве аргумента сторонникам реляционок:)
Низкоуровневая оптимизация C/C++ (не слушал, читал презентаху) - сборник очевидностей для тех, кто хотя бы по диагонали читает RSDN и аналоги, но для многих стало откровением. Значит, доклад таки полезный.
По рассылке почты - "у меня для вас посылка, но я вам её не отдам, потому что у вас документов нет." (Всё сказанное тривиально, всё нетривиальное скрыто.)
По самопальным HTTP серверам - комментарий Сысоева: "ну вот, логический круг замкнулся - были треды и FSM, а теперь есть и сопрограммы". Я хотел было влезть с вопросом "а каковы ваши перспективы в плане того, что все M:N, scheduler activations и прочее - вымерло нафиг", но пожалел докладчика;)
Что очень хотел послушать - вычислительная инфраструктура (Mirantis) и гипервизоры (Parallels), будем иначе изучать.
Никто не парился правами на картинкооживляж (было всё начиная от Симпсонов).
Организация проведения очень странная - дикая смесь высокого уровня и кошмара. Похоже, хозяева зала не умеют принимать столько людей (over 700) и обеспечивать IT. Попытка установить 40 accesspoint'ов в одном зале - явное ламерство, вроде только ко второму дню поняли, что не так. Трансляции всё время падали. Ну и многое другое по мелочам. Но в целом в плюс: кому нужно было, тому комфортно.

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

По собственному докладу вынес в опыт* (кроме того, что первый блин на публике всегда комом) - что надо для такой аудитории не следовать рецептам "не будьте рабами powerpoint", а, наоборот, следовать за изображением: так хоть как-то понимают. И таки меньше волноваться, в устном виде меня постоянно заносило куда-то в сторону.

(*) теперь буду по-модному говорить "я увеличил свою экспертизу"

По следам дискуссии сделал правку в раскладке: при русском нажатие '\' даёт прямой слэш (и '|' с Shift'ом). Бэкслэш на русской раскладке не нужен в принципе, и не понимаю, кто его туда и зачем впихнул.

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

Кто-то уже в XX веке перефразиловал Маркса, что история может повторяться в виде фарса неограниченное количество раз.

В пятницу яндекс успешно повторил старый (10 лет назад) подвиг Lucky Net по вбросу всего BGP в OSPF. Последствия аналогичны, но масштаб и резонанс несравнимы.

Говорят, один из бывших нокеров LN тех времён начал работу в Google тем, что зарулил 40Gb/s поток в 2Gb/s канал. Потоки всего-то в 1000 раз толще того, с чем имел дело до того.:)
Большому кораблю - и торпеда со стадион.

Я с ваших линуксов фигею.
Коллега создал бутерброд с несколькими KVM'ами. Внутрь каждого KVM идёт tap, который снаружи входит в bridge. Нормальная себе конфигурация, у нас в бою такие работают.
Дальше нужно рисовать бы, но облом. В общем, KVM1 выходит наружу через br0 хоста и имеет также внутренний интерфейс, который через xbm-br0 хоста подключается к KVM2.
К br0 подключен eth0 - единственный во всём этом зоопарке реальный физический, за ним мир. На br0 навешен маскарад 10-й сетки.
Пинги мира с KVM1 проходят без проблем, src IP меняется.
Пинги мира с KVM2 уходят без NAT (src IP остаётся 10.*)
Облизали правила iptables, прыгали между MASQUERADE и SNAT - ничего не нашли. NAT этот пакет тупо не видит.
Облизали таблицу раутинга - ничего не нашли.
Подключили Самого Опытного Коллегу. Тот сказал, что выход из бриджа может идти напрямую на L2 вместо L3 и тогда nat/POSTROUTING не работает, что это известные грабли бриджа. Но тогда бы и с KVM1 не работало. А в чём разница, спрашиваем? Афигегознаетъ.
Вечером коллега - автор конфигурации приходит офигевший. Перенёс, говорит, KVM2 домой, прокинул путь с местного бриджа туда туннелем - всё работает.
Получается, пакет, который пробежал только что через систему и ушёл наружу (через tap в KVM1), причём модулями NAT не замеченный, оставил какой-то след в ядре, который приводил к тому, что когда этот пакет снова входил в ядро уже через другой входной интерфейс, NAT его игнорировал несмотря на то, что не имел никакого отношения к первому проходу.

Из того, что в принципе в документации есть, но так с ходу не заметишь.

handle_info(foo, State) ->
  NewState = #state{} = do_foo(State),
  {noreply, NewState};

если do_foo() случайно вернуло ерунду, а не нужный record, то без проверки = #state{} оно заметится только на следующем цикле, а это немного не то, что нужно:)

Аналогично можно сделать function clause на входе:

do_foo(#state{} = State) ->

(Альтернатива в виде dialyzer тяжеловата, мягко говоря, и не во всех случаях.)

Во FreeBSD5 одно время в базе был diskcheckd, потом убрали в порты. Я недавно посмотрел - ставится и работает.

# ps ax | grep disk
67114  ??  Ss     0:07.07 diskcheckd: ad6 2.05%, ad4 5.14% (diskcheckd)

В фоне читает все локальные диски на заданной скорости (можно делать ооочень медленно, чтобы не мешать обычной работе), если где-то плохо читается - будет громко жаловаться в syslog.
Эта деятельность "ортогональна" всяким smartmon, или помогает им (проверять блоки раньше, чем они реально потребовались).

Подробный список известных вариантов хранения с плавающей точкой на всех известных архитектурах - просто доставляет разнообразием и хитрыми решениями.

Несмотря на это, всё равно придётся делать своё - потому что должно тривиально читаться в hex-дампе.

(И вообще автор жжот нипадецки - но оценить его могут только те, кто работал с битово-ассемблерными потрохами минимум двух заметно разных рахитектур...)

# df /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/lvm-slot10--0
2.0G 2.0G 0 100% /

# du -akx / | sort -rn | fgrep /dev/null | head -15
1029308 /dev/null.22874
165220 /dev/null.18565
115264 /dev/null.8357
100336 /dev/null.724
71028 /dev/null.23410
59840 /dev/null.1703
50672 /dev/null.3605
37016 /dev/null.32292
27320 /dev/null.397
2544 /dev/null.28946
1396 /dev/null.16699
0 /dev/null

# file /dev/null.[0-9]*
/dev/null.16699: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style,
from '/usr/sbin/slurmdbd'
/dev/null.1703: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style,
from '/usr/sbin/slurmctld'
/dev/null.18565: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style,
from '/usr/sbin/slurmctld'
/dev/null.23410: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style,
from '/usr/sbin/slurmctld'
/dev/null.28946: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style,
from '/usr/sbin/slurmdbd'

extern int a,b;
void f(void) {
  a = (a++) % b;
}

При входных значениях a=19, b=5 значение a в результате:
gcc3.4, tcc, clang2.9, SunC++, C#: 4
gcc4.*: 20
SunC, IntelC 10.1: 5

судя по задумке автора, должно было получиться 5. Хотя это зависит от конкретного применённого психоактивного вещества...

(Оригинал - ныне удалённый драйвер в staging linux)

Авторы XKB, у которого вечно проблемы с лампочками клавиатуры, явно сидят на ноутбуках eMachines, у которых вообще нет этих лампочек.


-netch-, настраивающий E642.

$ rpm -qa | wc -l
1876

OpenSuSE 11.4, десктоп без KDE и гномов.

Как-то незаметно прошлой осенью скончался SSH.com - съели стандартные венчурные маркетологи. С этого момента на сейчас у нас нет вообще никакой доступной альтернативы OpenSSH. lsh - последняя активность за 2008 год. fressh - дальше 1-го протокола не ушёл. Dropbear застыл примерно тогда же, когда lsh (в этом году какие-то правки - надолго ли?) Остальные не годятся даже на это.

По-моему, пора вкладываться в реализацию под GPL (например, развивать lsh) хотя бы для того, чтобы не остаться с единственным вариантом.

Добился включения caller ID на телефоне на текущей хате. Укртелефон требовал назвать формат для этого, ставя тем самым в тяжёлый когнитивный диссонанс (как быть, если их список выглядит как "ANI, FSK, DTMF", в инструкции по аппарату вообще не назван формат, а есть только сертификация, а гугл говорит, что все три термина - очень общие и есть ещё масса уютных домиков для дьявола?) Без указания с моей стороны конкретного формата чётким уверенным голосом - не соглашался. Я сказал "FSK" и не прогадал - заработало.

Про предыдущую точку их техподдержка сказала "Оболонский район - однозначно DTMF", несмотря на то, что станция была выносом с 460-й, которая в Подольском. Но тоже работало.

По-моему, им надо заводить штатного гадателя на кофейной гуще.

В обоснование test-drived design (TDD) постоянно приводят соображения, что без предварительного теста невозможно понять, рабочий ли тест вообще. Например, тут, дословно: "Сначала тест должен упасть. Это тест теста. Если тест не упал, я не могу быть уверен, что он упадет, когда надо."

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

Если так подумать, ответ становится тривиальным: зная структуру теста, мы должны иметь возможность внести в ключевых местах механизмы заведомой поломки тестируемой обстановки. Тогда проверка теста (мнэээ, это уже тестирование теста какое-то;)) состоит в проверке фактов, что
* тест без указания на модификацию обстановки - работает
* с каждым из таких указаний - ломается, причём характерным для этого образом (желательно видеть отражение в финальном коде завершения или сообщении об ошибке)

Например, если я проверяю в тесте приход определённого сообщения на шину, то очевидным вариантом сломать тест является не подписаться на шину или подписаться не на тот тип сообщения. Если в настройках должно стоять, какой выходной тег, то вариант поломки - заменить генерируемый тег. Если я проверяю, что выключение объекта привело к нотификации "ой, он выключился", то мы "забываем" выключить эмулятор объекта. И так далее. Для Unix я проверяю это установкой TEST_OPTIONS в окружении перед основным make теста, для других сред потребуется выбрать что-то соответствующее по вкусу.

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

Как читающие это уже поняли, я против TDD как тотального подхода, потому что TDD как подход - фактически обман, когда административные тезисы выдаются за технические. Требование "покажите, что ваш тест действительно работает" используется для маскировки требования не похерить само построение теста по обоснованиям недостатка времени, отсутствия необходимости проверять и тому подобному, а также для того, чтобы менеджмент получил формальные признаки готовности кода. Но так как всё покрыть тестами нельзя в принципе, (а 5% тестов покрывают 95% ошибок), то TDD изначально формально и практически некорректен. А вот behavior-driven development (тут или тут) при правильном подходе уже этим не страдает, но не по внутренним причинам, а потому, что определение "поведения" ограничивает тем, что действительно важно (а не несущественные особенности реализации).

Продолжая тему этого...

#include <stdio.h>
#include <fcntl.h>

int main()
{
  printf("%llx\n", (off_t)(-sizeof(int)));
  return 0;
}

в 32-битке выводит 0xffffffffc. Ура, товарищи.

Исходный код, по которому увидена проблема, содержал

lseek(fd, -sizeof(buf), SEEK_END)

Erlang'овский global - нечто, мягко говоря, очень своеобразное. Чтобы зарегистрировать имя, он:
* бежит по всем известным нодам, расставляя свой лок;
* модифицирует имя на каждой ноде отдельно;
* бежит по тем же нодам, снимая лок.
(Это я не учитываю варианты типа - нашли конфликт, удаляем все регистрации)
Если происходит конфликт в процедуре установки лока, он снимает свои локи, ждёт случайное время (от 0 до 8 секунд) и повторяет снова. И так до посинения (мы как-то насчитали несколько часов ожидания). Никакого преимущества у ранее пытавшегося нет, и реальный приоритет определяется сочетанием случайностей. Сейчас при одновременном рестарте многих приложений регистрация на старте может длиться десятки и сотни секунд.

Может, в устойчивой среде это и хорошо. Но представим себе разорванный кластер, который соединился снова. Одно имя зарегистрировано двумя => конфликт => одного удаляют (или обоих, тоже возможно). Значит, поздний конфликт возможен? Таки более чем. Что мешает положиться на изначальную неконфликтность и срубать только по достижению конфликта?

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

В R12, кроме того, ещё периодически регистрации терялись молча, без каких-то признаков проблемы. В R14 такого уже, к счастью, не наблюдается.

Убедился, что упорно предпочитаю git остальным средствам, но это никак не связано собственно с распределённостью, а с несколькими фишками:
1. Понятие отдельного "индекса" и удобство управления им. Особенно рулит возможность частичного коммита из файла и даже с ручной рихтовкой патча перед его вносом, если add --interactive недостаточно.
2. Лог со включённым в него диффом (git log -p), или описанием изменений (--stat)

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

Зато несколько раз ошибся в SVN, сделав svn update в подкаталоге и решив, что и остальная часть дерева тоже обновлена.

http://www.javalimit.com/2010/08/erlang-message-queues-and-rpc.html
процентов на 90 покрывает мои мысли по этому поводу.

Рекурсивный дятел - выстукивает себя самого через дерево.

К моему вероятному стыду, с современной печатью я до сих пор на "Вы".

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

Чего хочется:
1. Задать моноширинные шрифты (почти тривиально)
2. У каждой страницы должен быть header (заголовок) и footer (как переводится?), в сумме в которых должны быть (как расположу, хотя не суть важно)
- имя файла
- номер текущей страницы и количество всех страниц (лучше по типу 3/24)
- дата и время отправки на печать
- своё примечание специально для этой печати

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

Подсказали kate. Почти самое подходящее из того, что есть, но непонятно, как вписать полное количество страниц и как включить нумерацию строк.
Говорили про pr, lpr. Переписывать фильтры специально под этот случай как-то не хочется.
Заглянул в openoffice. Может, и можно, но долго страдать макросами (в лучшем случае).

UPD1: `a2ps --line-numbers=1 -1 $file' - дало уже вполне пристойный вид, можно использовать и улучшать.

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

1. Есть сокеты one-to-one и one-to-many. Их не следует путать с тем,
сколько адресов на конце у каждой ассоциации: может быть one-to-one на
много адресов и one-to-many на один адрес.

One-to-one - значит, может быть только одна ассоциация. При передаче
не обязательно указывать, по какой передаёшь и почему, а при приёме -
с какой получено. One-to-many - напоминает старый добрый UDP - общаешься
с кем хочешь, но не забывай про цену - тут на каждого другого есть состояние
в памяти.

2. SOCK_STREAM - это не поток, как в TCP, несмотря на название. Это
всего лишь one-to-one сокет. Почему STREAM - видимо, констант не
хватило. Сообщения, приходящие в него, всё равно не склеиваются.
(Я вначале подумал, что назначил бы иначе - SEQPACKET для one-to-one и
DGRAM для one-to-many. Было бы немного логичнее.)

3. sctp_send(), sctp_sendx() работают только при уже готовой ассоциации.
Если такой ещё нет, функция обломится с совершенно невнятной диагностикой.
Это значит, что первая посылка на one-to-many через них недопустима
и надо использовать sctp_sendmsg[x](). А лучше - использовать её всегда
для таких сокетов.

4. На one-to-many сокете передавать надо, как сказано выше, через
sctp_sendmsg(). Это создаёт ассоциацию, если её ещё не было - но у этой
функции нет возврата номера созданной ассоциации. Зовите
sctp_getassocid(), если он нужен. Сравнивайте адреса, как в старом
добром UDP.

5. У one-to-many сокета, если не сделать listen(), он не будет принимать
новые ассоциации по входящим запросам. Однако логично.

6. Номер потока не может быть произвольным, они считаются от 0 до максимума.
По умолчанию дают только 10 потоков - с 0 до 9.
(FreeBSD: sysctl net.inet.sctp.outgoing_streams)
Можно увеличивать желаемое (через sockopt SCTP_INITMSG), вопрос в том,
насколько удобно получится с этим работать.

7. Поле ppid надо сохранять и извлекать с помощью htonl() и ntohl().
В мане написано специально, чтобы запутать: "Note that the stack passes
this value without regard to byte order."
Кроме того, есть рекомендации IANA по значениям для него - чтобы помогать
расшифровке в случае чего. Не вижу глубокого смысла ставить его по этим
рекомендациям, но можно использовать в качестве своего внешнего тега.

8. Поле assoc_id имеет выделенное значение 0 - "моя не знай", допустимо
при передаче. Использовать одновременно адреса и assoc_id от разных
ассоциаций я не пробовал - боюсь, порвётся.

9. Не забывать включать получение sctp_sndrcvinfo через SCTP_EVENTS.
FreeBSD по умолчанию его доставляет, а вот Linux - нет.

Возможно, to be continued.

"Воля" сдалась варягу - перевела свою почту к яндексу. Требуют, чтобы во From было то же, что в аутентификации. Абыдна.

Почитал маны и тривиально замучил exim:

begin authenticators

base_plain:
driver = plaintext
public_name = PLAIN
server_prompts = :
server_condition = ${lookup{$auth2}lsearch{/usr/local/exim/etc/exim/passwd}\
{${if crypteq{$auth3}{$value}}} {false}}
server_set_id = $auth2

вместе с левым входным портом этого exim'а получается независимость от провайдерских извращений.

На досуге надо подумать оCRAM'ить, смотря что читалка позволит...

Чего только не узнаешь, читая дампы...

11:52:03.945275 IP 127.0.0.1.36916 > 127.0.0.1.512: UDP, length 15
        0x0000:  4500 002b 19b9 0000 4011 0000 7f00 0001  E..+....@.......
        0x0010:  7f00 0001 9034 0200 0017 fe2a 6e70 7840  .....4.....*npx@
        0x0020:  303a 2f64 6576 2f6e 756c 6c              0:/dev/null

мало того, что у procmail'а comsat живее всех живых, так он и про /dev/null рассказывает.

http://stackoverflow.com/questions/1995113
(увидел на RSDN)

если я правильно посчитал, пальма первенства - за Javascript.

UPD: хотя кошмарнее черты чем коболовский ALTER GOTO никто не признаёт - потому что вышибает почву из-под ног любого программиста, уверенного в неизменяемости кода из высокоуровневного языка.

Что-то начали массово менять средство сжатия для публичных архивов...

lzma на 1-м уровне делает файлы меньше в полтора раза, чем gzip на самом 9-м.
Зато и процессора жрёт при этом в 2 раза больше.

$ for P in gzip bzip2 xz; do for L in 1 3 6 9; do /usr/bin/time sh -c "$P -c$L ~/Mail/uanog-track.2009 >c.$P.$L" 2>&1 | awk '{print $3}'; done; done
0.21
0.24
0.40
0.44
1.90
2.16
2.44
2.66
1.02
3.98
5.89
6.04

$ ls -ld c.* | awk '{print $5 " " $9}'
1874385 c.bzip2.1
1623726 c.bzip2.3
1510405 c.bzip2.6
1451469 c.bzip2.9
2113625 c.gzip.1
2027492 c.gzip.3
1840844 c.gzip.6
1835760 c.gzip.9
1621832 c.xz.1
1317072 c.xz.3
1242684 c.xz.6
1242684 c.xz.9

Исходный файл - 6810957 байт.

Clang умеет при показе ошибки или предупреждения выводить строчку исходного текста и подчёркивать проблемный кусок. Очень удобно.

А ещё у него по умолчанию -Wall и -march=native.

Интересно, почему Intel до сих пор не отказался от поддержки 16-битного режима в процессорах x86?

Загрузчики? BIOS? Так EFI уже давно продумано и работает.
А даже если нет - переделать два десятка "прерываний" BIOS на новый лад не так сложно.

Настроили порцию весьма серверных железяк в процессе пусконаладки объекта.

У материнки Intel S5000PSL (её на объекте больше всего) встроенный IPMI на три LAN канала, два - на встроенные Ethernet интерфейсы (внутри карточки деление по MAC), третий - на подключаемый RMM модуль. Через IPMI (очевидно для знающих;)) можно включать/выключать/ресетить, снимать датчики, получать последовательную консоль (причём BIOS и всё что под ним объединяет ввод и дублирует вывод обычного экрана - неважно, чем цепляться и откуда нажимать). То, что цепляется к третьему каналу, ещё и умеет remote KVM (с графикой!) давать через вебморду плюс Java webstart (видимо, я отстал от жизни - как можно поместить ethernet интерфейс, IP стек и вебсервер в микруху размером в стандартную K155?)

Отдыхаю от процесса, пытаюсь себе представить осмысленность подобных устройств в типичных наших провайдерских условиях. Похоже, становятся таки всё более актуальными - если раньше обычный дежурный на площадке был сам в состоянии всё настроить, то уже к моменту моего ухода из LN это больше напоминало "покорми собак и ничего не трогай". Главное - не забыть заранее протянуть дублирующую сеть. Хотя можно и к местной домосети подрубиться.:)

Шеф радует рассказом.
Есть некий сервер. В полной набивке ватт 450.
Втыкание второго эзернета увеличивает потребляемую мощность на 270 ватт.
Куда она уходит - найти не удалось, перещупали всё.
Пришлось поставить 2*450 БП.
Материнка Tyan.

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

Свичи на T-500 хотят такакс, я несколько лет этого слова не слышал. Ностальгия.

Написал в uanog и подумал, что заслуживает отдельного постинга.

---

Wed, Mar 10, 2010 at 21:27:29, basil wrote about "Re: [uanog] apache dummy question":

> ну давайте поофтопим :)
>
> нормальные дистрибутивы конфиги не затирают
>
> в частности федора: создает файл-конфиг с расширением rpmnew (кажись так,
> ибо пользую федору сугубо на десктопе)
> во фре: если софт ставиться из портов, то каждый ментейнер заботиться о том,
> чтобы конфиги не затирались, а если не получается у ментейнера - то
> коммитеры всегда помогают, даже русского коммитера находят если надо :)

_Нормального_ подхода по-настоящему я не видел нигде. Потому что
единственный нормальный подход, jIMHO - это использование VCS, при
котором есть ветка канонической формы конфигов (в CVS такое
называется vendor branch) и ветка текущих конфигов, и при накате
нового состояния выполняется слияние (merge) правок из текущей
ветки и ветки канонической формы.

При любом другом подходе, не обладая комплектом из двух разностей
(diffs)
1) между прошлым каноническим состоянием (C0) и текущим
содержанием (A0)
2) между прошлым и текущим каноническими (C0 и C1)

невозможно гарантированно вычислить A1 (то, что должно получиться
в результате).

Подход RPM даёт A0 и C1, но не даёт C0.

В случае отсутствия конфликта слияния должно выполняться
A1 = A0 + (C1 - C0)
или же
A1 = C1 + (A0 - C0)

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

Остаются случаи, когда автоматическое слияние ломается. Например,
если у нас в C0 было написано

Port 34567

а админ заменил в A0 на

Port 45555

приход C1 с записями

ListeningPort 34567
OutgoingPort 34567

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

ListeningPort 45555
OutgoingPort 45555

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

---

Замечания по реализации:

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

2. Пакетный менеджер, даже если оставляет работу админу на потом, должен позволять общий учёт файлов для слияния. Искать .rpmnew или аналог по всему файловому дереву мне не улыбается.