Дайджест одной из первых дискуссий по поводу концепии ALT Linux, совместимости с the rest of the world и т.п.
По крайней мере часть ссылок на архив отъехала (при каком-то из его переездов или починок?), добровольцы покопать текущее состояние и сделать ссылки/вытащить суть в подстранички — приветствуются.
Побуду-ка я ALT Traffic-архиватором. Заранее извиняюсь, если где
промахнусь по треду — вылавливаю ссылки из не совсем маленького
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/thread.html
История: все началось с вопроса vic ismakaev <viclists@mail.esoo.ru>
по прикладыванию патча к ядру из Sisyphus:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014036.html
Очень быстро вопрос перешел к конкретике сборки пакетов:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014224.html
AEN> Я не мешаю Вам делать со своей системой все, что Вам
AEN> заблагорассудится.
AEN> Но у авторов дистрибутива есть свое мнение, основанное на
AEN> знаниях.
AEN> Это мнение мы здесь высказываем и предупреждаем:
AEN> — В случае использования базовых пакетов от других
AEN> дистрибутивов (как бы они ни были хорошо собраны) возможны
AEN> проблемы, за которые мы не несем никакой ответственности.
AEN> — Мы поддерживаем решения ACL RSBAC (кстати, обоснование
AEN> этого приведено на сайте Castle) и не подерживаем другие
AEN> решения.
AEN>
AEN> Это _наше_ мнение, с которым Вы можете соглашаться или не
AEN> соглашаться, Вам его никто не навязывает.
AEN> Мы делаем дистрибутив, сообразуясь со своими знаниями и
AEN> опытом, с благодарностью принимаем мотивированные советы. Но
AEN> мы никогда не будем собирать пакеты вопреки своему мнению.
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014381.html
AEN> Выход прост:
AEN> 1. Выбрать один из подходов, один из дистрибутивов, который
AEN> Вам симпатичен.
AEN> 2. Не смотреть во все стороны, если Вы до конца не поняли
AEN> концептуальных отличий дистрибутивов.
AEN> 3. Если же Вы поймете эти концептуальные отличия, то проблем
AEN> будет гораздо меньше, и вы будете задавать разработчикам
AEN> вопросы об _их_ дистрибутиве, а не рассказывать о том, что в
AEN> Англии ружья песком не чистят.
AEN> howto по нашему rpm было в списке рассылки. Там все, что
AEN> нужно для того, чтобы исправить spec от RH для работы с
AEN> нашим rpm.
Довольно быстро вопрос перешел в плоскость «взглядов на жизнь» в
контексте формирования дистрибутивов:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014384.html
[YR == Yuri Ryazantsev <yuri@unix.ru>]
YR> AEN> Еще раз:
YR> AEN> 1. Стандарты мы не нарушаем.
YR> AEN> 2. У нас свои взгляды на жизнь и Linux.
YR> Вот как раз с этого места и поподробнее. Хотелось бы узнать (а
YR> еще лучше
YR> прочитать в виде некоторого документа) ВАШИ взгляды на Linux и
YR> концептуальные отличия Mandrake RE. Только не отправляйте к
YR> .src.rpm, я понимаю там я это могу узнать, но времени...
YR> :-))
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014423.html
[ SSS == “Sergey S. Skulachenko” <sss@roscredit.com> ]
YR> SSS> YR> А вот и нет. Я постоянно читаю Вас (даже лично встречались) и
YR> SSS> YR> до сих пор не понимаю фактического состояния концепции
YR> SSS> YR> дистрибутива:
YR> SSS> YR>
YR> SSS> YR> 1. Потенциальный пользователь и его окружение (какого уровня
YR> SSS> YR> и какие задачи решает пользователь и какого он уровня).
YR> SSS> YR> 2. Техническая поддержка выпущенного дистрибутива
YR> SSS> YR> 3. Направления развития данного дистрибутива.
YR> SSS>
YR> SSS> На самом деле «дистрибутивов». И вот тут возникает очень важное
YR> SSS> замечание: о некоторых вещах надо уметь умалчивать. Их
YR> SSS> появление должно усиливаться неожиданностью. Сложное это дело -
YR> SSS> уметь молчать. И этому нужно с самого начала учить в
YR> SSS> особенности младший персонал. Русский человек привык рвать на
YR> SSS> себе рубашку. А надо жёстко придерживаться разделения труда и,
YR> SSS> не бойтесь этих слов, должностных инструкций. Кодируешь -
YR> SSS> кодируй. Брошен на связи с общественностью – вперёд, но в
YR> SSS> отведённых тебе жёстких рамках. Иначе выиграют те, у кого в
YR> SSS> голове всего одна идея. На чужом, то есть,
YR>
YR> А вот и не соглашусь с Вами. Я не прошу Вас рассказать о Ваших
YR> know-how или будущих идеях. Меня интересует мое будущее, чтобы я
YR> через N месяцев не сказал самому себе: «Пусть будет проклят тот
YR> день когда я связался с этим дистрибутивом». Вы прекрасно
YR> понимаете, что не существует универсального и замечательного
YR> дистрибутива для любого вида задач (иначе бы только он один и
YR> развивался :-). Поэтому когда стоит вопрос о выборе того или
YR> иного дистрибутива, соизмеряешь усилия по его освоению и доводке
YR> его под свои задачи. А также еще и смотришь на то, куда смотрит
YR> команда разработчиков. Если это все направлено в одну сторону,
YR> то получается что в выигрыше все. А если наши усилия как лебедь,
YR> рак и щука, то лучше менять дистрибутив.
YR>
YR> ВОТ ЭТИ ТО ВОПРОСЫ ВЫ НЕ ДОЛЖНЫ УМАЛЧИВАТЬ. Иначе собираете под
YR> свои знамена людей, а потом скажете: «Мы пошли по домам, а вы
YR> куда хотите» :-))
(далее прекрасное суммирование субтреда проведено
“Alexander V. Sotnikov” <al-so@mail.ru> — стоит прочесть полностью
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014496.html
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014547.html)
Возвратясь чуть назад — прозвучал следующий ответ:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014381.html
AEN> YR> 1. Потенциальный пользователь и его окружение (какого
AEN> YR> уровня и какие задачи
AEN> YR> решает пользователь и какого он уровня).
AEN> Писал, кажется, и об этом...
AEN> Мы будем выпускать дистрибутивы для разных категориф
AEN> пользователей, а также универсальный дистрибутив.
AEN> Наши пользователи — free people.
AEN> То есть во-первых — people. то есть мы обращаемся к
AEN> человеку, а не к организации как к сущности и не к функции.
AEN> Замечу, что это не значит, что мы не работаем с
AEN> организациями.
AEN> Во-вторых — free people. Здесь можно говорить много, скажу
AEN> только, что свобода подразумевает самостоятельность в
AEN> мышлении и в деятельности, способность воспринимать новое.
AEN> Конечно, есть люди, которые не вполне свободны, но могут
AEN> стать таковыми. Мы будем работать и для них.
AEN> Мы сознательно ограничиваем круг своих пользователей этими
AEN> весьма жесткими условиями. Но надо понимать, что нашу
AEN> команду объединяют, в первую очередь, общие взгляды на
AEN> жизнь, а не только род занятий.
AEN>
AEN> Что касается решаемых задач, то мы не ставим здесь
AEN> принципиальных ограничений, но в нашей команде пока
AEN> представлены не все направления.
AEN>
AEN> YR> 2. Техническая поддержка выпущенного дистрибутива
AEN>
AEN> Ну, об этом я писал точно.
AEN> Мы, в связи с ростом числа заказов, создаем подразделение
AEN> поддержки. Новость про обучение будет до конца мая.
AEN>
AEN> YR> 3. Направления развития данного дистрибутива.
AEN>
AEN> Основа нашей технологии — Sisyphus.
AEN> На его базе созданы и/или создаются:
AEN> — универсальный дистрибутив
AEN> — OEM – дистрибутивы (Intel, MSI)
AEN> — серверный дистрибутив Castle
AEN> — другие специализированные дистрибутивы.
AEN>
AEN> Думаю, что в июне имеет смысл выпустить что-то вроде
AEN> Appendix. Тем более, что проблемы обновления с появлениенм
AEN> apt-get должны быть сняты.
AEN>
AEN> Могу назвать также такие направления:
AEN> — защита (здесь у нас есть ряд уникальных решений);
AEN> — web (Midgard, LRN, Zope, отчасти с этим связаны и серверы
AEN> баз данных);
AEN> — офисные приложения (Gecko-броузеры, мейлеры, Open Office,
AEN> в ближней перспективе Koffice — такового выбора и степени
AEN> готовности к работе, Вы, пожалуй, не найдете нигде) ;
AEN> — интеранционализация (мы будем работать над интеграцией
AEN> Unicode и интенационализацией проблемных приложений, как
AEN> обычно);
И через сообщение:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014389.html
AEN> YR> Мое почтение, Алексей!!!! Именно этого я и ждал уже почти
AEN> YR> месяц. Еще бы
AEN> YR> немного поподробнее отдельные пункты и получится классный
AEN> YR> <a href="Phylosophy.html">Phylosophy</a>. А почему бы
AEN> YR> именно это и не положить
AEN> YR> на сервер. И вести бы сей документ, так же как и FAQ,
AEN> YR> учитывая обсуждения и
AEN> YR> пожелания.
AEN>
AEN> Вот Rider сделает новый сайт — допишу...
Кстати, сайт уже довольно-таки доделан с тех времен... Пора :)
Обсуждение задело и тему отбора пакетов для дистрибутива:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014548.html
[ MO == Maksim Otstavnov <maksim@otstavnov.com> ]
MO> AEN> Есть традиции, которые мы принимаем и не собираемся нарушать. Я
MO> AEN> всегда любил «толстые» дистрибутивы, а разговоры «дайте мне все на
MO> AEN> одном CD — несерьезны для специалиста. Для начинающего — да,
MO> AEN> возможно. Для сисадмина — понятно. Для разработчика — бред. Для
MO> AEN> активно использующего компьютер профессионала — тоже.
MO>
MO> Речь немножко не об этом. Здорово было бы иметь 1CD supported и
MO> хоть 10 – всего остального. А лучше – 20, при нынешней цене на
MO> диски :)))
Рядом Nidd отметил подход Debian, сославшись на DFSG
http://www.debian.org/social_contract :
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014574.html
Чуть позже при обсуждении загрузки участников проекта LDV ответил на
вопрос «что требуется от майнтейнера?»:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014811.html
[ SS == Serge Skorokhodov <suralis@pisem.net> ]
LDV> SS> А каковы обязанности мейнтейнера?
LDV>
LDV> Maintainer пакета XXX должен:
LDV> + Регулярно пользоваться этим пакетом.
LDV> Rationale: maintainer должен чувствовать пакет «изнутри», без
LDV> этого нарушается цикл тестирования и пакет становится
LDV> неполноценным.
LDV> + Быть в курсе разработки софта, входящего в пакет. Это, как
LDV> минимум, подразумевает участие в списке рассылки типа
LDV> XXX-announce.
LDV> Общение с разработчиками софта, входящего в пакет, желательно,
LDV> но не обязательно.
LDV> Участие в разработке софта, входящего в пакет, желательно, но
LDV> не обязательно.
LDV> Rationale: это дает возможность иметь в дистрибутиве самую
LDV> свежую (но при этом рабочую) версию софта, а также повышает
LDV> оперативность исправления ошибок.
LDV> + Отслеживать bug report'ы (как в bts, так и в списках рассылки;
LDV> последнее на порядок сложнее) и реагировать на них.
LDV> Оперативность реакции на security holes – не более одного
LDV> рабочего дня (реакция – это не обязательно исправление).
LDV> Rationale: это просто очевидно.
LDV>
LDV> Пишу на вскидку, окончательная версия будет вместе со списком
LDV> пакетов.
Тут возник вопрос о том, как же все-таки описывать эту самую
неуловимую концепцию дистрибутива. Когда в качестве примера было
предложено посмотреть на PLD Concept, Дмитрий добавил ссылку на
аналогичный документ проекта Owl:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014806.html
[ SB == “S. Budnevitch” <budnevitch@mail.mtu.ru> ]
LDV> SB> http://www.pld.org.pl/about/concept/
LDV> SB>
LDV> SB> Это устроит?
LDV>
LDV> Посмотрите на http://www.openwall.com/Owl/CONCEPTS.shtml
LDV> Интересует мнение о подходе к изложению концепции дистрибутива.
Как ни странно, эта ветвь не продолжилась (тогда).
Несколько дальше был поднят еще один предельно важный вопрос (к
счастью, на данный момент более чем удовлетворительно решенный):
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014430.html
AEN> В то время мы были совместимы с MDK и Вы могли
AEN> воспользоваться рекомендацией MDK.
AEN> Мы не будем поддерживать ни RH, ни ASP. Описание сборки rpm
AEN> от RH имеется. Что касается дыр в защите, то, естественно,
AEN> что декларирую свою несовместимость с другими дистрибутивами
AEN> мы берем на себя обязательства по их оперативному латанию.
В общем, все всё понимают — и это замечательно:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014572.html
AEN> Сергей, я выступлю в защиту своих оппонентов (я бы сказал --
AEN> доброжелателей, если бы слово это не имело известного второго
AEN> смысла). На самом деле, их, верные по сути пожелания,
AEN> продиктованы искренним желанием успешного развития проекта ALT.
AEN> Ни для кого здесь не секрет, что выжить программистской фирме
AEN> вообще, тем более — фирме free software, сложно. Конечно, нашим
AEN> давним пользователям интереснее новые пакеты, но для очень и
AEN> очень многих нужна хорошая документация, нужно представление о
AEN> концепции без поиска в списке рассылки. Сочетать это очень
AEN> сложно. А в безделье, я надеюсь, нас никто не подозревает.
PS: кстати, мысли насчет автоматизации «отмашки» по синхронизации
тоже не новы:
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014653.html
[ AVS == “Alexander V. Sotnikov” <al-so@mail.ru> ]
AEN> AVS> Насчет ночного каравана предложение-вопрос. Я не знаю почему
AEN> AVS> апдейты ночные. Мой ночной диалап халявен, но для качания сизифа
AEN> AVS> трудно воспользоваться халявностью, т.к. легко нарваться на
AEN> AVS> момент апдейта, что будет чревато глюками. Хотелось бы чтобы
AEN> AVS> график апдейтов был зафиксирован. Например фиксируется время
AEN> AVS> суток Ч, заводится пара линков current, updating на разные
AEN> AVS> директории. Далее в течение суток все апдейты идут в updating,
AEN> AVS> качать без риска можно спокойно current, а во время Ч линки
AEN> AVS> перекидываются. Реально?
AEN>
AEN> Дело в том, что наш радиоканал обладает более-менее стабильной
AEN> пропускной способностью только ночью, так что здесь пока ничего
AEN> существенно изменить нельзя.
AEN> Другое дело, что письмо об окончании синхронизации посылать в
AEN> список рассылки Sisyphus можно, — надо будет так сделать.
PPS: еще одно прекрасное обобщение произвел Serge Skorokhodov
(рекомендуется прочесть полностью):
http://www.altlinux.ru/pipermail/mandrake-russian/2001-May/014929.html
Ссылок на эту страницу нет