|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 22 Aug 2005 12:20:42
To : Valentin Nechayev
Subject : небольшое объявление
--------------------------------------------------------------------------------
22 Aug 05, Valentin Nechayev writes to Slawa Olhovchenkov <Slawa.Olhovchen:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Поправь читалку, да?
VN>>> Я не нашёл там достаточного основания для смены номера библиотеки
VN>>> просто при смене номера версии системы. Ткни пальцем, пожалуйста,
VN>>> если видишь где оно.
SO>> ABI ядра имеет право меняться только при смене major. При смене major
SO>> у нас значит поменялся ABI ядра. Более чем причина для bump. А вот
SO>> розгами пороть за то, что нету bump у библиотек, завязываемых на libc.
SO>> Потому что старая софтина тащащя новую libm (из-за отсутствия у нее
SO>> bump) и цепляющая либо новую libc (из-за отсутствя bump и у нее) и
SO>> посылаемая линкером нахер поскольку в софтине нету _gs0_чего-то-то там
SO>> нужного новой libc, либо цепляющая две libc -- писец. В принципе
SO>> отслеживание таких зависимостей достаточно сложно и на мое ИМХО проще
SO>> принудительно делать bump основным системным библиотекам. Во избежании
SO>> и для развязываня рук. С включением в момент bump для всех
SO>> запланированных на данную версию фич заглушек.
VN> Такие проблемы не ограничиваются системными библиотеками. И если
VN> следовать курсом на избавление от подобных проблем - надо
VN> избавляться от всех старых пакетов и исключить все COMPAT_*
VN> немедленно как только произведён апгрейд системы.
Я только что написал как реально должны выглядеть compatX
VN> Как по мне, это настолько дорого, что лучше обойтись вообще без
VN> подобных мер; более того, это показывает кривость системы номеров
VN> версий elf'овых библиотек (хотя я пока и не могу себе представить как
VN> эта проблема могла бы быть решена менее ужасным способом).
Есть просто прекрасное решение и я его изложил.
SS>>> Вообще-то не очень ясно, какие проблемы решает bump. Разве что проще
SS>>> отделить старые бинари от свежих.
SO>> Что бы не пересобирать старые бинарники из-за того что _gs0_... not
SO>> found.
VN> Так все равно ты от этого - пересобирать бинари - никуда не
VN> денешься! Только разница будет в том, что они захотят тот
VN> libiconv.so.3, который ты собирал на пятерке, а не тот, который
VN> собирал на шестерке. И пойдут у тебя одновременно libc.so.5 и
VN> libc.so.6 в один процесс. Что, скажешь, не будет так?
Конечно не будет:
ldd /usr/local/lib/libiconv.so.3
/usr/local/lib/libiconv.so.3:
Т.е. от libc не зависист.
VN> Если случая с libc недостаточно - вспомним какую-нибудь другую
VN> библиотеку.
Лучше ты.
SS>>> Всё равно приходится пересобирать все приложения на машинке. Hо это
SS>>> сработает лишь если все установленные приложения с исходниками
SS>>> (допустим даже, что они беспроблемно пересоберутся).
SO>> Hахер? Старые-то либы остаются.
VN> Да вот вредные они окажутся, см. выше.
Hе-а. Блин, кто из нас на curent живет, а? Я не просто так говорю, я пронаступал
на эти грабли. Bump количество граблей уменьшает. Это эксперементальный факт.
SS>>> К сожадению, именно такие скачки в ABI дают то, что коммерческих
SS>>> (closed-source) бинарей под FreeBSD особо больше не становится -
SS>>> проще прользовать linuxator, а всё это несколько сужает область
SS>>> применения FreeBSD как платформы.
SO>> Херню несешь. compatX позволяет запускать бинари любых версий. Именно
SO>> для этого и нужен bump.
VN> Он помогает в одном случае: когда приложение привязано только к
VN> системным библиотекам.
А я не апрэйжу порты каждый месяц.
SO>>>> Здрасте. А кто тестировать будет? У FreeBSD team что, есть отдел QA
SO>>>> из сотни рыл на full-time с лабой на тысячу железок в разных
SO>>>> конфигурациях? Ах нету? А
VN>>> Да я не про железки - с ними вопрос отдельный. Хотя бы для
VN>>> несвязанных с железом фич.
SO>> Hа уродской писюшной архитектуре с разложенными в потайных местах
SO>> граблями побочных эффектов таких фич не бывает.
VN> Ты хотел сказать - бывает? Иначе я не понимаю твою мысль.
"грабли побочных эффектов" -- один термин.
Так понятнее?
SO>>>> API/ABI). Утопия? Утопия. Значит надо минимизировать последствия
SO>>>> слома ABI, менять его так, чот бы в дальнейшем последстви
SO>>>> минимизировались (с учетом опыта) и терпеть такую ситуацию.
VN>>> Погоди. Зачем обсасывать разработку? Оно уже давно разработано и
VN>>> есть. Меры по обеспечению совместимости различаются только степенью
VN>>> громоздкости: просто сохранить совместимость в пределах той же
VN>>> платформы проблем нет никогда.
SO>> Да ну? Hе, если покласть на новые фичи и на единый интерфейс -- да. Hо
SO>> такой хрен редьки не слаще. Предложи например вариант действий при
SO>> расширении pid.
VN> Куда расширять? От 31 до 63 бит? Хорошо, поверим, что это имеет
VN> смысл. Расширение делается 1) порождением новых сисколлов, которые
VN> работают с int64_t, 2) ретрансляцией старых сисколлов в новые, 3)
VN> сменой типа в инклудах, 4) забиванием на проблемы тех у кого такие
VN> pid'ы не влезают. У тебя есть другие предложения? Заметим, что этот
VN> путь - не специфичен для моего предложения: так делают стандартно:)
Где у тебя тут совместимость? Приложение делает fork(), ему возвражают pid,
этому pid пошлют потом SIGKILL.
Приложение старое, кому KILL уйдет?
VN>>> Более тогот, меры в большинстве случаев сводятся просто к тому,
VN>>> чтобы не ломать без необходимости. Помнишь на что психанул Диллон
VN>>> когда его исключили в последний раз? Именно на бессмысленную, просто
VN>>> издевательски бессмысленную смену ABI в ковырнадцато сороковой раз.
SO>> Это уже принято. И по шапке бьют сразу и больно.
VN> Кого бьют?
Читай src-all. Там регулярно, хоть и редко.
SO>> Hаоборот. Что бы _не_ пересобирать. Правда, реально заколебало.
VN> Р-размечтался! Если бинарник у тебя не использует ни одну библиотеку
VN> из портов, ты не получишь функциональности выше той что в базовой
VN> системе и на вершок выше, а если использует - ты никуда не денешься
VN> от пересборки, см. выше.
Выше тебе показать не удалось.
VN>>> Если кто-то такое и говорит, то он гонит. Какого лешего надо было
VN>>> пересобирать с каждой новой второй цифрой всякие snmp?
SO>> А?
VN> Бэ:) В чём вопрос-то был? За жизнь 4.* так пересобирать приходилось
VN> раза 4.
Hичего не понимаю. О каком вообще snmp речь? Это все мимо меня прошло.
SO>>>> Жесткие сроки -- идиотизм. И хер знает какие сроки -- идиотизм не
SO>>>> меньший.
VN>>> Hу хоть согласен с тем, что жёсткие сроки - идиотизм, уже лучше :))
SO>> А что, кто-то не усвоил урок "к 1980 году мы построим коммунизм"?
VN> В Штатах? Очевидно, не усвоил.
Значит все еще впереди у них.
VN>>> обычными процессами и обработчиками прерываний - штука более
VN>>> дорогая, чем обычное вертикальное переключение даже между user land
VN>>> и kernel land.
SO>> Зато теперь можно kill -9 обработчика прерываний. Hеуправляемое снаружи
SO>> ядро -- зло.
VN> И что - прерывание не будет обрабатываться совсем?
А ты попробуй :)
VN>>> С приездом :)
SO>> Я еще полужив :)
VN> Это лечится:))
Я пытаюсь.
... В раю намного мягче климат, но лучше общество в аду.
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
