Re: [room] манагерско-разработческое

["Денис Смирнов" <mithraen@altlinux.ru>]

On Mon, Jun 11, 2007 at 01:25:22PM +0300, Michael Shigorin wrote:

>> Меня не устраивает alterator со своими вечно меняющимися интерфейсами.
MS> Я это объяснял Стасу, но с пониманием проблем по взаимодействию
MS> довольно трудно, поскольку оного взаимодействия скорее нет и
MS> делает он всё примерно сам (коллеги в пределах слышимости не
MS> в счёт по очевидной причине, а те, кто порывается, но в итоге
MS> заканчивается пшиком -- по другой столь же очевидной).

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

Замкнутый круг. Да и модули уже имеющиеся далеки от идеала. Конкретно
сейчас мне трепет нервы /vm и собственно установка base пакетов. Вторая
отсутствием внятных репортов об ошибке с попыткой делать вид что все
нормально, а первый я сейчас пытаюсь поймать за руку, чтобы увидеть что
таки происходит неправильно. Увы, в VMWare у меня не получается
переключиться на другую виртуальную консоль чтобы в логи залезть.

>> Меня не устраивает отсутствие text-mode interface к альтератору.
>> Меня не устраивает отсутствие у ALT системы стендов, на которых
>> прогоняется каждое ядрышко попадающее в Сизиф.
MS> Тут мне проще, в смысле good enough.  Скорее с xorg стенд бы не
MS> помешал.

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

>> Все это мне лично мешает. Только вот я понимаю, что для решения
>> первой проблемы нужно команду alterator'a увеличить, и ничем
>> кроме него не загружать. Это деньги.
MS> Нужно разгрузить Стаса на несколько месяцев и дать выход на
MS> толкового эксперта по предметной области и языкам (довольно 
MS> разумно выбранным, как по мне).  Я надеюсь познакомить их 
MS> как-то с нашим Витей Советовым, но вот не знаю, получится ли
MS> вытащить его на LF или нет.

Знаешь, сначала по поводу Scheme я бесился, типа "ещё бы BrainFuck какой
выбрали", но посмотрев внимательно понял что выбор действительно очень
удачен. Правда отсеивает тех, кому попросту лень ознакомиться с ещё одним
языком программирования, что не очень хорошо.

MS> С тем, чтобы спокойно подумать над тем, какие места были плохо 
MS> или наспех продуманы или реализованы и не спеша разметить то,
MS> как оно должно быть.  При этом рассказывая kirill@ или azol@
MS> по ходу, что к чему (наверное, хорошо бы с ощущениями кого из
MS> недавно влезших в создание модулей альтератора, как bga@ или
MS> dim@).

Скорее уж хотя бы что-то аналогичное javadoc/doxygen прикрутить. Чтобы эти
самые интерфейсы были хоть как-то полноценно документированы в одном
месте.

MS> Думаю, сейчас вполне достаточно экспериментальных данных и
MS> ощущений для того, чтобы хватило просто спокойного цельного
MS> куска времени и чтоб никто не дёргал со срочняком.

Это да. Только вот тут Server-K, Desktop, SOHO и прочие кошмарики делать
надо, причем "к позавчера".

>> Для третьего нужно и помещение, и оборудование, и питание этого
>> оборудование, да ещё и кондиционирование этого оборудования.
>> Это огромные деньги (хороший такой стенд будет стоить от 200k$
>> и выше).
MS> Мне кажется, скорее осмысленно тут работать с железячниками и у
MS> них, чем городить _обновляемый_ или ненужный полный стенд у себя.
MS> Это "кажется" в т.ч. основано на своём опыте как горожения
MS> стендов, так и работы у железячников: у них получается находить
MS> грабли, у себя (с конкретными железками, проблемы которых
MS> идентифицированы) -- решать.

В целом логично. Только насчет обновляемого -- ты помнишь как сам
матерился когда-то про "нечестные i586"? Притом что "честные i586" ещё
поискать надо. Да и матюки на уровне "а что это ваш супер-пупер
дистрибутив на мой i486 ставиться не хочет, непорядок!" проскакивают. При
том что у железячников как раз такого железа днем с огнем не найдешь.

А ещё прогонять тесты нужно, фактически, после каждого обновления таких
компонент, как:
 - иксы;
 - udev;
 - kernel-*;
 - libhw
 - hwdatabase
 - а я ещё всякие smartmontools вспомнить могу

в общем ты понял :)

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

