2010

Акадо+OpenVPN?

Меж тем, по следам вчерашней ужасной страшилки нам сообщают, что конкретно у Акадо и конкретно OpenVPN (и конкретно в штаты, если это существенно) - не работает. В точности как на роеме пишут (пункт 4).

Я вот не являюсь пользователем ни OpenVPN, ни Акадо, однако интересно.

Может кто-то у себя попробовать?

tor-rent?

Почитал на роем.ру новую УЖАСНУЮ СТРАШИЛКУ про тотальный запрет шифрованого трафика.

И подумал: а хрен ли в uTorrent и вообще в подобных клиентах нет внутри аналога Tor или подобных виртуальных аномайзеров-VPN-ов?

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

Очевидная, казалось бы, идея, а почему нету?

Beware: git(hub)+git+subversion= many epic fails...

Вынужден с огорчением признать, что такая вот схема:

GitHub  локальный git  SVN-репозиторий
оказалась нежизнеспособной, хотя изначально не казалась таковой.

У меня это, правда, осложнялось тем, что в SVN-е запомнена долгая и трудная жизнь, а на GitHub я поэкспортил только /trunk/, только одного проекта, да и то не весь, а только начиная с публичных версий.

Еще про карнавал

А если без шуток и хихиканий, то домен .РФ имеет шансы заменить поисковый запрос, как нам подсказывают коллеги. Если сработает.
аренда-бесшовной-видеостены.рф
аренда-бизнеса.рф
аренда-бульдозера.рф
аренда-в-питере.рф
аренда-в-спб.рф
аренда-видеостены.рф
аренда-город.рф
аренда-грузовиков.рф
аренда-домена-в-москве.рф
аренда-екатеринбург.рф
аренда-инструмента.рф
аренда-ипотека.рф
аренда-камеры.рф
аренда-кофемашин.рф
аренда-кран.рф
аренда-лесов.рф
аренда-мультитач.рф
аренда-нежелых-помещений.рф
аренда-новосибирск.рф
аренда-плазменной-панели.рф
аренда-плазмы.рф
аренда-презентационного-оборудования.рф
аренда-рублевка.рф
аренда-самолетов.рф
аренда-светодиодного-экрана.рф
аренда-хабаровск.рф
Может и не сработать, все-таки прилично оно выглядит только в файрфоксе, а эти ужасные xn-- в MSIE и Chrome - омерзительны. (Оперы под рукой нету и ставить ее ради посмотреть - не хочу). Но если у 50-70% населения это починится (ну там у MSIE9 и Оперы), то может и сработать.* - см update ниже.

И всякие очевидные generic-названия, вроде "магазин-вина" или "пивной-ларек" глупо не брать, по 89-99 рублей то.

Update интернет сообщает нам, что MSIE показывает нормальными буквицами в URL все, что подходит под понимаемые языки. У меня там был только английский, после добавления русского все вылечилось. С Chrome - аналогичная фигня. Подозреваю, что ставил браузеры до добавления русского в систему, отчего у них такие настройки и оказались.

LibRaw 0.11.2

По традиции, поспамлю тут немножко.

Вышла LibRaw 0.11.2 в которой:

  • Вычитание уровня черного производится всегда на стадии постпроцессинга (про что я тут уже писал), что сильно упрощает жизнь, особенно если у вас постпроцессинг свой: не надо разные камеры обрабатывать разными способами, черный или всегда сами вычитаете или всегда зовете LibRaw::subtract_black().
    Для пользователей постпроцессинга LibRaw в этом месте ничего вообще не изменилось, API старый, вычитание делается прозрачно для вас.
  • Сильно порефакторена AHD-интерполяция, если используется OpenMP, то на 4-процессорной машине оно теперь раза в полтора быстрее чем раньше (тоже с OpenMP) на полной обработке, т.е. AHD-стадия быстрее разика в 2-2.5
  • Новый I/O-layer, сделанный на iostreams, что для мультипоточных программ на Win32 и Linux сильно быстрее (на этих системах в FILE* I/O явно переборщили с блокировками). На FreeBSD/MacOS разницы никакой нет, что мне говорит об отсутствии там лишних блокировок (а кому-то еще - об убогости тамошней реализации iostreams :).
  • Поддержан мешочек новых камер (импортирована свежая dcraw 9.05):
    • Canon: G12, SX120, 60D,
    • Hasselblad H4D, Nokia X2, Olympus E-5,
    • Nikon: D3100, D7000, P7000,
    • Panasonic: FZ40, FZ100, LX5,
    • Pentax: K-r, K-5, 645D,
    • Samsung GX20, WB2000
  • Ну и по мелочи много поправлено, читайте Changelog.

Ну и на закуску: основная ветка разработки теперь дублируется на GitHub: github.com/LibRaw/LibRaw, отчего участие в наших развлечениях для сторонних желающих сильно облегчилось. Увы, но сил на дублирование всего репозитория не хватило, поэтому релизные боковые ветки - бэкпортятся в master, но вот самих боковых веток на github нету.

FreeBSD ZFS performance: просто возьмите молоток побольше

