четверг, 16 апреля 2015 г.

Поймал забавную ошибку при построении docker image

Наткнулся на забавную проблему, захотелось поделиться решением.

Я последнее время полюбил для публичных образов докера строить их не у себя а в облаке docker hub.

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

Удобно, не требует ресурсов, дополнительный контроль, и нет необходимости а значит меньше возможности сделать ошибку с распространением образа.

Но вчера, один из моих образов отказался собираться напрочь.

Получаю вот такое сообщение:

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

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

И конечно ж:

Пакет mysql захотел получить пароль пользователя с консоли.

И висит так бесконечно, до таймаута.

Решение,запускать так:
RUN DEBIAN_FRONTEND=noninteractive apt-get install

Эту мелочь я всё время забываю.

Новый pkg на freebsd



Прочитал новость:
Разработчики FreeBSD представили релиз пакетного менеджера Pkg 1.5

У меня фрях в эксплуатации много, и в целом я этой новости рад.

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

Ну иногда, разок, для особых опций можно,но постоянно — надоедает.


Особенно, теперь, когда из за какой то загадочной криворукости летом 2014 намеренно сломали make.

Я с большим интересом слежу за развитием pkg по вышеуказанным причинам.

Он уже действительно быстр. Просто освежающе быстр, когда видишь, начинаешь удивляться, эмм, а чем же тогда apt занят?

Но проблем ещё полно.

Я постоянно наталкиваюсь на такой сценарий, когда внезапно в репозитории нужного пакета нет, и ты вынужден поставить его из портов, и вдруг увидеть:




Лень вникать как именно это происходит, но происходит подмена библиотечных зависимостей для пакетов установленных с помощью pkg.

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

Но прогресс заметен, надежда есть.

После pkg останется лишь дождаться человеческого jail в стиле docker.


понедельник, 13 апреля 2015 г.

Улучшаем переключатели pulseaudio в awesome-dm

Регулятор громкостей различных наушников у меня уже есть на панели awesome-dm.

Выглядит аскетично:

Как его сделать, писал вот тут.

Теперь захотелось к нему добавить мгновенное переключение вывода звука.

Не просто set-default, а еще и  всё что уже проигрывается переносить в нужный вывод.

Для этого будем использовать вот такой скрипт:
#!/bin/bash
   
if [ -z "$1" ]; then          
    echo "Usage: $0 <sinkId/sinkName>" >&2
    echo "Valid sinks:" >&2
    pactl list short sinks >&2
    exit 1
fi 
   
newSink="$1"
   
pactl list short sink-inputs|while read stream; do
    streamId=$(echo $stream|cut '-d ' -f1)
    if [ "$streamId" -gt 1 ]
    then
        echo "moving stream $streamId"
        pactl move-sink-input "$streamId" "$newSink"
    fi
done
Забираем всё что проигрывается,
потоки номер 0 и 1 пропускаю потому, что они у меня виртуальные, там находится remapped sink,
и через move-sink-input перенаправляю в нужный источник.

Впишем вызов этого скрипта в pulseaudio.lua
function SwitchTo(i)
    local f = io.popen("pa_switch.sh " .. i )
    local v = f:read()
    f:close()
end

