Запустил Mele A2000G с Ubuntu-14.04 в качестве маршрутизатора в интернеты. Работает, но больше 2 мегабайтов в секунду не пропускает, при этом xl2tpd съедает весь процессор. Как же так? Старенький (даже WiFi нет) маршрутизатор D-Link спокойно пропускает в 5 раз больше. В старом маршрутизаторе, пить дать, процессор на пару сотен мегагерц и ОЗУ что-нибудь в районе 16 Мб, а в Mele A2000G гигагерцовый ARM и гигабайт ОЗУ. Почему же тормозит, почему xl2tpd съедает весь процессор?
В интернетах я встречал информацию, что xl2tpd бывает ядерный и userspace'ный. Какой лучше? Как узнать какой используется в моём случае, какие это опции xl2tpd и ядра? Или дело не в этом?
Захотел я на localhost'е поднять почтовый сервер, благо полосатый провайдер предоставляет статический IP, а доменное имя у меня куплено давно. Но Пчелайн не прописывает PTR записи для абонентов, так что для большинства SMTP серверов письма будут приходить с безымянного IP'шника.
Есть ли сервис пересылки сообщений который я мог бы использовать в качестве SMTP сервера для исходящих сообщений? По сути relay, только не совсем open, потому что я даже готов зарегистрироваться.
Собираю Ubuntu-14.04 для Mele A2000G (телеприставка на ARM'е). По инструкциям sunxi собрал ядро, загрузчик, debootstrap'нул файловую систему, но собрать всё воедино не получается.
Попробовал оттолкнуться от того что имею, взял готовый рабочий образ SD'шки с Ubuntu-12.10, посмотрел тамошний boot.scr. И вот теперь сижу и думаю, что же всё это значит.
Во-первых, что это за параметр такой LOADADDR, который нужно установить при сборке ядра? И в какое значение? sunxi его вообще не указывают, в интернете обычно встречается
LOADADDR=0x40008000 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage modules
Что это за числа после mmc 0 и bootm? Почему они различаются и какие они должны быть?
Я пробовал положить ядро linux-sunxi/experimental/3.10 и его модули в образ Ubuntu-12.10, но ОС не загрузилась. Возможно не только загрузчик неправильно настроил, но ещё и некоторые параметры ядра надо было включить. Однаков вопрос с магическими числами остаётся открытым.
Есть ЭВМ с Debian Wheezy, хочу гонять на ней пачку виртуалок с выходом в локальную сеть. Ту же самую локальную сеть к которой физически подключена ЭВМ.
Сейчас у меня такой /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.32.2
netmask 255.255.255.0
broadcast 192.168.32.255
gateway 192.168.32.254
bridge_ports eth0
В результате br0 получает статический IP 192.168.32.2, а eth0 почему-то по DHCP 192.168.32.204.
А я хочу чтобы br0 вообще не имел IP, а eth0 был 192.168.32.2. Как это задать в конфигах?
В Debian'е вообще возможно через /etc/network/interfaces задать br0 без адреса?
Смотрю лекции к courser'овскому курсу о LaTeX'е (кому интересно — ещё не поздно записаться, первое задание желательно успеть сдать до 25 мая), огорчаюсь. LaTeX отделяет содержание от оформления, да. Но вот множество вопросов по оформлению приходится решать самостоятельно. Хочешь нарисовать несколько формул — сам укажи по какому символу они будут выравнены, хочешь скобки в формуле — обычных символов "(" и ")" недостаточно, нужны специальные команды, хочешь кириллицу в формулах — подключи специальный пакет который может конфликтовать с другими пакетами (а на дворе 2014 год и Unicode).
Может быть были попытки создать издательскую систему на похожих принципах, но с другим поведением? Чтобы большее количество разнообразных типовых ситуаций обрабатывалось умолчальным образом, и только в специальных случаях пользователь мог вмешаться. Ведь все алгоритмы TeX'а и LaTeX'а известны.
Не могу понять чем принципиально инструменты для приёмочного (acceptance) тестирования отличаются от инструментов для модульного (unit), функционального (functional) и даже нагрузочного (load). Что я думаю не так?
Что мы имеем, например, в nosetests — инструменте для модульного тестирования python'ового кода:
Придумываем некоторое утверждение, например: «Функция вызваная с такими параметрами возвращает 4»
Пишем код для вызывающий функцию с нужными параметрами, возможно заменяем какие-то объекты mock'ами
Сравниваем результат
Что мы делаем для функционального тестирования? То же самое:
Придумываем или берём из ТЗ утверждение
Вызываем функцию или программу
Сравниваем результат
Что мы делаем в FitNesse, инструменте для приёмочного тестирования:
Придумываем или берём из ТЗ какое-то утверждение
Пишем вызывальщик функции или программы, возможно используем какие-то обёртки для вызова браузера или графической тестилки (Selenium, Sikuli)
Сравниваем результат
То есть шаги всегда одни и те же: вызываем действие, сравниваем результат. Почему бы тогда не пользоваться тем же nosetest'ом не только для модульного тестирования, но и в качестве пускалки python'овских сценариев запускающих нагрузочные тесты, функциональные тесты, Sikuli, прочее. В нашем распоряжении сразу оказывается язык с большой библиотекой, поддержка на уровне платформы (framework'а) таких вещей как фикстуры, сценарии запускаемые перед тестом, после теста, запуск из командной строки, возможность легко привязать к системе контроля версий. Зачем тогда городить FitNesse, который сам себе standalone вики с возможностью нажать кнопочку test и запустить примерно такие же скрипты, и ответ увидеть не в командной строке, а в виде зелёных прямоугольничков в браузере. Зачем всё это?
Intel показала разъём USB 3.1 Type-C. Я ДЖВА ГОДА ЭТОГО ЖДАЛ! Маленький как micro-B, разъём можно подключать так и сяк, кабель тоже можно подключать так и сяк (одинаковые разъёмы на ноутбуках, принтерах и т.п.).
Понадобилось мне тут познакомиться с «системным анализом». Результат знакомства удручил. Я привык, что если в названии дисциплины есть слово «анализ», то это будет МатАн (дифференциальное и интегральное исчисление) применительно к какой-то специальной области. Я ожидал, что в системном анализе будет введено понятие системы, введены операции над системами, воздействия, определено как система реагирует на эти воздействия и как меняется реакция в зависимости от изменения воздействия. А оказалось, что под словами «системный анализ» скрывается какое-то философское словоблудие. Взгляните, например, на этот учебник. Нет строгого определения ключевого понятия «система», нет ни одной формулы, от начала и до конца какое-то переливание из пустого в порожнее. Задача системного анализа системно анализировать системы. В Википедии и других местах примерно то же самое. При этом говорится, что на системном анализе основаны такие вещи как логистика и теория операций.
Что я делаю не так с системным анализом? Чем занимаются системные аналитики? Есть ли в их работе хоть толика математики? А может быть их работа на самом деле сплошная математика?
Samsung анонсировала Chromebook 2. Характеристики радуют. Экран с диагональю 34 сантиметра (13,3") с разрешением 1920x1080, 4 Гб ОЗУ, ARM'овский процессор с 8 ядрами на часторе 2,1 ГГц.
Скажите, на такой ноутбук можно поставить Gentoo, Ubuntu, что-то другое, или там огороженный по самое передать невозможно загрузчик? Какая там может оказаться видеокарта, WiFi, для каких железок есть свободные драйверы, для каких закрытые, а какие вообще не заведутся? Можно ли поставить GNU/Linux на основной накопитель, или из-за банальных ограждений только на внешнюю флешку?
Использую mock в модульных (unit) тестах. Столкнулся с тем, что могу заменить вызов оригинальных функций mock'ами в сторонних библиотеках и функций из того же файла что и тестируемая функция, но не могу заменить функции из других файлов моей же программы. ЧЯДНТ? Кто-нибудь сталкивался с подобным?
Попросили меня сделать из одной из машин сервер для нагрузочного тестирования. На нём будет только программа которую мы разрабатываем, а запросы будут подаваться с других машин. Встал вопрос, ставить ли Ubuntu на голое железо или на вируталки?
С одной сторын у виртуалок можно объём ОЗУ и количество процессоров менять, создать слабую конфигурацию и загрузить её нагрузочным тестом до самого падения.
А с другой стороны будут ли эти результаты соответствовать поведению программы на реальном железе? Есть ли смысл тестировать под нагрузкой на железе более слабом чем то что будет во время эксплуатации?
Есть ли какие-нибудь инструменты для проведения нагрузочного тестирования не-web'овых приложений? Есть у меня, например, программка, которая получив запрос лезет в Redis, берёт оттуда немного данных и принимает решение какой ответ вернуть. Нужно узнать сколько запросов в секунду программа способна обработать, как растёт время обработки одного запроса с ростом сложности запроса, сколько при этом потребляется памяти.
Я мог бы сам написать сценарий, который грузит программку запросами, потом обрабатывает файл журнала, вычленяет из него временные метки нужных событий, считает время обработки, находит среднее и т.п. Но может это ненужный велосипед? Может быть уже есть инструмент которым все с удовольствием пользуются?
Есть программа на python'е, есть модульные (unit) тесты к ней (nose). Хочу измерить покрытие тестами кода. Проблема в том, что запуск nosetests --with-coverage пробегает по тестам так же всех import'нутых модулей, а не только моих. Учитывая что код какого-нибудь numpy или pandas во много раз больше моего я получаю, во-первых, что coverage долго меряется, во-вторых, что даже печальнее, что вместо покрытия моего кода я меряю покрытие pandas'а, всегда получаю 21%.
Как померять покрытие только своего кода тестами? Только того кода который есть в некоторой директории, но не того который добавляется import'ами.
Я для проверки даже написал модуль с двумя тривиальными функциями уровня hello_world и один тест к этому модулю. Если нет import pandas, то nosetests --with-coverage говорит 44%, а если есть import pandas и вызов одной функции из него, то проверяется покрытие в pandas'е и numpy и отвечает 21%.
То есть в каждом файле объявлен свой logger (хотя все они привязаны к корневому logger'у).
В коде местами разбросаны вызовы logger.warn(), logger.info() и прочие.
При запуске nosetests естественно в консоль валится некоторое количество сообщений от logger'ов, что засоряет выхлоп (особенно это мешает в логах Jenkins'а). Можно как-то запустить nosetest с опцией подавления вывода логов уровня ниже WARNING или ERROR? --logging-level= не помогает. Вызываю nosetests --logging-level=ERROR, но в консоль всё равно выводятся WARN'ы и INFO.
Есть Ubuntu поставленная через netboot. Какие пакеты нужно поставить чтобы работать с i3?
Мне ведь не нужно для этого ставить ubuntu-gnome-desktop или ubuntu-desktop (Unity)? Но ведь нужно поставить X и GDM/LightDM.
Переключалку клавиатуры можно настроить через setxkbmap. А как получить такие привычные вещи как автомонтирование флешек, network manager (чтобы WiFi'ки подхватывались) и прочие? Или правильный путь в данном случае поставить сначала ubuntu-gnome-desktop, а потом заменить metacity на i3?
В готовящейся к выпуску версии Ubuntu Gnome 14.04 есть ошибка — клавишу CapsLock нельзя установить для смены раскладок. Конкретный баг, виден, повторяем. Где найти правильный багтрекер в который стоит сообщить об этом?