>> Да да, Юра работал :-)
> BTW привет ему, если есть контакт.недалее как неделю назад пили кофе вместе, уточню - хотел бы он слышать привет от Вас или нет.
>> Когда вы с подковыркой каждый раз пытетесь спросить - то чем плохо отсутсвие
>> стабильного API, то "сталкивался ли я с ролью RE" - это нормально.
> На самом деле как раз без подковырок, а ожидая ответа по существу.
> Вы попробуйте сами почитать свои сообщения и подумать о том,
> что воспринимать их вполне возможно и как безграмотные, и как грамотные
> -- при этом сделать обоснованное предположение вовсе не всегда получается.
> Соответственно можно бодаться, можно выуживать, а можно просто спросить в лоб
> в надежде на прямой же ответ.
ваш коментарий содержал фразу "с подковыркой" - теперь звучит "на деле как раз без подговырок" - кому верить? вам тогдашнему или вам сегодняшнему? какой из них лгал?
Тем более аргументы достаточно избитые.
>> А когда вам показывают чем это плохо, аргументировано
> Между прочим, с Вашими аргументами по части stable API всё так же
> не могу согласиться. Т.е. они верны для Вас как разработчика,
> но я как манагер понимаю, почему Линус придерживается именно такой точки
> зрения на гарантии неизменности и их пределы. И вообще-то это
> странно, со временем разработчики нередко начинают шурупить в организации процессов из
> более чем одного-двух-пяти человек (хоть и не всегда).
Странно что у вас как менедежера такое видение, очень странно. Не опускаясь до флейма (боюсь все равно не поймете) - могу только порекомендовать перечитать (если не читали) PSP/TSP book (personal software process, team software process) - там очень доходчиво поясняется с цифрами и математикой почему в проектах ориентированных на качество нельзя делать то что делает Тeo.
>> или подтверждают что понимают о чем речь - начинается уход в кусты и рассказы о понтах.
> Э, стоп. Читаем #58 и о чём тут ещё рассказывать надо?
> Или чтоб не указывать на ответ другому человеку -- мой
> вопрос к Вам был по мотивам #19, которое иначе как запущенной
> звёздной болячкой объяснить не получается.
> В частности, в стремлении выпереться на пьедестал умудрились не заметить то, что
> "плохой" Тед докопал-таки до того битого комментария, а вот Вы полезли
> его обливать, не докопавшись и побежав вперёд со скоропалительными выводами.
> Такое действительно чинится только подходом "и теперь ничего не трогай".
Эти выводы только вам кажутся скоропалительными. На самом деле это просто результат наблюдения за тем что твориться с разработкой ядра. Когда-то такое должно было случиться - вот и случилось.
А теперь еще раз перечитайте классику из книг по управлению проектами.
Кроме того - я собственно указал всего немного вещей
1) все фиксы в very minor должны очень сильно тестировать и анализироваться на предмет регрессионых изменений = что не сделано
2) very minor релизы - не допускают добавления новых фунций, так как это нейзбежно добавляет ошибки = что не мешает маинтейнерам "стабильных" релизов поступать так, ровно как и ситуациях когда в RC4 меняют API, что бы в релизе еще раз его поменять /пример не приведу - но сталкивался при портировании люстры на новые ядра/
3) Отсутствие стабильного API в ядре вынуждает комитить изменения в основное ядро как можно раньше без надлежащего тестирования, что бы дальнейшее сопровождение (и изменение в соответствии с новым API) было головной болью других.
Вы можете опровергнуть любой из этих тезисов? Считаете любой из этих фактов идет на пользу стабильности и качеству (возьмем классическую метрику bugs / LOC) кода?
>> Разве нельзя было сразу поверить что человек знает о чем говорит?
> Нет.
Для этого надо просто априори считать что он знает о чем сказал. У вас же наоборот - "Шигорин вот все знает, шигорин кучу курсов провел, а тут какой-то аноним может указывать на то с чем я не соглаен".
Пересмотрите позицию, советую.
>> Вам надо было подтверждение - вы его получили, в чем проблемы то?
> С подтверждением проблемы есть, с доводами -- тоже, с замашками -- тем
> более.
Ровно на ваш взгляд. Но стоит посмотреть чуть чуть выше.....
>> Теперь оказывается это понты? Так кто виноват - тот который захотел
>> подтверждения, или тот кто это подтверждение предоставил?
> Предлагаю обойтись без поиска виноватых, но при этом продолжать называть вещи своими
> именами.
Правильно - вы его уже назначили. Зачем смотреть в округу ?
>> Да, у меня свое мнение о том как стоило бы развивать ядро.
> Прекрасно. Осталось его реализовать, если это осмысленно. Убедите руководство?
проект не сильно меньше - пока вполне удается, и что странно проект развивается и приносит прибыль.
>> Ибо еще раз замечу - флейм в адрес любой ОС кроме Linux не режется
> Врёте.
Не вру - достаточно посмотреть новости про BSD, MacOS, Windows - там куча тупых GNU мальчиков развлекается, но до этого никому нет дела.
Так почему бы не поразвлекутся в новостях о GNU/Linux? Чем тут лучше? тем более вполне аргументировано.
Чего не скажешь о GNU мальчиках с криками BSDL плохая лицензия, BSD Rip, BSD предатели opensource и тп.. С 0 количеством аргументов в коментарий.
Почему вы считаете GNU/Linux такой священной коровой?
> Ваш
> стиль на удивление трудно отличить от одного из типовых стилей microsoft
> student partners по крайней мере на мой изрядно замылившийся глаз.
Потому что мой стиль ровно так же тыкает пальцем в недостатки GNU и Linux в частности - что приравнивается к флейму. Я так понимаю слово "гротеск" вам ничего не говорит?
Поэтому если у вас глаз "замылилися" имейте мужество - или размыльте его или уйдите.
А что касается ms students - вы просто ведете себя с ними высокомерно - считая что можете им указывать с высоты ваших знаний, поэтому любой кто бросает вам "вызов" приравнивается к таким студентам.
> Если хотите, попробуйте перечитывать сообщения перед отправкой сюда, как если бы писали
> в LKML: в чём суть, а что наносное.
С LKML - тоже не все так просто. чего стоит только гонор Alan Cox который не любит когда ему указывают на баги в патчах, или Rick Van Riel (или как там его - автор rmap в linux vm) - который сначала порывался участвовать в linux-vserver, а после того как увидел нестыковки в своих предложениях - сразу как-то расхотел. Можно еще вспомнить гонор Торвальдса - который фактически выгнал автора -ck патчей, и тп..
И который не любит включать патчи со стороны.
PS. ровно так же - прежде чем нажимать "удалить" - советую подумать. И лучше стирать сообщения GNU ботов которые скатываются в фрейм, а не оригинал.
PPS. рамки этой болячки возможно гораздо шире - есть репорты что в RHEL6 клонах наблюдался похожий эффект. Если подтвердят - будем на следующей неделе разбираться.
