Идея новой подсистемы разделяемых библиотек. Критикуем.

>я мог выбрать нужное... и ушел пить чай, а после бы получил полностью раочую систему без Next-Agreed-Next-Next-Finish.

неа, ты должен купить лицензии на апгрейд каждой программы. или обновления должны прямо с пиратской бухты каачаться?

И шо делать с прогами, которые не юзают msiexec :(

И вообще если у тебя парк машин на венде, как их вообще можна обновлять всех одним скопом (не гуглил но подореваю гемморой до наступления девственности)?

>неа, ты должен купить лицензии на апгрейд каждой программы. или обновления должны прямо с пиратской бухты каачаться?

Щито? А если у меня в основном freeware и opensource?

>Да что у него вообще за софт такой, который постоянно перестает работать при обновлении библиотек?

ABI-то как раз все ломают периодически

>А если у меня в основном freeware и opensource?

мс-овцы в основном винду под свои продукты затачивали

> неа, ты должен купить лицензии на апгрейд каждой программы. или обновления должны прямо с пиратской бухты каачаться?

Да как бы под вендой дофига свободного и бесплатного софта (:

> И вообще если у тебя парк машин на венде, как их вообще можна обновлять всех одним скопом (не гуглил но подореваю гемморой до наступления девственности)?

Обновляться не нужно, нужно сидеть с дырками и работать со старым софтом, это круче.

>мс-овцы в основном винду под свои продукты затачивали

Ну и как под вендой обновить софт от мс?

Никак. Тред почитай.

Понятно... венда так и останется слакой...

>Ну и как под вендой обновить софт от мс?

купить диск с новым софтом и запустить setup.exe

>Обновляться не нужно, нужно сидеть с дырками и работать со старым софтом

исправления дырок обычно не связаны с поломкой ABI

хотя вру, в последних виндах апдейтер винды умеет докачивать патчи для установленных мсовских продуктов

Какой там процент десктопов под слакой, напомни, я забыл.

А, и какой процент сетей уровня предприятия работают под слакой, пожалуйста, если не затруднит.

>Какой там процент десктопов под слакой, напомни, я забыл.

Ты неправильно распарсил.

купить диск с новым софтом и запустить setup.exe

Я кончил и закурил...

>Там традиционно гадят в windows\system32

Если склероз мне не изменяет, то еще в хрюше же появилась фича хранить несколько вариантов либ и подсовывать программе ту, которую она поставила, нет?

>Напомню, что есть даже устойчивое словосочетание - «виртуальная машина Java». Оно появилось не на пустом месте.

Напомню тебе, что есть понятия JVM и .NET CLR, которые обозначают эти виртуальные машины. А если говорится «виртуальная машина» без всего, это уже вмварью попахивает. По крайней мере, «C# виртуальная машина» — это что-то непонятное, а вот сказал бы .NET CLR, все бы поняли.

купить диск с новым софтом и запустить setup.exe

Это откуда и к чему? Такая новая форма слива? Спасибо, это любопытно.

> как в венде АВТОМАТИЧЕСКИ обновить нужные мне программы средствами венды? Шоб оно автоматически вывело список всех доступных обновлений, я мог выбрать нужное... и ушел пить чай, а после бы получил полностью рабочую систему

Если вдруг в винде появится АВТОМАТИЧЕСКОЕ обновление программными средствами винды, это будет начало конца микрософта. Ибо после автоматического обновления получить полностью рабочую систему невозможно. Ибо вместе с обновлениями на любой системе - хоть винда, хоть линух, пользователь автоматически получает наслабый такой набор новых галлюнов.

> как в венде АВТОМАТИЧЕСКИ обновить нужные мне программы средствами венды? Шоб оно автоматически вывело список всех доступных обновлений, я мог выбрать нужное... и ушел пить чай, а после бы получил полностью рабочую систему

Если вдруг в винде появится АВТОМАТИЧЕСКОЕ обновление программными средствами винды, это будет начало конца микрософта. Ибо после автоматического обновления получить полностью рабочую систему невозможно. Ибо вместе с обновлениями на любой системе - хоть винда, хоть линух, пользователь автоматически получает наслабый такой набор новых галлюнов.

> Ибо вместе с обновлениями на любой системе - хоть винда, хоть линух, пользователь автоматически получает наслабый такой набор новых галлюнов.

Мда, в каком мире ты живешь?

> В винде не совсем там. Там традиционно гадят в windows\system32, в этом случае есть шанс получить обновление для всех программ. В макосе такой традиции вроде как нет.

И... иэ... на дворе XXI век, никто уже в System32 давно не гадит. А для тех, кто гадит, начиная с WinXP имеется WinSxS, который не дает им гадить.

>Ибо вместе с обновлениями на любой системе - хоть винда, хоть линух, пользователь автоматически получает наслабый такой набор новых галлюнов.

А можно вопрос?
Какой у тебя дистрибутив?

> Какой у тебя дистрибутив?

Debian 5.0.4 Stable

>Debian 5.0.4 Stable

А... Debian Stable. Тогда понятно, почему галлюны при обновлении. Ты, надо полагать, для обновления вынужден либо ставить все сам, либо переходить на testing или sid, потому и огребаешь.

Попробуй какой-нибудь дистрибутив вроде Ubuntu. Галюны будешь огребать не чаще раза в полгода при переходе с одной версии дистрибутива на другую. И то галюнов ограниченное количество. Или любой другой дистрибутив, который предоставлвяет и свежий софт, и не особенно много багов.

Хотя, конечно, это большая проблема, что в линуксе приходится если уж обновлять, то сразу всю систему (или пользоваться бэкпортами, или собирать самому), но и ситуация «я набрал aptitude safe-upgrade, и все равзвалилось» тоже возникает совсем не часто.

> Попробуй какой-нибудь дистрибутив вроде Ubuntu.

Немогу, Debian Stable - корпоративный стандарт в моей конторе. А мне дома приходится часто работать (плюс, у нас свое железо). Если вдруг что-то, отлаженное на Ubuntu будет глючить и выпендриваться в Lenny, я буду крайним. А такие случаи бывали и не раз - и поддержка сети имеет особенности, и USB стек перелопачивают из ядра в ядро, и X-сервер по-разному окна может обрабатывать, сюрпризов много. Поэтому отказались от разработки «кому в чем нравится», приняли стандарт, и теперь лишних вопросов не возникает.

Хотя, конечно, это большая проблема, что в линуксе приходится если уж обновлять, то сразу всю систему (или пользоваться бэкпортами, или собирать самому)

Вот. А какие методы (пусть даже самые фантастические) ты можешь предложить для решения этой проблемы?

> Ибо вместе с обновлениями на любой системе - хоть винда, хоть линух, пользователь автоматически получает наслабый такой набор новых галлюнов.

похоже ты бредишь

давай-ка конкретный пример галюна (например, последний, чтобы легче вспомнить) при апгрейде Debian 5 Stable (именно при upgrade, а не dist-upgrade)

> и чем же NSIS лучше InnoSetup?

тем, что он есть пакетом дебиана

можно полностью делать инсталляшку под винду (включая компиляцию и пакетирование) под линуксом

>можно полностью делать инсталляшку под винду (включая компиляцию и пакетирование) под линуксом

InnoSetup отлично работает в вайне, и пользоваться им проще (если не использовать CPack из CMake, который дает очень мало свободы)

А вообще есть нативный InstallJammer, которым можно и для никсов инсталляторы делать.

>А какие методы (пусть даже самые фантастические) ты можешь предложить для решения этой проблемы?

Боюсь, что на данный момент единственное, что лично я могу придумать - это инсталлятор, который будет собирать софт прямо на машине. Имеющий хорошую эвристику и умеющий обращатья к какой-нибудь БД, установленной на машине.

> давай-ка конкретный пример галюна (например, последний, чтобы легче вспомнить) при апгрейде Debian 5 Stable (именно при upgrade, а не dist-upgrade)

Ты не понял. Когда дело касается оборудования и выбирается стандарт на систему, то это означает, что конечный продукт будет работать на выбранной системе. Поэтому я и написал не просто «Debian 5 Stable», а «Debian 5.0.4 Stable». Это значит что для конечного продукта в качестве образа операционки будет использоваться Debian 5.0.4. Не 5.0.4 с апдейтами, а именно 5.0.4. Поэтому ни о каких upgrade речи не идет.

А по поводу обновений, это же классика жанра.

Когда сидел на Ubuntu, после обновления иксы не поднялись. Шаманил долго, оказалось какой-то процесс отвечащий за шрифты перестал запускаться при старте системы. Grub стал глючить и не давать системе запуститься, выдавая странные ошибки 16, 28, раз в две недели. Перестал работать инфракрасник через LIRC, пришлось пересобирать модуль, причем той же версии что и был в бинарном пакете. Заработал. Перестали инититься нестандартные USB-устройства. Как лечили - отдельная песня. Стал тормозить OpenGL. На анимациях видно, что на эране все происходит с 0.25-0.3 сек задержкой. Да и картинка стала не совсем «сглаженой», а более «рябой». Побороть задержку помогла пересборка драйверов nvidia, а картинка как была рябой, так и осталась. Видимо где-то в глубинах какие-то настройки по-дефолту сменились. X-сервер стал почему-то отправлять иногда два сигнала в момент сворачивания окна - о том, что окно свернуто и окно развернуто. В результате, иногда программы «запирались» - то есть, нельзя свернуть (сразу разворачивается) или развернуть (сразу сворачивается). Появилась блокировка размеров порта вывода OpenGL, то есть, нельзя было сделать окно размером больше чем разрешение монитора. Уже не помню как решили. Да, и звук тоже стал выпендриваться. Если раньше была возможность сделать незаметной латентность путем уменьшения размеров буфера, то после обновления при малом размере буфера стали слышны щелчки. Сетка стала по-другому себя вести, если раньше при выключении ADSL модема сразу исчезал if интерфейс, то после обновления он продолжал висеть только данные не передаются, незнаю что там намутили. Ну и куча прочих мелких пакостей, которые щас уже не вспомню. А! Конечно, wxWidgets. Новые обновления - новые глюки в интерфейсе. Например, появляется модальное окно с полем ввода, набираешь текст, а он печатается в предыдущем активном текстовом поле родительского окна. При копировании текста из лог-полей (в которых выключено редактирование), текст после выделения исчезает. Чтоб снова увидеть - надо вверх-вниз покрутить. Может быть, хомякам, которые только браузер и проигрыватель пользуют, этих глюков не видно. Но когда ты полноценно пользуешься системой, такие постоянные галлюны достают. Потому что вместо того чтоб работать и делать что-то новое, ковыряешь и выправляешь новые глюки.

> и чем же NSIS лучше InnoSetup?

Тем, что проект не такой кривой. Но вообще сравните сами.

> я еще понимаю, если бы сказали про InstallJammer, который не только для оффтопика

А зачем под тем же Linux'ом нужны какие то инсталяторы?

> > и чем же NSIS лучше InnoSetup?

тем, что он есть пакетом дебиана

можно полностью делать инсталляшку под винду (включая компиляцию и пакетирование) под линуксом

Круто, в Gentoo тоже есть. Я и не знал. Теперь от билд-машины под виндой можно полностью отказаться.

>А зачем под тем же Linux'ом нужны какие то инсталяторы?

для деплоймента

>Тем, что проект не такой кривой

Зато нет гуя для его создания

То, что в Убунте бывают мощные глюки — я верю, наслышан о них (сам убунту не юзаю).

А вот с практической точки зрения интересно, могут ли быть глюки при переходе например с дебиан 5.0.4 до 5.0.5 (через apt-get upgrade).

Мой опыть юзания дебиана (примерно с 2000 года) выявил только один глюк, причем он был связан именно с dist-upgrade. То есть раньше initrd не создавался, потом начал создаваться — и dist-upgrade прошел нормально, НО после, наверно через год, при обычном upgrade че-то случилось. Это проявилось только на одной машинке.

Так что если словишь глюки при переходе например с дебиан 5.0.4 до 5.0.5 (через apt-get upgrade) — напиши, интересно будет почитать.

Конечно, собирать в один бинарник код для 10 архетектур кажется ещё никто не «додумался» :)

man FATelf

Зачем оно мне? Хотя ладно, принято)

