| |
| Вместе с Alexey Torkhov собрали покалеченные копирайтом/патентами/цензурой пакеты в Fedora: https://fedoraproject.org/wiki/User:Peter/Disabled_applicationsСписок получился с одной стороны большой, а с другой - из нескольких тыщ пакетов могло быть и больше. Хотя это то, что удалось найти сразу - наверняка будет еще что. Понятно, что серьезные проблемы, типа отсутствия в Fedora ffmpeg, мы не упоминали вовсе. Что с этим листом делать? Сначала была мысль просто переписать такие пакеты, а теперь я понимаю, что это может стать руководством к действию для тех, кто создает свободные дистрибутивы на базе Fedora/RHEL, например для Omega Linux или для Russian Fedora Remix. Они сейчас просто сваливают в одну кучу пакеты из RPMFusion и Fedora (ну и добавляют несколько своих, как в случае Russian Fedora Remix), а надо подходить более творчески. Быстро глянув можно увидеть, что главная проблема, это ограничения из-за патентов - тут, думаю, нужно ввести новый макрос, что-то типа %{enable_patented}, который должен присутствовать как в главное Fedora (и там он должен быть 0), так и в различных пересборках (а там он может быть как нулем, в тоталитарной США, так и единице, в свободно дышащей России). Все остальные пакеты должны быть в курсе этого макроса, и, в зависимости от него, включать поддержку патентованного или нет. Тогда инструкция по сборке будет выглядеть так - выставляем макрос в 1 и пересобираем все. Иначе, при тупом совмещении Fedora и RPMFusion, функции в пакетах, которые уже в Fedora, сами не включатся. Есть еще кривой способ - самому брать те пакеты, где что-то отключено, и постоянно их править (так делают в Russian Fedora Remix, в т.н. fixes). Кстати, если дистрибутив будет для некоммерческого (например учебного) использования, то он может включать также non-commercial пакеты, так-что надо будет еще и этот макрос добавить. Вот, как-то так. Надо еще подумать и предложить эту фичу, пока шум не улегся от флеймов на тему non-us fedora headquarters. | |
|
| Невероятно, но дефолтный syslog в RHEL5/CentOS5 глючит! Как все было: * Наладили систему на тестовом сервере (там Gentoo какая-то - ее не жалко, да и менять параметры можно быстрее хотя бы и в ущерб стабильности) * Запустили, потестили под нагрузкой - работает * Перенесли на рабочий сервер, с CentOS 5 * Запустили под нагрузкой - все, лежит. Дергаемся, отключаем то, включаем это, меняем тот параметр и т.п. - хрен! Как быдто какой-то ресурс кончается, но и la не такой уж и страшный (хотя гораздо выше "гентушного"), и памяти полно, и диск особо не юзается. Смотрим в /var/log/messages, ничего не понятно - сообщения бегут, все, вроде, работает. Начали смотреть, чем-же еще различаются машинки - kernel, glibc, gcc, да почти все! Приуныли. Сразу вырисовывается мораль - машинки должны быть полностью идентичны, лучше на уровне архитектуры, ведь я прекрасно помню про список Bugzilla ticket (кстати, как это будет по-русски? "запись в багзилле"?) о программах, которые просто не работают на разных архитектурах.Начали шаманства - лазили внутрь софтины (слава Богу, опенсорсной) с printf и дебаггером - ничего не увидели жуткого (хотя кое-чему удивились, что будет, видимо, поводом для писем в список рассылки софтины). Все время внимательно читали syslog'овые сообщения (ну как может он глючить? это ж тривиальнейшая штука - проще некуда). Компилировали с разными флагами (я знаю, что использующийся в RedHat'овых дистрах -D_FORTIFY_SOURCE=2 вызывает проблемы иногда). Пересобирали из разных тэгов и бранчей репозитория, но все без толку. Затем, в самый последний момент, решили отключить syslog - все сразу залетало. Насторожились, включили снова, настроив так, чтоб писал в /dev/null - все бегает. Пересобрали из fedora-devel syslog-ng 2.0.9 и заменили им старый дефолтный syslog - все забегало, как положено. Разрешив таким образом проблему, мы запланировали в свободное время еще покопаться в этом направлении. Уже поняли, что проблема возникает, когда мы пытаемся записать слишком большие сообщения, скажем больше 5-10 килобайт. Мы до сих пор не знаем, почему он так себя повел? Может-быть дело в связке "используемая софтина + sysklogd"? Я быстро покопался по issue-tracker'ам, но ничего не нашел. В общем, посмотрим. А еще есть rsyslog. | |
|
| У ![[info]](http://lj.rossia.org/img/userinfo-lj.gif) gpr63@lj увидел.  Весело! Одна поправка - это, конечно, гендерно политкорректная картинка, а в реале пацанва-бы не испугалась. | |
|
| С этим охлохом (название-то какое, да?) какая-то странная тема. Во-1 они зачем-то прикручивают с упорством, достойным лучшего применения, туда примивтиную блог-площадку. Внимание вопрос - нахрена? Этих блог-площадок уже жопой жуй, так зачем еще одна? Тут есть один тонкий момент, который почему-то многими в упор не замечается. Каково преимущество у одноклассников.ру (например) перед мойкруг.ру? А то, что в отличие от одноклассников, мойкруг косит под универсала - там и то, и это, и другое... Мне (и прочим людям) это не очень нужно - языком болтать есть где, а что-то более специализированное (может даже и в довесок к *уже* *имеющемуся* сервису) можно опробовать. А как этого добиться? Не пытаться конкурировать с уже имеющимся сервисом (у нас можно и блог вести, и то, и се), а добавить что-то новое, вклиниться в существующую инфраструктуру. А как подключиться? Да вот как - забить на всякие уже давно реализованные фичи и добавить логин с уже имеющегося аккаунта, т.е. OpenID, (и не надо бояться проблем с безопасностью - ведь "волков бояться - в лес не ходить"). Кстати, вот как можно легко нагнать себе аудиторию маленькому стартапу - разрешить к себе логин по OpenID, а большая аудитория, это +5 к здоровью и +5 харизмы. Все же будут довольны! Человеку не надо заводить еще один Useless Account (а это уже раздражает) а маленький стартап получает хорошую прибавку к аудитории, причем нахаляву, присосавшись к крупным. С этой точки зрения в Ohloh не хватает возможности привязать тамошний аккаунт к уже имеющемуся (приходится заводить еще один, а самый популярный вопрос на мое предложение завести там аккаунт, это "what for?"), зато эти ребята делают всякую лабуду. Во-2 какое-то нездоровое палево с рейтингом. Я там еще не полностью разобрался, то там такая тема - рейтинг создается из строчек кода + Kudos, которые могут тебе навешать другие лемминги. Приколитесь, да? На самом деле должно быть так - рейтинг должен склоадываться *только* из строчек кода, причем т.к. некоторые приложения действительно популярны, то некоторые строчки должны быть дороже остальных. Никакие Kudos, данные тебе другими юзерами не должны влиять на рейтинг. Еще момент - надо учесть, что пользователей Ohloh, указавших, что они юзают Fedora полно, однако не все из них (далеко не все) указывают, что они используют, например Linux Kernel 2.6. Я про то, что в описании софтины надо добавить возможность указывать от чего она зависит, и это тоже учитывать в рейтинге, ведь иначе библиотеки вообще никто указывать не будет, хотя их все используют. А Kudos раздавать и получать надо вообще запретить. Максимум можно включить функцию "добавлять в друзья". Хотя и это вполне можно запретить, если мы запретим там унылое блоггерство, а группы пользователей и разработчиков и так появляются. Как-то так. Ну и по мелочи - виданое-ли дело, что среди VCS там поддерживаются только CVS, SVN и Git? Это тоже косяк. А в целом мне идея нравится. Я-бы даже поучаствовал в улучшении ихнего проекта, но в опеосорц у них только (ГЫГЫГГЫ) счетчик строк кода. | |
|
| Сегодня в ser-devel мэйллист свалилось несколько патчей от мэйнтейнера SER из Debian. Припекло, наконец-то. Патчи должны быть засланы в upstream. А еще у нас, в Fedora, тоже решили следить за патчами более внимательно: http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatusЭто, конечно, муторно, но правильно. Фигли, надо как-то это дело контролировать. | |
|
| Пытаясь разобраться с RTPproxy и особенно с ее протоколом управления, написал свой вариант на erlang: http://code.google.com/p/erlrtpproxy/Это утилита для OpenSER/SER, чтоб соединять RTP-потоки у SIP-клиентов, находящися за симметричным(и) NAT'ом. Что работает: * Полностью заменяет RTPproxy в случае звонков с одним RTP-потоком (без видео, например) * Прозрачно для пользователя работает одновременно на множестве erlang-узлов TODO: * Проксирование более одного rtp-потока (пока просто не нашел времени чтоб сделать и протестировать, но нужно сделать - микрософтовый RTC умеет видео, причем неплохо) (надо потестить получше) * Проигрывание определенного, заранее записанного RTP-потока (для проигрывания в early media мы используем SEMS - у нас там статические правила) * Вообще, сделать обработку дополнительных аргументов при соединении пользователей (надо посмотреть, что там есть) * Запись RTP-потока (наверное придется сделать) * Переупаковка RTP-потока для линий с плохим качеством (надо сделать) * Получение статистики (надо б сделать, пожалуй - заодно и балансировать получится получше, чем round-robin'ом) * Добавление и убавление списка узлов без перезапуска (надо срочно доделать)А так - пашет у нас уже дней 20. Надо еще думать, может-ли быть такое, чтоб адрес и порт источника RTP в процессе разговора сменялся? Ну, может бывают такие симметричные NAT'ы. | |
|
| Вот, в erlang-general разговаривают о unit-тестах. В процессе общения Joe Armstrong высказал идею, до которой я как-то и не догадывался, что можно считать unit-тесты стандартной частью самого языка. http://thread.gmane.org/gmane.comp.lang.erlang.general/25815/focus=25825Походу это не только фича erlang'а, но и всех языков, где оператор сравнения может выбрасывать ошибку. | |
|
|
![[info]](http://lj.rossia.org/img/userinfo.gif){kind=small}