MS>Ю> 14 часов вообще-то плохо, способствует ускоренному выгоранию.
>> В курсе. Осенью собираюсь в отпуск таки свалить, первый раз за
>> последние 5 лет.
MS> Если не придумаешь, куда -- я вот думаю, а не выбраться ли опять 
MS> к друзьям в Севастополь и таки на этот раз добраться в Соколиное.

Интересная мысль :) Хотя я всерьез подумываю о том, чтобы отдохнуть тут
под Москвой в неплохом санатории. Под Москвой потому, что не уверен что
будет возможность к фуллтайм отдыху, боюсь руку на пульсе все равно
держать придется.

> >>> У нас только один ядерщик, который делает титаническую работу.
> >>> Это да, проблема очень большая.
> MS>> Два активных (не знаю, насколько сейчас wrar@ машет напильником 
> MS>> в той области или утомился; shrek@ свои сборки публикует, но без
> MS>> претензий на дистрибутивизацию).  Костика ты незаслуженно забыл.
>> Уже после отправки письма вспомнил, и сразу вспомнил почему забыл.
>> Проблемой совместимости с железом и т.д. занимается все-таки у
>> нас один vsu@, а lakostis@ мучает ovz с wks.
MS> Извини, это тоже не плёвое дело.

Я в курсе :( Но таки std у нас занимается один человек, и этого
катастрофически нехватает.

Вот я сейчас вижу что все мои проблемы с ztdummy можно решить портировав
из последних ядрышок к нам все обновления к hrtimers. Но это можно сказать
ядро самого ядра, и без вычитывания каждой строчки кода такое делать
нельзя. И меня совесть мучает даже обращаться к vsu@ по этому поводу.

А вот Костика скоро придется немного помучить, ибо на ovz у меня один
драйвер попросту не собирается. Вообще не собирается :)

>> У меня сейчас основная тема для того чтобы плакать горючими
>> слезами -- ACPI в последних std, из-за чего у нас модуль
>> ztdummy без acpi=off попросту неработоспособен на многих
>> машинках.
MS> А что, есть варианты?

Разобраться от чего у RTC крышняк уносит без acpi=off. И ведь работает
этот RTC сам по себе, а когда к нему ztdummy цепляется в логах вижу
сообщения про потеряные прерывания.

>> Угу. На самом деле сейчас ставить задачу именно конкурировать с
>> хостинговыми решениями это сложновато.
MS> Да и бессмысленно.  Лучше начать делать для себя, а если другим
MS> понравится -- ну ой ;)

Угу :)

> MS>> Кстати, ты уже заценил ui/vm/blonde.scm? :)
>> Это где?
MS> Чё, ещё не догадался, где у нас есть /vm? :)

wtf blonde.scm? Где /vm я знаю, у меня сейчас с ним идет драка не на
жизнь, а на смерть. Пока счет 2:0 в пользу /vm :)

> >>> Нам с тобой надо как-нибудь вместе подумать на тему
> >>> nginx/apache -- как бы сделать удобный вариант "из коробки"
> >>> фронтенда. Сейчас в конфигурации по умолчанию поставленные
> >>> nginx и apache попросту дерутся.
> MS>> Да-да-да-да-да, и чтоб виртхосты интегрированно создавались,
> MS>> и вопрос, на который сегодня в sysadmins@ отвечал, просто не
> MS>> поднимался.
> MS>> Отложу-ка в =packages/web-policy.
>> Давай так -- я тебе отдам те кошмарные скрипты, которые у меня
>> трудятся на хостинге, а ты их причешешь и выложишь? ;) Только
>> там очень много на daemontools завязано.
MS> Давай лучше летом пальцем по ним поводишь с комментариями.

Без проблем. Там самое сложное будет таки научить apache _удобно_
стартовать несколькими сразу, на разных ip:port из под разных юзверей.
А с nginx более-менее просто. У меня сейчас так:

 - nginx frontend (сидит в отдельном ve);
 - nginx backend (сидит в каждом ve с apache);
 - несколько апачей в каждом ve, которые собственно обслуживают запросы;

В общем-то можно было бы от фронтенда избавиться, но проблема в том, что
некоторые хосты имеют свой реальный IP, и поэтому к ним коннектятся
напрямую (то есть сразу на nginx backend). А nginx frontend позволяет мне
о таких мелочах жизни не думать.

Конфиги все текстовые, но перед обработкой скриптами конвертируются в
sqlite :) Сделано для того, чтобы в будущем перейти на схему с хранением
всех конфигов в постгресе каком, и обновлений по пинку.


-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<thresh> империя наносит ответные зависимости