И навешаем левый клик по регулятору громкости на вызов этой функции.
     volumewidget0:buttons(awful.util.table.join(
      awful.button({ }, 1, function() pulseaudio.SwitchTo(1); end),
Можно улучшить избавившись от констант номеров звуковых карт, но у меня они почему то не меняются,  и я ленюсь.

Теперь что бы перенести все звуки на конкретные наушники/колонки нужно щелкнуть по нужному регулятору громкости.



четверг, 2 апреля 2015 г.

Прекрасное средство — aptly

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

Свежий, не битый, полный сил и здоровья админ с удовольствием ставит libfoobar-0.11.beta в продакшен в ту же ночь как она релизится. И с большим упоением следит за changelog выискивая там что-нибудь новенького.


Те натруженные ребята что уже имели опыт множества таких обновлений и бывали сильно биты коллегами, больше любят тренироваться на кошках, и прогонять какие-либо тесты в специальном окружении. Могут легко пропустить пяток версий используемого софта.

В некоторых случаях, если команда девелоперов или менеджеров погоняющая такого админа слаба, софт перестает обновляться «навсегда». Работает — отойди.

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

Но, за последнее время я заметил, один небольшой, но новый нюанс в этом движении.

С современным развитием виртуализации, включая контейнерную, с современным средствами подготовки и управления образов, разнообразными packer, ansible и т.д. на одно из первых мест, для меня, выходит возможность гарантированной возможности получить в точности тот же образ что и на другом железе/облаке/где-либо ещё.

Средств для этого много, но был у меня  один «непокрытый» момент.
Я как-то очень уж смело полагался на содержимое внешних репозиториев debian.

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

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

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

Оказалось, что всё уже придумано за нас: http://www.aptly.info/, Автор - Andrey Smirnov.

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

Рекомендую!


воскресенье, 11 января 2015 г.

Очередной привет дебиану от systemd.

Я привык debian на своей рабочей машине обновлять пару раз в месяц через dist-upgrade.

Обычно, это все без сучка без задоринки проходит, настолько, что хочется даже иногда просто в crontab засунуть это обновление.

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

dist-upgrade падает, просит -f  install для исправления, а тот выдаёт вот такую вот портянку:

Чтение списков пакетов… Готово
Построение дерева зависимостей      
Чтение информации о состоянии… Готово
Исправление зависимостей… Готово
Будут установлены следующие дополнительные пакеты:
  libpam-systemd
Пакеты, которые будут обновлены:
  libpam-systemd
обновлено 1, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 201 пакетов не обновлено.
не установлено до конца или удалено 11 пакетов.
Необходимо скачать 0 B/120 kB архивов.
После данной операции, объём занятого дискового пространства уменьшится на 4 096 B.
Хотите продолжить? [Д/н]
Чтение журнала изменений... Выполнено                
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: слишком много ошибок — останавливаемся
При обработке следующих пакетов произошли ошибки:
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
Обработка остановлена из-за слишком большого количества ошибок.
E: Sub-process /usr/bin/dpkg returned an error code (1)
systemd уже близок. Уже тут.

Надо менять свои привычки. Какие такие обновления? Работает хоть как-то?
И то хлеб, сплюнь и не трогай.

Конечно ж, это частная и мелкая проблема, но однако
а) оцените портянку? Зачем оно 130 раз одно и тоже апгрейдит? Что вообще можно понять из этого бреда.
б) раньше то однако не случалось. Началось с приходом счастья от systemd.

Очень, очень надеюсь, что или у devuan всё получится, или ещё будут успешные форки.



четверг, 25 декабря 2014 г.

Закончил курс по haskell. Свежие впечатления.

Закончил курс
FP101x Introduction to Functional Programming
на edx.com

Определенно вхожу во вкус функциональщины всё больше и больше.

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

Другое дело, что конечно, ребята наработали уже просто огромную базу. Начинаешь понимать. что тут дело на в мапах и не в high order functions — этим как раз никого не удивишь. А скорее в общем объеме. Ум за разум заходит как увидишь готовое решение со всеми этими моноидами когда закончишь лабу. А по отдельности, пока пишешь - очень даже ничего. Хороший метод декомпозиции задач.

Но я хотел написать не про собственно функциональщину, а про курс.

Оставил он смешанные чувства.