Избирательная статическая линковка - это только метод уменьшения места на диске. И обычный статический бинарник, и бинарник собранный избирательной статической линковкой одинаково должен _избирательно_ _загружаться_ в память. Вот о чем речь.

Может быть тогда проще иметь динамические библиотеки в которых функция foo представлена в нескольких экземплярах ? :) Т.е. foo@0.0.1, foo@0.0.2 и т.д. Или как это должно быть?

Например, программа A зависит от

foo@0.1
baz@0.2
bar@0.3

А программа B:

foo@0.2
baz@0.2
bar@0.2

Тогда если сделать две (умно собранных) статических библиотеки, то будет:

size(A*) = size(A) + size(foo@0.1) + size(baz@0.2) + size(bar@0.3) ~ P + 3*F
size(B*) = size(B)+ size(foo@0.2) + size(baz@0.2) + size(bar@0.2) ~ P + 3*F

all ~ 2*P + 6*F

Если иметь динамическую библиотеку с разделением версий, то:

size(DynLib) = size(foo@0.1) + size(baz@0.2) + size(bar@0.3)
             + size(foo@0.2) + size(bar@0.2) ~ 5 * F

size(A*) = size(A) ~ P
size(B*) = size(B) ~ P

all ~ 2*P + 5*F

Т.е. имеем, что symbol versioning во-первых эффективнее чем ваш способ по расходу места, во-вторых он по-умолчанию именно «_избирательно_ _загружает_ в память», тогда как для статического метода нужно чего-то там докручивать.