Если поискать в этом блоге, особенно в каментах, то найдете что ZFS на трех дисках (RAIDZ) давала у меня скорость чтения/записи порядка 75-80 Mb/sec. Так оно и было до недавнего времени, пока я с этой скоростью не уперся в скорость на сети (samba).

Пришлось навести следствие. Выяснилось очень простое, хотя и не вполне очевидное:

  • У меня был даунклоченый Core2Duo: 1.86Ghz работающий на ~1.6, задаунклочил летом, по случаю жары, просто на всякий случай.
  • При этом при чтении с ZFS system time как правило не рос выше 50%, что я неверно интерпретировал как однопоточность ZFS (судя по всему, неверно, ибо потом в тестах видел и 70% system) и верно интерпретировал как упертость в процессор.
  • Банальный оверклок того же горшка (и памяти) приводил к почти линейному росту скорости FS.

Тогда я пошел в лабаз и купил там еще один 2TB диск и 3.06-гигагерцовый C2D (E7600), собрал все в кучку (дисков стало 4) и результат:

  • 170-195 Mb/sec на запись
  • 230-280 Mb/sec на чтение
Скорость, судя по всему, зависит от того, в какую зону диска, побыстрее или помедленнее, файловая система положила файл. System при этом держится на уровне 20-30%, а изменение частоты горшка на производительность почти не влияет. Ну и Samba в диск больше не упирается.

Все тестирование делалось методом

dd if=/dev/zero of=file bs=1M count=20000
dd if=file of=/dev/null bs=1M
То есть речь о больших файлах, с мелкими всегда все сложнее и хуже.

802.3ad, EtherChannel и прочие....

А я правильно понимаю, что все виды агрегирования двух (и более) Ethernet-ов в один логический линк - они распределяют трафик по отдельным линкам исходя из адресов (MAC или IP) конкретного пакета?

То бишь стандартов я не читал, естественно, но читал википедию и читал интеловский текст про teaming, в обоих местах написано примерно это.

Никаких стандартных способов раскидать по двум линкам пакеты от одного TCP-соединения нету?

А счастье было так близко.....

P.S. Нет, я знаю что у FreeBSD-шного lagg есть round-robin, проблема в том что у меня с другой стороны работают или LACP или EtherChannel, а имеющийся там же LoadBalance работает как-то удивительно.... (это Realtek Ethernet Teaming, если интересно). Но похоже, даже если интеловскими средствами пользоваться (поменять сетевую карту и так далее...), которые более человечные, запихать один TCP-коннект в две трубы - не выйдет.

Поэтосамое по-настоящему

Если вы хотите поеба потрахаться по-настоящему, предлагаю такой вот метод:

  • Создаете ZFS-том терабайт эдак на шесть (меньше не пробовал) на FreeBSD 8.1-RELEASE/STABLE.
  • И записываете туда пару-тройку сотен тысяч файлов с русскими (и европейскими) именами в кодировке UTF-8.
Если вам очень повезет, то вы получите ненулевое количество каталогов в которых нельзя сделать ls или find (и естественно, все остальные, получающие список файлов, вроде du). Если повезет слегка, то ls работать будет, а вот rm * - нет. И rm конкретный-файл - тоже нет.

Единственная выявленная система - это очень длинные, под лимит, имена файлов. Не только русские, но и европейские (с умляутами).

gptzfsboot и все все все....

В копилку знаний сисадмина:

Если у вас ZFS, RAIDZ и загрузка с RAIDZ и вы ставили FreeBSD 8.1-RELEASE

То не поленитесь поапгрейдить бут-блоки на более свежие, те которые в 8.1 - не умеют грузиться с degraded array.

Подробности тут: www.freebsd.org/cgi/query-pr.cgi?pr=148655

Да, а если ваш массив в состоянии resilvering (навернувшийся диск заменили, но массив не успел перестроиться), то и новые бутблоки имеют шанс не загрузиться...

P.S. Нет, диск не ломался, это я просто like to move it, move it, все массивы в доме наращивал до размера побольше....

Половинка интернета?

Вот есть два 10-мегабитных интернета в квартире (раньше второй был 3-мегабитным и назывался бэкап), хочется статического load balance, ни с каким bgp затеваться желания нет, старый я уже.

Вопрос: как двумя-тремя route add поделить "интернет" примерно пополам? В первую очередь, конечно "рунет", ибо все затевается ради скорости на торрентах, а торренты преимущественно отечественные. Тут же, среди читателей есть обладающие статистикой, я знаю.

Банальное деление ровно пополам:

route add default channel-1
route add 0.0.0.0/1 channel-2
дает, как и ожидалось, огромный перевес первой нижней (0-127) половинки.

Сдается мне, что водораздел находится в районе 80/8 или 82/8, но приятно было бы подтвердить это статистикой....

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

P.S. Попытка прикрутить к решению pf с его round-robin привела меня к мысли, что кто-то негуманоиден, или авторы pf или я.

Update2: вебманевский клиент очень обижается на dual-homed. И, думаю, хорошие клиент-банки тоже должны обижаться. И понятно почему.....

Pages