Плюсы:
  1. Очень интересный, вряд-ли его можно назвать "начальным", но мне как то в уровень попало. И не скучно и не сильно тяжело.
  2. Лекции мне понравились, все за исключением серии про монады. Чего там хотели добиться не понимаю. Явно что то перемудрили.
  3. Лабы - крутые реально, клево так придумали, что дают задание. которое ты выполняешь. что то высчитываешь и заливаешь им на проверку не саму прогу а ответ какой то зашифрованной ими функции. Типа такого:
    Крутая идея и крутая реализация, просто молодцы. И руками такое не посчитаешь - приходится прогу написать, и в тоже время никакой мороки с тестированием.
    И сами задания — интересные. Прямо хочется решить.
  4. Определенно хочется продолжать, было впечатление что окончилось внезапно. Это я считаю плюс.
Минусы: 


  1. Главный основной минус это задания послед лекций  (homework), на мой вкус — просто отвратительно. Что тестирует вот такой тест:

    В лучшем случае моё зрение. Но точно не о программировании он. Но это ягодки. Как вам такой:
    Бредятина на 10 экранов которую надо в уме распарсить и найти правильное решение из 4, а отличаются они парой символов.

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

    Это хорошо видно на графике моей успеваемости:
    Те homework где прогресс по 5% это они и есть. Меня это настолько раздражало что только из за этих заданий хотел бросить курс многократно.
  2. Jam sessions ну очень странные, я их записал в простую потерю времени. Ни идеи этого не понял, ничего полезного не вынес. Какая то ерунда.
  3. Мне не показалось что из этого курса можно что то целостное получить. Так, вариации на тему крутых хаскельных штучек, привлечь внимание.

Я так понял это первый запуск этого курса, можно простить некоторые шероховатости с заданиями ( а лучше их совсем выкинуть).