Что касается критики пакетного подхода с зависимостями - есть большое количество людей которые не просто терпят этот подход, он им предпочтителен - они его используют. При этом есть разработчики которые выбирают другой подход статической линковки. Ни тот ни другой подход не мешают друг другу, т.к. у них разные цели. Если уж требования к API и необходимость устранения коллизий столь высоки, то, опять, чем не подходит symbol versioning?

И кстати:

ничего нового не предложили ,

symbol versioning активно используется в библиотеках, в частности в GLIBC

Кроме того, нужно не «активное использование», а стандарт, без которого нельзя работать.

Linux Standard Base подойдёт? http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/symversion.html

> >Тем, что проект не такой кривой

Зато нет гуя для его создания

Это и есть один из плюсов NSIS.

> >А зачем под тем же Linux'ом нужны какие то инсталяторы?

для деплоймента

Прекратите нести ахинею.

я же не собираюсь доверять распространение своего продукта красноглазикам. Пользователь обновит дистрибутив, а мой продукт будет работать. Пользователь поменяет дистрибутив на другой, а мой продукт будет работать. Пользователю не нужно иметь права рута, так как инсталлятор может поставить его хоть в $HOME, хоть в /tmp

>Это и есть один из плюсов NSIS.\

я не собираюсь тратить время на изучение какого-то стремного язычка, больше не для чего не пригодного

