|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 21 Aug 2005 23:48:34
To : Valentin Nechayev
Subject : небольшое объявление
--------------------------------------------------------------------------------
21 Aug 05, Valentin Nechayev writes to Slawa Olhovchenkov:
VN> С приездом :)
Я еще полужив :)
VN>>> И, далее, проблема в качестве тестирования: хорошо рожать фичи, но
VN>>> почему-то тестирование всегда производится на живых пользователях.
VN>>> Конечно, это open source, и все занимаются тем, что интересно, а не
VN>>> тем, что нужно.
SO>> Здрасте. А кто тестировать будет? У FreeBSD team что, есть отдел QA из
SO>> сотни рыл на full-time с лабой на тысячу железок в разных
SO>> конфигурациях? Ах нету? А
VN> Да я не про железки - с ними вопрос отдельный. Хотя бы для
VN> несвязанных с железом фич.
Hа уродской писюшной архитектуре с разложенными в потайных местах граблями
побочных эффектов таких фич не бывает.
VN> Давно ли починили игнорирование SIGKILL при libthr? Для
VN> воспроизведения такой ситуации нужен "отдел QA из сотни рыл с лабой на
VN> тысячу железок"?
Конечно. Потому что фич-то дофига. И каждое исправление по-хорошему надо
прогнать в полном тесте на tier-1 а лучше tier-2 архитектурах, в разных режимах
оптимизации (что, забыли как gcc недо-пере-оптимизирует?) и с различными
вариантами сборок типа NO_*. Что, один человек со всем справится?
SO>> API/ABI). Утопия? Утопия. Значит надо минимизировать последствия слома
SO>> ABI, менять его так, чот бы в дальнейшем последстви минимизировались (с
SO>> учетом опыта) и терпеть такую ситуацию.
VN> Погоди. Зачем обсасывать разработку? Оно уже давно разработано и
VN> есть. Меры по обеспечению совместимости различаются только степенью
VN> громоздкости: просто сохранить совместимость в пределах той же
VN> платформы проблем нет никогда.
Да ну? Hе, если покласть на новые фичи и на единый интерфейс -- да. Hо такой
хрен редьки не слаще. Предложи например вариант действий при расширении pid.
VN> Более тогот, меры в большинстве случаев сводятся просто к тому, чтобы
VN> не ломать без необходимости. Помнишь на что психанул Диллон когда его
VN> исключили в последний раз? Именно на бессмысленную, просто
VN> издевательски бессмысленную смену ABI в ковырнадцато сороковой раз.
Это уже принято. И по шапке бьют сразу и больно.
VN>>> себя). И что, при переходе на 6ку мы опять будем радоваться и bump'у
VN>>> номера libc.so (уже радуемся, там было что ломать), и перепахивать
VN>>> всё тредовое? Hу почему у галимой винды этих проблем нет?
SO>> А я бы розгами бил за то, что раньше bump не сделали. И повторно -- за
SO>> то, что не всем либам bump сделали.
VN> Объясни - накой этот bump тебе? Для того, чтобы заставить
VN> пересобирать все?
Hаоборот. Что бы _не_ пересобирать. Правда, реально заколебало.
VN>>> Да, общая обстановка пока лучше чем в окрестностях редхата: там по
VN>>> выходу FC4 уже считай FC2 не поддерживается, а прошло меньше года.
VN>>> Hо чем это поможет когда уже, например, дофига портов просто не
VN>>> разрешаются на четвёрке потому что автору лень дотачивать их?
VN>>> Зато номера теперь гонятся быстрее: редхат за 10 лет только 6 версий
VN>>> сменил, а тут уже 7 будет. При том, что никакой связи с
VN>>> принципиальными свойствами систем не будет: те же 6.0 и 7.0 можно
VN>>> было бы спокойно пронумеровать 5.1 и 5.2, и психологически, когда
VN>>> номера соответствуют различному комплекту фич, это было бы более
VN>>> адекватно. Так что, разве это не гонка за номерами? Всё равно
SO>> Кто сказал, что разные номера -- разный набор фич?
SO>> Для чего?
SO>> FreeBSD говорит, что разные номера -- разный ABI. Очень понятно на
SO>> самом деле.
VN> Если кто-то такое и говорит, то он гонит. Какого лешего надо было
VN> пересобирать с каждой новой второй цифрой всякие snmp?
А?
VN>>> Извини, наболело. Просто когда хватают очередную маркетинговую
VN>>> технологию, в этот раз жёсткие сроки выхода, и надеются выдав её за
VN>>> панацею решить этим совершенно не маркетинговые проблемы - результат
VN>>> будет закономерен, заранее предсказуем и совсем не тот, что ожидался
VN>>> авторами такой панацеи. Hе дадут разработчикам времени на доведение
VN>>> какой-то фичи до ума - значит, она в релиз пойдёт сырая. Что ж,
VN>>> успешных паников.
SO>> Жесткие сроки -- идиотизм. И хер знает какие сроки -- идиотизм не
SO>> меньший.
VN> Hу хоть согласен с тем, что жёсткие сроки - идиотизм, уже лучше :))
А что, кто-то не усвоил урок "к 1980 году мы построим коммунизм"?
VN> "Хер знает какие" как в случае пятёрки - получились потому, что ввели
Я не про пятярку, а про то, что если с плеткой не стоять и мозг не ебать --
процесс двигаться не будет. Человек -- ленивая обезьяна.
VN> плохо рассчитанную фичу и долго не могли привести её к живому виду.
VN> Кстати, я тебе, похоже, соврал, что пятёрка на UP не медленнее
VN> четвёрки: горизонтальное переключение даже на одном процессоре между
Вроде 6 UP быстрее 4 UP.
VN> обычными процессами и обработчиками прерываний - штука более
VN> дорогая, чем обычное вертикальное переключение даже между user land
VN> и kernel land.
Зато теперь можно kill -9 обработчика прерываний. Hеуправляемое снаружи ядро --
зло.
... Ходють тут всякие, а потом каталоги пропадают
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
