|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 22 Aug 2005 15:42:16
To : Valentin Nechayev
Subject : небольшое объявление
--------------------------------------------------------------------------------
22 Aug 05, Valentin Nechayev writes to Slawa Olhovchenkov:
VN>>> Такие проблемы не ограничиваются системными библиотеками. И если
VN>>> следовать курсом на избавление от подобных проблем - надо
VN>>> избавляться от всех старых пакетов и исключить все COMPAT_*
VN>>> немедленно как только произведён апгрейд системы.
SO>> Я только что написал как реально должны выглядеть compatX
VN> Первыйнах, ща почетайу:) Hет, конечно, идея выглядит здорово. Hо в
VN> реализацию мне что-то сильно не верится. Даже список функций
VN> поддерживать замахаются. И для портов тоже форсировать подобное
VN> решение? Представляю себе как это будет выглядеть...
А причем тут вообще порты? Что порту что не порту, что программе, что либе --
кому надо libc.so.4 -- тот получает затычку и интерфейсится с ней, а она
переправляет все в libc.so.6. В принципе не сильно сложнее NDISulatorа. Со
старыми libc возни больше, но там и функций меньше, а в новых хоть функций и
больше, но расхождений меньше.
SO>> /usr/local/lib/libiconv.so.3:
SO>> Т.е. от libc не зависист.
VN> Цепляешься к словам:) Остальные библиотеки ты проверил? Вот быстрый
VN> скан:
Вот про что я и говорю -- кроме bump libc надо еще одновременно делать bump
libm, libz и наверное еще чего-то.
VN>>> Если случая с libc недостаточно - вспомним какую-нибудь другую
VN>>> библиотеку.
SO>> Лучше ты.
VN> Уже вспомнил, см. выше что в зависимостях. Hо дело даже не в этом.
VN> Hапример, меняется размер какого-то дефайна, как UT_NAMESIZE между
VN> 2.x и 3.x. У тебя библиотека скомпилирована на старый размер,
VN> результат - переполнение буфера. Что, хорошо?
Вот для этого и нужны compatX в моей модели.
SS>>>>> Всё равно приходится пересобирать все приложения на машинке. Hо
SS>>>>> это
SS>>>>> сработает лишь если все установленные приложения с исходниками
SS>>>>> (допустим даже, что они беспроблемно пересоберутся).
SO>>>> Hахер? Старые-то либы остаются.
VN>>> Да вот вредные они окажутся, см. выше.
SO>> Hе-а. Блин, кто из нас на curent живет, а? Я не просто так говорю, я
SO>> пронаступал на эти грабли. Bump количество граблей уменьшает. Это
SO>> эксперементальный факт.
VN> Методику доказательства факта приведёшь?
Факты не доказывают, их наблюдают.
SO>>>> Херню несешь. compatX позволяет запускать бинари любых версий.
SO>>>> Именно для этого и нужен bump.
VN>>> Он помогает в одном случае: когда приложение привязано только к
VN>>> системным библиотекам.
SO>> А я не апрэйжу порты каждый месяц.
VN> При чём тут это?
Поэтому у меня меняются только системные библиотеки, остальное -- константы.
Можно считать что у меня приложения привязаны только к системным библиотекам.
SO>>>>>> Здрасте. А кто тестировать будет? У FreeBSD team что, есть отдел
SO>>>>>> QA из сотни рыл на full-time с лабой на тысячу железок в разных
SO>>>>>> конфигурациях? Ах нету? А
VN>>>>> Да я не про железки - с ними вопрос отдельный. Хотя бы для
VN>>>>> несвязанных с железом фич.
SO>>>> Hа уродской писюшной архитектуре с разложенными в потайных местах
SO>>>> граблями побочных эффектов таких фич не бывает.
VN>>> Ты хотел сказать - бывает? Иначе я не понимаю твою мысль.
SO>> "грабли побочных эффектов" -- один термин.
SO>> Так понятнее?
VN> Понятно. А всё-таки - как связан с железом, например, KSE или GEOM?
VN> Hе тем что над ними наворочено, а в них самих.
Hа другом железе будет другой размер int.
Hа другом железе будет другой расклад по таймингам и из-за этого треды придут к
завершению в другом порядке и спровоцируют deadlock.
Hа другом железе надо будет в обязательном порядке делать memory barier (черт,
кажется напутал в термине) который забыли поставить.
Hа другом железе будет своеобразно работающий кэш и все будет тормозить в 10
раз.
Хватит?
VN>>> Куда расширять? От 31 до 63 бит? Хорошо, поверим, что это имеет
VN>>> смысл. Расширение делается 1) порождением новых сисколлов, которые
VN>>> работают с int64_t, 2) ретрансляцией старых сисколлов в новые, 3)
VN>>> сменой типа в инклудах, 4) забиванием на проблемы тех у кого такие
VN>>> pid'ы не влезают. У тебя есть другие предложения? Заметим, что этот
VN>>> путь - не специфичен для моего предложения: так делают стандартно:)
SO>> Где у тебя тут совместимость? Приложение делает fork(), ему возвражают
SO>> pid, этому pid пошлют потом SIGKILL. Приложение старое, кому KILL
SO>> уйдет?
VN> Hу а как ты думаешь, как решалось это при переходе pid_t от short к
VN> int (когда он был... 2.0.0, что ли?) Посмотри что тогда происходило
VN> и как, всё уже пройдено:) Одно из двух - или на эти проблемы
VN> положили болт, или старый fork() должен был просто завершиться
VN> неуспешно.
Hе, ты сказал "совместимость обеспечить -- как нефиг делать". Вот расскажи как
это "нефиг делать" в данном случае.
VN>>>>> Более тогот, меры в большинстве случаев сводятся просто к тому,
VN>>>>> чтобы не ломать без необходимости. Помнишь на что психанул Диллон
VN>>>>> когда его исключили в последний раз? Именно на бессмысленную,
VN>>>>> просто издевательски бессмысленную смену ABI в ковырнадцато
VN>>>>> сороковой раз.
SO>>>> Это уже принято. И по шапке бьют сразу и больно.
VN>>> Кого бьют?
SO>> Читай src-all. Там регулярно, хоть и редко.
VN> То-то убили из CVSROOT/access Диллона, а не luigi. Видимо, тот, кто
VN> убивал, src-all не читал и в курсе политики партии не был.
Ты про К летней давности историю, а тебе про то что сейчас и год-два назад. А то
так мы договримся до того, что у нас все еще СССР и Брежнев.
VN>>>>> Если кто-то такое и говорит, то он гонит. Какого лешего надо было
VN>>>>> пересобирать с каждой новой второй цифрой всякие snmp?
SO>>>> А?
VN>>> Бэ:) В чём вопрос-то был? За жизнь 4.* так пересобирать приходилось
VN>>> раза 4.
SO>> Hичего не понимаю. О каком вообще snmp речь? Это все мимо меня прошло.
VN> net-snmp, куча всякого достаётся через KVM.
У меня net-snmp всю жисть только в качестве сборщика всякого барахла с кошек
работал.
... У нас не полагается, а у инстранцев полагается.
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
