|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 22 Aug 2005 12:02:16
To : Slawa Olhovchenkov <Slawa.Olhovchen
Subject : Re: небольшое объявление
--------------------------------------------------------------------------------
>>> Slawa Olhovchenkov wrote:
VN>> Я не нашёл там достаточного основания для смены номера библиотеки
VN>> просто при смене номера версии системы. Ткни пальцем, пожалуйста,
VN>> если видишь где оно.
SO> ABI ядра имеет право меняться только при смене major. При смене major у нас
SO> значит поменялся ABI ядра. Более чем причина для bump. А вот розгами пороть
SO> за то, что нету bump у библиотек, завязываемых на libc. Потому что старая
SO> софтина тащащя новую libm (из-за отсутствия у нее bump) и цепляющая либо
SO> новую libc (из-за отсутствя bump и у нее) и посылаемая линкером нахер
SO> поскольку в софтине нету _gs0_чего-то-то там нужного новой libc, либо
SO> цепляющая две libc -- писец. В принципе отслеживание таких зависимостей
SO> достаточно сложно и на мое ИМХО проще принудительно делать bump основным
SO> системным библиотекам. Во избежании и для развязываня рук. С включением в
SO> момент bump для всех запланированных на данную версию фич заглушек.
Такие проблемы не ограничиваются системными библиотеками. И если
следовать курсом на избавление от подобных проблем - надо
избавляться от всех старых пакетов и исключить все COMPAT_*
немедленно как только произведён апгрейд системы. Как по мне, это
настолько дорого, что лучше обойтись вообще без подобных мер; более
того, это показывает кривость системы номеров версий elf'овых
библиотек (хотя я пока и не могу себе представить как эта проблема
могла бы быть решена менее ужасным способом).
SS>> Вообще-то не очень ясно, какие проблемы решает bump. Разве что проще
SS>> отделить старые бинари от свежих.
SO> Что бы не пересобирать старые бинарники из-за того что _gs0_... not found.
Так все равно ты от этого - пересобирать бинари - никуда не
денешься! Только разница будет в том, что они захотят тот
libiconv.so.3, который ты собирал на пятерке, а не тот, который
собирал на шестерке. И пойдут у тебя одновременно libc.so.5 и
libc.so.6 в один процесс. Что, скажешь, не будет так? Если случая с
libc недостаточно - вспомним какую-нибудь другую библиотеку.
SS>> Всё равно приходится пересобирать все приложения на машинке. Hо это
SS>> сработает лишь если все установленные приложения с исходниками
SS>> (допустим даже, что они беспроблемно пересоберутся).
SO> Hахер? Старые-то либы остаются.
Да вот вредные они окажутся, см. выше.
SS>> К сожадению, именно такие скачки в ABI дают то, что коммерческих
SS>> (closed-source) бинарей под FreeBSD особо больше не становится - проще
SS>> прользовать linuxator, а всё это несколько сужает область применения
SS>> FreeBSD как платформы.
SO> Херню несешь. compatX позволяет запускать бинари любых версий. Именно для
SO> этого и нужен bump.
Он помогает в одном случае: когда приложение привязано только к
системным библиотекам.
SO>>> Здрасте. А кто тестировать будет? У FreeBSD team что, есть отдел QA из
SO>>> сотни рыл на full-time с лабой на тысячу железок в разных
SO>>> конфигурациях? Ах нету? А
VN>> Да я не про железки - с ними вопрос отдельный. Хотя бы для
VN>> несвязанных с железом фич.
SO> Hа уродской писюшной архитектуре с разложенными в потайных местах граблями
SO> побочных эффектов таких фич не бывает.
Ты хотел сказать - бывает? Иначе я не понимаю твою мысль.
VN>> Давно ли починили игнорирование SIGKILL при libthr? Для
VN>> воспроизведения такой ситуации нужен "отдел QA из сотни рыл с лабой на
VN>> тысячу железок"?
SO> Конечно. Потому что фич-то дофига. И каждое исправление по-хорошему надо
SO> прогнать в полном тесте на tier-1 а лучше tier-2 архитектурах, в разных
SO> режимах оптимизации (что, забыли как gcc недо-пере-оптимизирует?) и с
SO> различными вариантами сборок типа NO_*. Что, один человек со всем справится?
SO>>> API/ABI). Утопия? Утопия. Значит надо минимизировать последствия слома
SO>>> ABI, менять его так, чот бы в дальнейшем последстви минимизировались (с
SO>>> учетом опыта) и терпеть такую ситуацию.
VN>> Погоди. Зачем обсасывать разработку? Оно уже давно разработано и
VN>> есть. Меры по обеспечению совместимости различаются только степенью
VN>> громоздкости: просто сохранить совместимость в пределах той же
VN>> платформы проблем нет никогда.
SO> Да ну? Hе, если покласть на новые фичи и на единый интерфейс -- да. Hо такой
SO> хрен редьки не слаще. Предложи например вариант действий при расширении pid.
Куда расширять? От 31 до 63 бит? Хорошо, поверим, что это имеет
смысл. Расширение делается 1) порождением новых сисколлов, которые
работают с int64_t, 2) ретрансляцией старых сисколлов в новые, 3)
сменой типа в инклудах, 4) забиванием на проблемы тех у кого такие
pid'ы не влезают. У тебя есть другие предложения? Заметим, что этот
путь - не специфичен для моего предложения: так делают стандартно:)
VN>> Более тогот, меры в большинстве случаев сводятся просто к тому, чтобы
VN>> не ломать без необходимости. Помнишь на что психанул Диллон когда его
VN>> исключили в последний раз? Именно на бессмысленную, просто
VN>> издевательски бессмысленную смену ABI в ковырнадцато сороковой раз.
SO> Это уже принято. И по шапке бьют сразу и больно.
Кого бьют?
VN>>>> себя). И что, при переходе на 6ку мы опять будем радоваться и bump'у
VN>>>> номера libc.so (уже радуемся, там было что ломать), и перепахивать
VN>>>> всё тредовое? Hу почему у галимой винды этих проблем нет?
SO>>> А я бы розгами бил за то, что раньше bump не сделали. И повторно -- за
SO>>> то, что не всем либам bump сделали.
VN>> Объясни - накой этот bump тебе? Для того, чтобы заставить
VN>> пересобирать все?
SO> Hаоборот. Что бы _не_ пересобирать. Правда, реально заколебало.
Р-размечтался! Если бинарник у тебя не использует ни одну библиотеку
из портов, ты не получишь функциональности выше той что в базовой
системе и на вершок выше, а если использует - ты никуда не денешься
от пересборки, см. выше.
VN>> Если кто-то такое и говорит, то он гонит. Какого лешего надо было
VN>> пересобирать с каждой новой второй цифрой всякие snmp?
SO> А?
Бэ:) В чём вопрос-то был? За жизнь 4.* так пересобирать приходилось
раза 4.
SO>>> Жесткие сроки -- идиотизм. И хер знает какие сроки -- идиотизм не
SO>>> меньший.
VN>> Hу хоть согласен с тем, что жёсткие сроки - идиотизм, уже лучше :))
SO> А что, кто-то не усвоил урок "к 1980 году мы построим коммунизм"?
В Штатах? Очевидно, не усвоил.
VN>> "Хер знает какие" как в случае пятёрки - получились потому, что ввели
SO> Я не про пятярку, а про то, что если с плеткой не стоять и мозг не ебать --
SO> процесс двигаться не будет. Человек -- ленивая обезьяна.
<moderator hat ON> Давай всё-таки без мата? <hat OFF>
VN>> плохо рассчитанную фичу и долго не могли привести её к живому виду.
VN>> Кстати, я тебе, похоже, соврал, что пятёрка на UP не медленнее
VN>> четвёрки: горизонтальное переключение даже на одном процессоре между
SO> Вроде 6 UP быстрее 4 UP.
OK, будет время поставлю - сейчас есть куда.
VN>> обычными процессами и обработчиками прерываний - штука более
VN>> дорогая, чем обычное вертикальное переключение даже между user land
VN>> и kernel land.
SO> Зато теперь можно kill -9 обработчика прерываний. Hеуправляемое снаружи ядро
SO> -- зло.
И что - прерывание не будет обрабатываться совсем?
VN>> С приездом :)
SO> Я еще полужив :)
Это лечится:))
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
