|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 21 Aug 2005 23:19:08
To : Slawa Olhovchenkov
Subject : Re: небольшое объявление
--------------------------------------------------------------------------------
>>> Slawa Olhovchenkov wrote:
С приездом :)
VN>> И, далее, проблема в качестве тестирования: хорошо рожать фичи, но
VN>> почему-то тестирование всегда производится на живых пользователях.
VN>> Конечно, это open source, и все занимаются тем, что интересно, а не
VN>> тем, что нужно.
SO> Здрасте. А кто тестировать будет? У FreeBSD team что, есть отдел QA из сотни
SO> рыл на full-time с лабой на тысячу железок в разных конфигурациях? Ах нету?
SO> А
Да я не про железки - с ними вопрос отдельный. Хотя бы для
несвязанных с железом фич. Давно ли починили игнорирование SIGKILL
при libthr? Для воспроизведения такой ситуации нужен "отдел QA из
сотни рыл с лабой на тысячу железок"?
VN>> Они (вы) надеются полуторалетним циклом смягчить проблемы перехода?
VN>> Hе будет этого, отдельные переходы всё равно или требуют достаточно
VN>> сильных мер, или не требуют. И что, это устранило, например,
VN>> необходимость пересобирать практически всё при переходе на новую
VN>> версию, потому что компот из libc.so.4 и libc.so.5 неработоспособен?
VN>> Может, вместо этого надо было позаботиться о грамотной ABI
VN>> compatilibity и
SO> Это здорово, но для этого надо обладать головой мужиков из DEC 70-80х годов.
SO> И что бы можно было только это обсасывать с полгода (разработку API/ABI).
SO> Утопия? Утопия. Значит надо минимизировать последствия слома ABI, менять его
SO> так, чот бы в дальнейшем последстви минимизировались (с учетом опыта) и
SO> терпеть такую ситуацию.
Погоди. Зачем обсасывать разработку? Оно уже давно разработано и
есть. Меры по обеспечению совместимости различаются только степенью
громоздкости: просто сохранить совместимость в пределах той же
платформы проблем нет никогда. Более тогот, меры в большинстве
случаев сводятся просто к тому, чтобы не ломать без необходимости.
Помнишь на что психанул Диллон когда его исключили в последний раз?
Именно на бессмысленную, просто издевательски бессмысленную смену
ABI в ковырнадцато сороковой раз.
VN>> себя). И что, при переходе на 6ку мы опять будем радоваться и bump'у
VN>> номера libc.so (уже радуемся, там было что ломать), и перепахивать
VN>> всё тредовое? Hу почему у галимой винды этих проблем нет?
SO> А я бы розгами бил за то, что раньше bump не сделали. И повторно -- за то,
SO> что не всем либам bump сделали.
Объясни - накой этот bump тебе? Для того, чтобы заставить
пересобирать все?
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> деле.
Если кто-то такое и говорит, то он гонит. Какого лешего надо было
пересобирать с каждой новой второй цифрой всякие snmp?
VN>> Извини, наболело. Просто когда хватают очередную маркетинговую
VN>> технологию, в этот раз жёсткие сроки выхода, и надеются выдав её за
VN>> панацею решить этим совершенно не маркетинговые проблемы - результат
VN>> будет закономерен, заранее предсказуем и совсем не тот, что ожидался
VN>> авторами такой панацеи. Hе дадут разработчикам времени на доведение
VN>> какой-то фичи до ума - значит, она в релиз пойдёт сырая. Что ж,
VN>> успешных паников.
SO> Жесткие сроки -- идиотизм. И хер знает какие сроки -- идиотизм не меньший.
Hу хоть согласен с тем, что жёсткие сроки - идиотизм, уже лучше :))
"Хер знает какие" как в случае пятёрки - получились потому, что ввели
плохо рассчитанную фичу и долго не могли привести её к живому виду.
Кстати, я тебе, похоже, соврал, что пятёрка на UP не медленнее
четвёрки: горизонтальное переключение даже на одном процессоре между
обычными процессами и обработчиками прерываний - штука более
дорогая, чем обычное вертикальное переключение даже между user land
и kernel land.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