Плюсов очевидно больше чем минусов — думаю можно советовать курс всем заинтересованным функциональщиной.

    воскресенье, 21 декабря 2014 г.

    Vagrant docker provider — как средство оркестрации.

    Короткий пост про признание ошибок.

    Больше месяца в черновиках у меня висел пост о том, как я пытаюсь использовать
    vagrant --provider=docker
    для управления многими связанными контейнерами docker.

    Что б так сказать запустить в нужном порядке,  связать, настроить и т.д. То, что хочется назвать orchestration.

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

    Как свинью стричь: визга много - шерсти мало.

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

    Поищу другой инструмент.




    четверг, 18 декабря 2014 г.

    Подсветка ruby в vim

    Пришлось тут немного на ruby писать.

    Ну как минимум, плюс из этого что перестал на  конфиг файлы Vagrant смотреть с отвращением.

    Не то что б полюбил, но свыкся.

    Посмотрите на картинку к посту. Видите что последние два end окрашены по разному? Один в цвета if — потому что к нему относится, второй в цвета def.

    Я и не знал что vim так умеет. да ещё и из коробки.  Очень удивился.

    И в целом, как  к языку к Ruby особых претензий нет, perl - perl-ом,  с претензиями на оригинальность.

    Но вот gem-ы их, и в целом инфраструктура — вечный адъ какой то. Не помню случая что б "просто работало".

    среда, 17 декабря 2014 г.

    ООП в контейнерах docker

    Каждая новая команда изменяющая состояние контейнера в Dockerfile создает новый образ диска- image.

    Посмотреть их можно через docker images. Мне очень нравится ключ --tree к ней, но не понимаю почему они её пометили как depricated.

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

    К примеру два контейнера с такими Dockerfile:
    FROM debian:testing
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y ssmtp
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y net-tools
    и второй с другим порядком команд
    FROM debian:testing
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y net-tools
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y ssmtp
    Построят 4 разных образа, два промежуточных, два конечных, плюс debian-testing.

    Но функционал то будет одинаков - фактически пустая потеря места, и лишняя сложность.

    Вот так выглядела часть дерева моих образов docker

     Один общий далекий предок debian/testing и затем огромная куча разных промежуточных образов.

    Рефакторим это. Выделим общие настройки и софт в base образ, и унаследуем остальные от него.

    Теперь дерево выглядит так:

    Не идеально, но лучше.

    Общий предок стал гораздо ближе к листьям дерева, значит больше дискового пространства стало общим.

    Если вам не нравится большие развесистые деревья можно в dockerfile объединить команды в одну
    RUN command1 && command2
    тогда на две команды будет только один образ.
    К реальному уменьшению потребления дискового пространства это вряд-ли приведет, но дерево будет аккуратнее.
    Я так иногда делаю с теми образами которые уже не меняю.
    Но для часто меняемых и перестраиваемых предпочитаю иметь команды отдельными строками.
    Docker умеет кешировать, и не перестраивать неизменяемые состояния, что очень удобно.

    Автоматизируем написание хороших сообщений к коммитам git

    Все знают как сложно написать хороший commit message.

    К нему предъявляются особые требования:
    -  быть кратким
    -  правильно оформленным
    -  придерживаться определенного стиля

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

    Ну вот пример. Google по фразе good commit message показывает
    Результатов: примерно 12 000 000 (0,35 сек.)

    Не шутки.

    Но я нашел способ решить эту проблему. Эта деятельность легко автоматизируется.

    Возьмем, в помощь mojolicious, ну как же без duct-tape. Если у вас его еще нет, ставьте:

      apt-get install libmojolicious-perl
    Вторым инструментом будет вот этот замечательный сайт  он анализиует ваши изменения и автоматически предлагает отличный текст.

    Осталось лишь прописать в ваш шел, вот такой вот алиас

     git commit -a -m "`perl -Mojo -E "say g('http://whatthecommit.com/')->dom->at('div#content p')->text"`"

    ну например на git-auto, или что вам там нравится


    Всё, одной проблемой в жизни меньше.

    вторник, 16 декабря 2014 г.

    Как docker делает админов ленивыми.

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

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

    Да и анализ логов показывает, что переодично какие то дети пытаются чего то там применить. Лучше уж я первым про это узнаю.

    Глобально путей проверить это два:
    - или по базе установленных пакетов проверить базы аудита
    - или самому атаковать снаружи.

    Первый путь мне нравится меньше - машины разнотипные, да и что мне переживать за уязвимость в установленном пакете, если он  например не используется.

    Пошел по второму пути. Ну не руками же такое делать?

    Есть некий framework metasploit, содержащий базу експлоитов, и умеющий их применять.

    Немного гемморойный в установке, ну ничего такого страшного.
    Postgres то сё, сборка ручками.
    Поставил, побаловался - надоело быстро.

    Сразу стало понятно, почему это именно фреймворк а не готовое решение.

    Погуглил, нашел armitage - оболочка поверх этого фреймворка автоматизирующая рутину.

    И тут же, в этом же запросе в google мне попался Dockerfile для него.

    Ну,  даже интересно стало, неужели счастье близко.
    И правда, docker run - и всё, сразу работает, само расправилось и с постгрей и с metasploit , поставило и настроило всё,  и выдало поверх этого мне vnc — заходи и сразу работай.

    Удобно? Да, прямо очень. Особенно для моей разовой задачи, поставил - просканировал - снёс - забыл.

    Но, ммм, если подумать. Не пришли ли мы в c:\program files\ схему?
    Точнее в комбинацию этого и каких то fat jar?

    Ну для разовой задачи, вопросов нет - удобно и может в чём то лучше даже, не насилуем пакетный менеджер, не оставляем следов в host системе.

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

    Большая тема для раздумий.

    пятница, 12 декабря 2014 г.

    «Вшиваем» часть ansible playbook в образ с помощью Packer.io

    В продолжение темы замечательного packer.io, рассмотрим вариант когда часть playbook-а общая для всех хостов, и очень редко изменяется.

    У меня такая есть: некий common.yml. Зачем каждый раз проигрывать эти изменения на хостах, если можно заранее проиграть их на образе из которых мы эти хосты строим.

    А уж остальные, часто изменяемые, или уникальные playbook-и будем играть на vagrant или на vds уже руками.

    В случае packer эта часть называется post-provisioning.

    Умеет кучу всякого разного: chef, puppet, скрипты, но я медленно и верно ухожу на ansible, его и буду использовать.

    Итак, в предыдущей серии мы получили образ нужного нам debian-а в виде vagrant box.

    Изменим конфигурацию packer, добавив туда наш рецепт ansible.

    Мне проще в этот же репозиторий добавить submodule, чем высчитывать путь, поэтому:
    git submodule add https://github.com/korjavin/ansible-for-clouds provisioning

    И в конфиге вписываем:
         {  
          "type": "shell",
          "execute_command": "echo 'vagrant' | {{.Vars}} sudo -E -S bash '{{.Path}}'",
          "inline": "apt-get -y install ansible"
        },
    установку собственно ansible, так как запускать мы будем ansible-playbook «изнутри» хоста, а не «снаружи», то придется его иметь.

    И прописываем путь к рецепту:
        {
            "type": "ansible-local",
            "playbook_dir":"./provisioning",
            "playbook_file": "./provisioning/local.yml",
            "playbook_paths": [
                     "./provisioning/"
                           ],
             "role_paths": [
                "./provisioning/roles/"
             ],
            "staging_directory":"/tmp/stage"
        }
    Я отдельно добавил себе playbook local.yml, для того что бы прописать в нём
    - hosts: 127.0.0.1
      sudo: yes          
      connection: local
    Без этого ansible-playbook запускался от vagrant без sudo.

    И оставил в local.yml только те свои роли, которые я хочу иметь "вшитыми" в образ.

    Всё чудесно срабатывает:

    И в итоге у меня есть механизм удобного получения этих образов из текущего среза debian и набора playbook.

    Теперь, можно комбинировать: построить этот образ, включив в него только хорошо протестированные playbook-и.

    Затем отладить остальные ansible playbook-и на этом образе в vagrant, экономя время на каждом запуске, и затем после отладки: или выставить в production на vds/bare metal, или итерационно перейти к шагу один и вшить протестированные рецепты снова в образ.



    Packer vs debian testing: И вновь продолжается бой!

    Неожиданное продолжение вот этого поста.

    Вдруг меня осенило: зачем бороться с багами в daily image дебиана, если есть же weekly image.

    Поправил url и sha512 в конфиге, вернул обратно partman-auto-lvm в preseed.cfg, и дело пошло.


    Образ (box) для vagrant удачно построен.

    Теперь быстрее будет играться с с этим на локальной машины, так как долгий этап обновления до testing пропущен.


    Но, я также увидел и минус в этом.

    Если для Amazon и прочих продвинутых я этим же packer построю образ, и он будет совпадать с моим локальным, то для других хостеров машины которых я с 7.5 и 7.7 обновляю до текущего среза testing — каждый день расхождение будет увеличиваться.

    И это скорее плохо: вполне могут появится какие то баги, которые на локальном окружении (от сегодняшней сборки) отсутствуют, а на завтрашних срезах могут появится. Нет предсказуемости.

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

    Что ж, ну пусть пока так, тоже шаг вперед.
    В дальнейшем  может найду себе импортозамещающий хостинг который позволит мне загружать сразу образ целиком.

    Пока я только у vdsina видел возможность iso указать при создании vds.
    Но, я ещё не пришел к решению их использовать, уж очень там своебразная админка, не проникся ей, поэтому не пробовал создание из iso.


    Эволюция svchost.exe (зачеркнуто) systemd.


    Люблю, когда утро начинается  с прекрасной новости.

    В этот раз, она особенно хороша:

    Выпуск systemd 218 со встроенной поддержкой PPPoE

    Также, среди прочего важного, в релиз попало и:

     - База данных аппаратного обеспечения (hwdb) udev'а теперь содержит базу данных разрешений оптических сенсоров мышей.

    Что тут сказать. Отлично.

    С нетерпением жду момента, когда systemd заменит недоразумения типа отдельного ядра, внешних драйверов оборудования и программ, интегрирует в себя ffmpeg и включит хотя бы простенький движок на webkit.

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

    Я понял, что хочу помогать этому процессу. Чем быстрее поттеринг со своими друзьями реализует svchost.exe, тем быстрее они отпочкуются в свою собственную вселенную, может даже emacs там перепишут себе.



    Картинка к посту намекает на это видео:



    четверг, 11 декабря 2014 г.

    Попытка построить debian testing box для vagrant c помощью packer

    В случае облаков, особенно если они не Amazon и не Digital Ocean, а вполне себе обычные российские хостеры, надеятся на широкий выбор базовых образов — увы, не приходится.

    Если есть debian 7.х это уже достаточно хорошо.

    Но мне обычно нужно посвежее, я привык сидеть на debian testing, со всеми мякотками docker-ов и свежих ядер.

    Поэтому обновляю сразу после создания через ansible.

    Но для локальных образов типа виртуальных машин libvirtd и virtualbox которые я поднимаю с помощью vagrant: поднимать сначала чистый debian 7 а затем обновлять его до testing — тратить лишнее время в пустую.

    На момент написания этой заметки в vagrantcloud не было готовых образов (box) для debian testing.

    Поэтому попробуем построить их с помощью packer.

    Вот репозиторий с конфигурацией packer, большую часть я успешно форкнул, подменил лишь url на нужный образ, убрал не нужный мне chef и puppet.

    Изменил также, механизм с sudoers, я не понял как они хотели использовать это:
    # Set up password-less sudo for user vagrant
    echo 'vagrant ALL=(ALL) NOPASSWD:ALL' > /etc/sudoers.d/vagrant
    chmod 440 /etc/sudoers.d/vagrant
    Тут же проблема, курицы и яца, что б добавить такую строчку надо уже быть root, что бы быть root нужна такая строчка.
    Вот тут вот есть объяснение, но я всё еще не понял как это может работать.

    Мне показалось проще решить это через вынесение в preseed.cfg как:

    d-i preseed/late_command string sed -i -e 's/vagrant\tALL=(ALL)\tNOPASSWD: ALL' /etc/sudoers



    Ну и тут начались прелести night-build.

    Наткнулся на странный глюс с part-auto в debian-installer, ни  с lvm ни без неё он работать не хотел.


    Оказывается, баг в инсталлере:


    На мой взгляд, они забыли ext4 вкомпилить, но я не стал копать.

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

    И ещё вот тут, даже на русском.


    Запускаем
    packer build debian-testing

    И мучаемся с отладкой.

    Что бы видеть что происходит в виртуалке, я отключаю headless в false.

    К сожалению, сегодняшний nightly build оказался совсем уж кривым.

    После мучений с разбивкой, появилась проблема с grub2.
    Даже когда оно устанавливается, затем почему то не грузится.

    Что ж, тем лучше. Ценный опыт  и ответ на возможный вопрос почему debian/testing нет в vagrantcloud.

    Либо попробую еще раз через пару дней, когда они build обновят.
    Либо есть ещё куча вариантов, можно сменить netinst на другой образ, можно попробовать построить самому этот образ, или освоить preseed дял их нового инсталятора, которые di-2 сборки.

    Также остается беспроигрышный полу-ручной вариант.
    Взять box с 7.7, накатить туда full-upgrade через вот этот playbook ansible а затем уже тем же packer перепаковать его снова в box.

    С таким количеством вариантов, продолжение неминуемо следует.





    среда, 10 декабря 2014 г.

    Апгрейд debian до testing с помощью ansible

    К сожалению, идеального софта не бывает. Менеджер пакетов APT — не исключение.

    Наткнулся на то, что при обновлении с debian 7.5  и 7.7 до сегодняшнего среза testing apt-get full-upgrade не справляется то с некоторыми циклами зависимостей, то с отдельными пакетами, то почему то с man-db и падает в процессе.



    В некоторых, особо запущенных случаях, требуется затем трижды запускать цикл apt-get install -f , и затем опять full-upgrade.

    Печально, но большой трагедии нет. Хоть один раз запускать хоть три. Главное что?
    Главное что бы работала машина а не человек.

    Для этого в ansible у нас есть ignore-errors.

    Ляпаем  вот такой вот workaround в процессе:
    - name: update                
      apt: update_cache=yes
    - name: upgrade               
      apt: upgrade=full           
      ignore_errors: yes          
    - name: install -f            
      command: apt-get -y install -f 
      ignore_errors: yes          
    - name: upgrade second try    
      apt: upgrade=full           
      ignore_errors: yes          
    - name: install -f second try 
      command: apt-get -y install -f 
      ignore_errors: yes          
    - name: upgrade third try     
      apt: upgrade=full   
    И оно теперь отлично обновляется.
    В случае же, если срез testing изменится. и ошибка пропадет - мы ничего не потеряли.

    Второй и последующий запуски просто не меняют состояния.

    Целиком playbook на github

    Белка, колесо и systemd — неразлучные друзья.

    С приходом systemd в debian, каждое обновление стало замечательным квестом приносящим сюрпризы.

    Как я уже писал про тошнотворных дебилов хранить настройки системы в /usr/share/ признак этих самых дебилов.

    Конечно же, apt-get upgrade молча их перезаписывает.
    Он то на людей расчитан, а не на фанбоев системд в кожаных штанишках. Он конечно же мержит настройки в /etc, но забивает на /usr/share.

    Как результат, опять сломаны права.


    Причем этот ваш systemctl даже не смущает что  у него tty нет. Оно спокойно выплевывает запрос пароля в никуда и виснет.

    Я вдруг начал думать, а что если такое вот поспешное введение systemd в debian, вовсе не глупость, а намеренная диверсия.

    Непонятно только против кого диверсия?
    Чем больше людей это попробуют, тем быстрее закопают systemd или тем быстрее мигрируют с debian. В чём именно цель?

    вторник, 9 декабря 2014 г.

    Плавная миграция Puppet -> Ansible

    Надоели мучения с puppet. Иногда лучше час потерять, а затем за пять минут долететь — решил я, и начал принудительно все новые настройки раскатывать через ansible.

    Пока доволен. В зависимости ролей через meta/main.yml вообще влюбился уже.

    Почти ничего с работы показать нельзя, но вот мелкий рецептик, который для себя сделал ­— без секретов.

    Поделюсь им.

    Для нетерпеливых, вот целиком репозиторий на github.

    Ничего особенного. но мне полезно.
    Что оно делает, берет некий стабильный debian 7, который выдается почти любым провайдером vds.

    Обновляет его до debian/testing, настраивает минимально необходимый софт, screen, git, vim, zsh.

    Клонирует мои настройки vim с github, и настраивает zsh с помощью oh-my-zsh.

    Ставит docker и несколько сетевых пакетов.


    Мне это нужно, для очень простой вещи. В рамках своего импортозамещения я тестирую российские vds просто пачками.

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

    Подробные результаты будут позже, но забегая вперед: уже есть кандидаты на замену Digital Ocean.


    Итак, какие фокусы я использую в этом репозитории.

    Первый: установка simplejson модуля питона через модуль ansible raw.

    Благодаря этому, я совсем никогда не захожу на эти vds что б создать условия для работы ansible. Он создает их себе сам.

    Второй: модифицируем PATH для команды apt-get install.
    Удивительный какой то факт, не на всех хостингах, но иногда я сталкиваюсь с тем что start-stop-daemon и прочие команды из /sbin не могут быть выполнены.
    Делаем это прописав в роли
      environment:                
        PATH: /usr/sbin:/sbin/:{{ ansible_env.PATH }}
    Третий: Используем простые зависимости, типа:
    dependencies:
          - { role: zsh }         
          - { role: sudo }        
          - { role: vim }

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

    Четвертый: Используем как файлы и из этого репозитория
      copy: src="screenrc" dest="/root/.screenrc"
     так и файлы из хост машины
    key="{{ lookup('file', '/home/iv/.ssh/id_dsa.pub') }}"

    Пока всё. 

    Следующая серия будет про управление docker контейнерами через ansible.

    четверг, 4 декабря 2014 г.

    Практикум на Haskell и/или Ocaml.

    Зная про себя, что я подвержен синдрому утёнка, про который лурк пишет гораздо понятнее, чем википедия:

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

    Что бы не попасться в эту ловушку (а то я так однажды уже попал на perl ),  совместно с курсом про standart ml на coursera я начал проходить курс по haskell на edx.



    Ссылки:
    Я неизбежно их сравниваю. Поделюсь этим сравнением.

    Курс  Dan Grossman на coursera просто отличный. 
    Вся та часть что относится к sml отличная. Изложение понятное, и местами натурально захватывающее, о ряде проблем поднятых там я никогда не думал, и в целом целая куча новый открытий, что не может не радовать.

    Домашние задачи и практические работы - на пятерку. Всегда приходится напрячься и подумать, но не настолько сложно что б хотелось бы бросить.
    Задания точно сформулированны и довольно интересны. Ну кажется я это писал.

    У преподавателя отличная дикция, примеры, скорость, всё на уровне. Подача довольно сухая, но мы ж тут не за развлечениями.

    Я даже довольно хорошо сдал экзамен по этому разделу



    Курс от @headinthebox  совсем другой. Я подозреваю, что лектор скорее программист чем преподаватель.

    Довольно много своеобразного юмора, и в лекциях, и в текстах, который я впрочем оценил. Что то вроде:
    Но порой мне сложно понять речь, приходится возвращаться, ну спишем на мой плохой английский.

    Содержание отличное, несмотря на то что sml курс шёл с опережением, всё равно полно новых и интересных вещей и концепций.

    Но что начисто отвращает, это домашние задания. Не могу сказать про них ничего положительного.

    В первых нескольких лекциях, как мне показалось, слегка перепутали порядок, и в итоге вышло что то вроде.
    Ты сам нагуглил и освоил что то для выполнения задания 1, а потом тебе это же повторно рассказали в лекциях 2.

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

    Причем, текст выполнен картинками, что б не скопировали в REPL.
    Хотите проверить машиной?
    Наберите 10 вариантов в 20 вопросах с картинки всякого бреда, и интерпретатор покажет вам неверный порядок операндов или пропущенную кавычку?

    Ужас. Зачем? Категорически отрицаю полезность такой ерунды.
    В итоге "с таким настроем слона не продать" не могу себя заставить вчитываться в эти мелочи, и похоже курс провалю.
    Пока прогресс не радует:
    И это я сейчас уже попривык, а когда первую такую муть увидел, хотелось немедленно бросить.

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

    И хочется курс закончить, и не могу смирится со способом тестирования.
    Ну и переходя от лирики к практике.
    Я знаю что любые знания не подкрепленные массивной практикой — бесполезны, и будут забыты немедленно.
    Выходит, нужно закрепить.

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

    Проекты есть разные, есть мелкие веб сайтики, к примеру: что то собрать по api с других проектов, или сграбить с  html, переобработать и выставить, есть и другие, когда нужно наоборот вести какую то базу и предоставлять api наружу.
    И тут, я забуксовал. Ну не с нуля же реализовывать http сервер на haskell? 

    Должны быть общепринятые распространенные фреймворки и всякое такое.

    Посоветуйте пожалуйста, что лично вы использовали и какие впечатления остались.