Перейти к содержимому
Калькуляторы

XeonVs

Активный участник
  • Публикации

    338
  • Зарегистрирован

  • Посещение

Все публикации пользователя XeonVs


  1. Ага, есть такое, огребаю по сей день, всецело доверился финальной версии сборки №10 АСР LANBilling прошедшей тестирование согласно программе-методике(интересно было бы взглянуть) испытаний разработанной компанией,вобщем сам дурак. Причем обновлялся со сборки за июль. Косяки не только при обновлении на рабочей вылезли, но и на тестовой свежеустановленной системе вылезли установленной уже потом. Впрочем, сборку эту, быстренько убрали по понятным причинам из загрузки в ЛК. Поздно, я уже то-же пробежался про граблям. Действительно убрали... Свинство сделанное в тихую. У меня стоит сейчас последний билд от 31го числа. + накатаны костыли для нормальной работы "планирования блокировок". Активно мешающих жить проблем не наблюдается.
  2. Работает, устраивает? Не трогай! Одно мучение только.
  3. Нашел в чем проблема. Отписал тикет по критичной проблеме, 11 утра, ни ответа ни привета. Хомячки посылают нежные лучи ненависти "сетевым решениям".
  4. Что за эффект? Поясните? Одновременно: поток А кратковременно блокирует кучу записей таблице А. поток Б блокирует записи таблице Б и ждет записи результатов в таблицу А. При определенных условиях поток Б может ждать очень долго и транзакция аварийно завершается.
  5. У нас еще веселее, тупо эффект гонки в пачке таблиц связанных с радиус-агентом. Хомячки негодуют уже с 4х часов вечара, ТП от "сетевых" в данном случае бесполезна.
  6. ну вот, стоило вас похвалить как опять то-же самое. Сборка обновлена вчера, где Changelog?
  7. На боевой системе уже попробовал 10ю кто нибудь?
  8. так никто иначе на нее(бету тем более) не перейдет. А тестировать сборку хочется на живых базах.
  9. Выводы позитивные, детализация изменений стала значительно лучше. Посмотрим теперь как она будет развиваться в рамках вносимых изменений в 10ю сборку.
  10. Вы опять ничего не понял. :) Таким образом хотят показать, что о Вас не забыли и Вашей проблемой занимаются, хотя по факту на Вас нет никакого времени. Предполагаю, что МэТээС и ТэТэКа дрючит поддержку ЛБ "по-черному", на остальных времени не остается. все бы хорошо, но данная инсталляция как раз таки относится к одной компании из трех букв.
  11. ТП вам дополнительно надо тренировать и тренировать это уже ни в какие ворота не лезет.. тема тикета: "бла бла бла агентом XXX" класс запроса: агент XXX и после этого сотрудники интересуются, цитирую: "Добрый день, Укажите какой агент."
  12. Немного не согласен, даже бекпорт в старую сборку должен быть отражен. Нормальный ченжлог(+ возможность скачать старые билды) например, позволил бы разобраться, где что сломалось, между 8й и 9й сборкой. Поправьте меня если я не прав. Рассуждаю так: какой прок от списка и содержания коммитов от сборки к сборке если все равно пользователь не владеет кодом. Это крайность. Другая крайность - когда по записи в changelog действительно нельзя судить о конкретике изменения алгоритма. Вывод - мы увеличиваем детальность changelog, но человеческим языком (не в терминах коммитов) по которому можно судить о том как именно изменилось поведение системы и при каких условиях. Говоря в целом мы уже наполовину открыли код некоторых частей системы, для внешних разработчиков. В 2.0 вынесли в открытую часть большинство "внутренних" бизнес критичных алгоритмов, включая тарификацию. Т.е. двигаемся в сотрону открытости кода. Коммиты же имеют ценность если виден код. Я для примера могу в личку кинуть пример логов svn коммитов от 9->10 - сотни строк малопонятного кода. Не представляю какая от них польза в changelog. чрезмерно детализировать лог однозначно не стоит. В минимуме достаточно одной записи на каждую публичную генерацию сборок. Может быть вам посмотреть в сторону публичного read-only баг-трекера, для того что-бы иметь возможность не наступать на грабли коллективно и ссылаться в ченжлоге на баги? Кажется этот вопрос поднимали в "волжских далях". За сотрудника, принимается. Да и если в тикете стоит дата со словами: "исправим такого-то и такого-то"; то хотелось бы, чтобы срок выдержан был? либо по истечении хоть какая-то реакция, а не игра в молчанку.
  13. Не внимательный, для нового сотрудника вполне простительно, не разобрался в вашей кухне. Баг который проверялся за 1 минуту на вашем\нашем стенде, вылился в переписку на пару часов. И на мой взгляд ответ: "На данный момент веб-программисты в отпуске, будут через недели полторы." вообще не профессионален.
  14. Немного не согласен, даже бекпорт в старую сборку должен быть отражен. Нормальный ченжлог(+ возможность скачать старые билды) например, позволил бы разобраться, где что сломалось, между 8й и 9й сборкой.
  15. Тем что он не информативен и не актуален. Да что, то иногда меняется, но когда сборка пересобирается 7 раз за неделю.... В итоге и получается, что обновиться надо, а что получится не знает никто. Раз держите разработку в svn то уже есть достаточно хороший ченжлог.
  16. Категорически согласен. Документированность системы оставляет желать лучшего. + Как минимум должен быть еще более подробный публичный ченжлог на каждое обновление сборок. Иначе установка\обновление сборки превращается в русскую рулетку даже имея тестовые базы.
  17. Борис Осянин Ага, разобраться еще раз стоит. Сделать дополнительные выводы о своей работе, если после летнего комстаровского сборища их(выводов) было не достаточно. Или устройте например на форуме раз в месяц опросы о качестве оказываемой ТП для каждого ее сотрудника.
  18. Адекватных там пара человек, остальные могут 20 секундные тесты по проблеме проводить 2 часа в доказывания клиенту, что это он дурак. Часто на МТСо-комстаровские тикеты реакция наступает только после солидного ускорения в пяту точку. Гибкость местами спорна, данное чудо пишется в отрыве от телекомовских реалий, и тут либо пинать ТП по доработками, либо менять кардинально бизнес-процессы в компании. В общем работатьс ним можно, но после очень детальных тестов под свои процессы.
  19. ESP какой стоит? наши коробочки прожевывают по 4FV+пиринги и замечательно все.
  20. 4 FV + 5ток пиров на циске BGP using 266391320 total bytes of memory
  21. Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии.
  22. http://www.hilik.org.ua/bgp-community-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-%D0%B2-quagga/
  23. Конечно. Товарищ вас не правильно понял. Можно построить фильтр на основании AS-PATH
  24. Можно посмотреть как написан whireshark, кушать процессор любит при обработке. Формально тормозить будет уже за счет копирования пакета из ядра в юзерспейс. Можно посмотреть на netghaph в freebsd, будет достаточно производительно. Еще там-же можно посмотреть на фреймворк Khelp ERTT модуль. Под линуксы посмотреть модули от iptables.