> Может быть тогда проще иметь динамические библиотеки в которых функция foo представлена в нескольких экземплярах ? :) Т.е. foo@0.0.1, foo@0.0.2 и т.д. Или как это должно быть?

Как вы себе представляете поддержку такого кода? Ведь нужно будет держать исходники всех прошлых версий. Разработчики взвоют от такого.

Кроме того, сейчас держать в системе библиотеки, которые могут потребоваться программам уже сложно, даже с наличием репозитариев - забудет майнтейнер прописать зависимость, и привет. У него работает (потому что либа установлена), у вас - нет. А держать библиотеки всех возможных версий - это вообще из разряда фантастики.

Такой подход вообще не катит, вы это уже сами наверно поняли.

> Да, апдейты я выключаю сразу при установке системы, не важно что за дистр.

Microsoft gold certified, ога

Такой подход вообще не катит, вы это уже сами наверно поняли.

Ну symbol versioning, как уже говорили, активно используется и в LSB включён - то есть в некоторых случаях вполне катит.

Кроме того, сейчас держать в системе библиотеки, которые могут потребоваться программам уже сложно, даже с наличием репозитариев - забудет майнтейнер прописать зависимость, и привет. У него работает (потому что либа установлена), у вас - нет. А держать библиотеки всех возможных версий - это вообще из разряда фантастики.

Н-да, как раз сегодня после полугода спокойного существования столкнулся с подобной ситуацией, но виню, конечно, только кривоту рук :) Например в gentoo очень обширный и сложный репозиторий который учитывает не только зависимости и версии, но и разные тонкости вроде тех что бывают при бустрапе toolchain. Т.е. вроде пока ничего - всё работает более менее стабильно.

Хорошо, пусть будет избирательная статическая линковка. Пусть будет множество системных библиотек X с которыми мы линкуемся динамически, множество Y прочих базовых и опциональных библиотек с которыми мы не линкуемся (конечно, а то майнтейнер забудет прописать зависимости к ним :). И наша программа Z которая использует множество функций, которое суть пересечение X' (выборка из X), Y' (выборка из Y). Z загружается в память - функции из X' подгружаются динамически - это понятно. Функции из Y' это статически слинкованные функции, но вы говорите о какой-то «умной» их загрузке в память - можете подробно описать что это?

> Хорошо, пусть будет избирательная статическая линковка. Пусть будет множество системных библиотек X с которыми мы линкуемся динамически, множество Y прочих базовых и опциональных библиотек с которыми мы не линкуемся (конечно, а то майнтейнер забудет прописать зависимости к ним :). И наша программа Z которая использует множество функций, которое суть пересечение X' (выборка из X), Y' (выборка из Y). Z загружается в память - функции из X' подгружаются динамически - это понятно. Функции из Y' это статически слинкованные функции, но вы говорите о какой-то «умной» их загрузке в память - можете подробно описать что это?

В стартовой мессаге вроде всё однозначно описал...

>но и разные тонкости вроде тех что бывают при бустрапе toolchain

не путайте бутстрап тулчейна и отладку взаимосовметсимости разных версий пакетов X и Y. Первая задача имеет важное практическое значение, но является лишь частным случаем

> я же не собираюсь доверять распространение своего продукта красноглазикам.

Я, как пользователь, не собираюсь доверять вам. Фанатизм в любом его проявлении вреден для здоровья.

Пользователь обновит дистрибутив, а мой продукт будет работать. Пользователь поменяет дистрибутив на другой, а мой продукт будет работать. Пользователю не нужно иметь права рута, так как инсталлятор может поставить его хоть в $HOME, хоть в /tmp

О да, это заслуга инсталлятора, а не продукта.

> >Это и есть один из плюсов NSIS.

я не собираюсь тратить время на изучение какого-то стремного язычка, больше не для чего не пригодного

Я не настаиваю. Со временем жизнь все расставит на свои места.