Разработчики Debian поставили под сомнение (https://lwn.net/Articles/658809/) целесообразность обеспечения поддержки в дистрибутиве стандарта Linux Standard Base (https://www.opennet.me/opennews/art.shtml?num=42360) (LSB), который определяет сервиcы, средства разработки, бинарные интерфейсы и библиотеки, дающие возможность выполнения в дистрибутиве LSB-совместимых сторонних приложений. По мнению некоторых разработчиков, на обеспечение совместимости с LSB тратится слишком много сил, при неочевидной пользе от такой совместимости.Поддерживаемый в Debian стандарт LSB 4.1 описывает 1493 компонентов, 1672 библиотек, 38491 команд, 30176 классов и 716202 интерфейсов. При том, что в настоящее время на предмет совместимости с LSB сертифицировано (https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb) всего 8 (восемь) приложений, из которых только одна программа сертифицирована на соответствие LSB 4.0+. Иначе говоря, вся огромная работа и те рамки в которые приходится укладываться ради совместимости с LSB делаются ради нескольких проприетарных программ, разработчики которых не желают сформировать специфичные для дистрибутива пакеты.
Главной же проблемой является то, что никто из разработчиков не хочет брать на себя работу по сопровождению пакетов с компонентами для поддержки LSB. В связи с этим решено (http://permalink.gmane.org/gmane.linux.debian.devel.lsb/1103) сохранить только пакеты lsb-base и lsb-release с небольшим набором shell-функций для скриптов инициализации и утилитой для вывода уровня совместимости с LSB, отбросив всё остальное.
URL: https://lwn.net/Articles/658809/
Новость: http://www.opennet.me/opennews/art.shtml?num=43119
Ну и правильно
После того, как перестанут работать всякие проприетарные сетевухи или Wi-Fi карточки с видеокарточками, юзверята завопят и начнётся массовый отток, хошь-не-хошь, а вернуться к поддержке придётся.
А с другой стороны всё верно. Ленивые проприетарные задницы пытаются переложить работу на кого-то другого. Вот если бы все массово перестали поддерживать их продукцию - был бы положительный эффект.
Причем тут сетевухи, Wi-Fi карточки и видеокарточки?
Действительно мимо. А прикладной софт - отвалится, да. Начиная с флеша и заканчивая средами разработки.
flash уже года три как не нужен чуть более чем полностью.
Ололошеньки-лоло, расскажи мне больше про ненужность Флеша.
5 лет не видел флеша.
На seasonvar, видимо, не ходите, потому и не нужен. Или стоит у вас старенький плагинчик в системе, еще 5 лет назад установленный, вот и не знаете даже, что видите...
html5 плеер там таки есть. Не очень удобный, но есть.
> html5 плеер там таки есть. Не очень удобный, но есть.ну вот, а я не нашел и крыл матом apple за их отказ от flash и не мог смотреть через iPad. А он давно появился?
В Apple никогда не отказывались от flash, его там никогда не было. Для того, чтобы играть во флеш-копро-игруленьки можно использовать один из *дцати броузеров для iOS с поддержкой оного. Смотрите в App Store по тэгу "flash".
> В Apple никогда не отказывались от flash, его там никогда не было.
> Для того, чтобы играть во флеш-копро-игруленьки можно использовать один из *дцати
> броузеров для iOS с поддержкой оного. Смотрите в App Store по
> тэгу "flash".Причем здесь игры? Я про видео говорил. Что странно, для видео эти говноброузеры тоже не подходят. Если не верите - попробуйте. Кровь-кишки. Имхо если делать систему для массового пользователя, то оставлять за бортом флеш глупо. Они ему смерть пророчили еще в первом (первом, Карл!) айфоне, а уже 12й вышел, флеш живее иных живых, а убер-хтмл5 болеет идиотскими детскими болезнями. Пообщайтесь с разработчиками этих самых "копроигр" и вам популярно объяснят на какой %уй надо пойти этому html5. На такой он еще не ходил...
Причем здесь игры? Для игр есть аппстор. Пообщайтесь с разработчиками этих самых сайтов и вам популярно объяснят, что если делать сайт для массового пользователя, то оставлять на борту флеш глупо. Ну а копроразработчики могут ходить на своих %уях дальше - их мнение никого не волнует.
детскими болезнями болеют только жопорукие индусы, в html5 никаких проблем нет, в нём всё прекрасно работает на всех устройствах
> Пообщайтесь с разработчиками этих самых "копроигр"зачем общаться с безмозглыми кретинами?
Год назад уже был.
Согласен, тебе для посмотра порносайтов он еще нужен :)
на редтубе отличный хтмл плеер
Сказано же, оно нужно только восьми гoвноприожениям. Ничего не изменится.
8 приложений лицензировано ≠ 8 приложений всего. "Говноприложений", ты сейчас похож на диктора советского ТВ с его интонационной поддержкой. Ты же даже не знаешь что это за программы.
Почему советского? Сейчас такие же дикторы.
А в САСШ что, другие? Везде они одинаковые. ПРосто этому чувачку в советские времена не давали осуществить его низменные мечты, видать, вот он и обиделся на всю свою никчёмную жизнь ;)
Если это настоящий Зентар, то в советские времена его ещё не было в природе.
это не мешает отдельным личностям страдать от тоталитаризма и даже от оккупации.
> это не мешает отдельным личностям страдать от тоталитаризма и даже от оккупации.для таких людей придумали психиатрические лечебницы
сейчас бы всем дикторам не помешало быть такими же как в Советах
И среди них Wolphram Mathematica или Matlab ,например . Ну кому нужен госводистрибутив без матлаба ?? В в свитч пакетокидалкой разве что ...
> И среди них Wolphram Mathematica или Matlab ,например .А точно? RPM, например, для дистрибуции первый не использует.
Да он и не нужен... Я помню новость про LSB 5.0 - каждый второй коммент про "LSB не нужен, потому что RPM". Но никто же не заставляет им пользоваться. Вот например Nero Linux 4 предлагает на выбор RPM и DEB, и Lightworks 12.5 тоже.
зачем нужен матлаб если есть luaJIT?
И всю-всю функциональность всех-всех пакетов уже переписали opensource гномики ??
Ну продемонстриуйте что-нибудь не архисложное.Например, есть видео как капля чернил расползается по мокрой промакашке,- требуется вычислить коэфф диффузии .
> зачем нужен матлаб если есть kcalc?Починил.
> И среди них Wolphram Mathematica или Matlab ,например . Ну кому нужен
> госводистрибутив без матлаба ?? В в свитч пакетокидалкой разве что ...У меня матлаб на дебиане работает без LSB-либ :)
>> И среди них Wolphram Mathematica или Matlab ,например . Ну кому нужен
>> госводистрибутив без матлаба ?? В в свитч пакетокидалкой разве что ...
> У меня матлаб на дебиане работает без LSB-либ :)Это как? Вы без libc работаете?
> Сказано же, оно нужно только восьми гoвноприожениям. Ничего не изменится.Не путай сертификацию с "нужностью".
Коммерческих программ под Linux - много. Действительно, довольно похоже на то
что вещи вроде Mathematica или Matlab - используют элементы LSB.
Проприетарщики ориентируются в первую очередь на клиента, а не на стандарты. С другой стороны, LSB не очень вписывается и в практики FOSS-разработки. Вот и получается чисто бумажный стандарт.
> Проприетарщики ориентируются в первую очередь на клиента, а не на стандарты. С
> другой стороны, LSB не очень вписывается и в практики FOSS-разработки. Вот
> и получается чисто бумажный стандарт.Хрен ты угадал. Знаешь, почему? Почитай, как IBM PC получил всеобщее распространение. Потом когда проникнешься - приходи, потрындим за стандарты. Сечешь?
>> Проприетарщики ориентируются в первую очередь на клиента, а не на стандарты. С
>> другой стороны, LSB не очень вписывается и в практики FOSS-разработки. Вот
>> и получается чисто бумажный стандарт.
> Хрен ты угадал. Знаешь, почему? Почитай, как IBM PC получил всеобщее распространение.
> Потом когда проникнешься - приходи, потрындим за стандарты. Сечешь?наверное вот поэтому http://abcdefgh.livejournal.com/924831.html
> Проприетарщики ориентируются в первую очередь на клиента, а не на стандарты."Как бы его повернуть, что е..ть, а он не рыпался" в принципе можно считать ориентацией на клиента... но с оооочень большооооой натяяяя....
Заметались бедненькие. То systemd во все поля, то LSB не нужен. Наверное UsrMove собираются делать, иначе редхватовская поделка работать отказывается.
с systemd это они правильно. Да и с сабжем тоже.
С аргументацией у тебя проблемы. Давай, разъясни, чем несоблюдение стандартов правильно?
Тем, что именно на этот стандарт всем положить, а поддерживать надо. Если есть хоть кто-то заинтересован, он может взяться за это...
>Тем, что именно на этот стандарт всем положить, а поддерживать надо. Если есть хоть кто-то заинтересован, он может взяться за это...Тогда вопрос. Как вообще возник стандарт, на который всем положить? Кто его разработал? Может, какие инопланетяне?
> Тем, что именно на этот стандарт всем положить,Программ, использующих стандарт LSB, довольно много (почитайте обсуждение выше). Просто далеко не все производители заморачиваются с сертификацией.
> С аргументацией у тебя проблемы. Давай, разъясни, чем несоблюдение стандартов правильно?Ну вот гента использует нестандартную систему инициализации. Это неправильно?
> иначе редхватовская поделка работать отказывается.Это вы про LSB?
Странно что они вообще возились с этим мертвым стандартом.
У дебы насиловать труп - в порядке вещей
Да где ж он мёртвый-то? То, что игроделы взяли за стандарт Ubuntu 12.04, а не Enterprise Linux 5 (для LSB 5.0 - 7) не значит, что это сделали все. Хотя бы потому что софт для работы в Steam не берут. (Если кто не знает, Steam таскает с собой 300 МБ либ из Ubuntu 12.04, иначе проблемы наблюдаются даже в 12.10 - не говоря уже про 15.04). А обратная совместимость во всех стандартных либах поддерживается железно - от Glibc до Glib.
>Если кто не знает, Steam таскает с собой 300 МБ либ из Ubuntu 12.04, иначе проблемы наблюдаются даже в 12.10 - не говоря уже про 15.04Это временное явление, когда контракт Valve с Canonical истечёт эти устаревшие либы выкинут из Steam.
>> Если кто не знает, Steam таскает с собой 300 МБ либ из Ubuntu 12.04, иначе проблемы наблюдаются даже в 12.10 - не говоря уже про 15.04
> Это временное явление, когда контракт Valve с Canonical истечёт эти устаревшие либы выкинут из Steam.Нет никакого контракта. Сначала Valve начала писать Steam как для нормальной системы! Бета-релиз доустанавливал все зависимости для игр через apt-get, запрашивая пароль администратора. А потом выяснилось, что в Ubuntu 12.10 это не работает. Как так?! "Эй, Canonical! Ты что, не обеспечиваешь обратную совместимость с предыдущими релизами Ubuntu?" "Нет, не обеспечиваю" "%$#!" Сроки, видимо, поджимали, вот и решили проблему bundled-либами. А после релиза Steam, вообще обказались от сотрудничества с Canonical, создав SteamOS на базе Debian. Я уверен, что изначально планировалось на Ubuntu и делать консоль.
Так вот, LSB - это и есть стопроцентная обратная совместимость между Enterprise 5, 6 и 7. LSB гарантирует, что весь твой софт, которым ты пользовался в EL5, в EL6 прекрасно заработает, а от EL6 - в EL7. Red Hat тратит на поддерживание обратной совместимости нехило средств - иначе она потеряет гораздо больше!
Печально, что Debian отказывается от его поддержки - тем самым перекрывая себе дорогу в энтерпрайс. Если LSB не будет совсем - не будет обратной совместимости между Debian 8 и 9, и Ubuntu 15.10 и 16.04. Потому что (в частности) Glib 2.50 не сможет гарантированно запускать софт, скомпиленный с Glib 2.40. Не Шаттлворт же будет следить за обратной совместимостью в базовых системных либах!
> Печально, что Debian отказывается от его поддержки - тем самым перекрывая себе
> дорогу в энтерпрайс.Бред написали, потому что:
- Debian для бинарного Oracle/SAP/Etc. никто и сейчас не поставит - нет в списке сертифицированных систем с платной поддержкой 24/7.
- Debian с опенсорс и/или Java приложениями, типа DataStax - нет смысла в строгом следовании LSB ABI. Все что надо - работало, работает, и будет работать. Так же как и в FreeBSD, который тоже не следует LSB, но в продакшн широко используется и многим админам нравится.
>> Печально, что Debian отказывается от его поддержки - тем самым перекрывая себе
>> дорогу в энтерпрайс.
> Бред написали, потому что:
> - Debian для бинарного Oracle/SAP/Etc. никто и сейчас не поставит - нет
> в списке сертифицированных систем с платной поддержкой 24/7.
> - Debian с опенсорс и/или Java приложениями, типа DataStax - нет смысла
> в строгом следовании LSB ABI. Все что надо - работало, работает,
> и будет работать. Так же как и в FreeBSD, который тоже
> не следует LSB, но в продакшн широко используется и многим админам
> нравится.А причём тут вообще FreeBSD и _Linux_ Standard Base???
> А причём тут вообще FreeBSD и _Linux_ Standard Base???А как, по-вашему, "линуксулятор" во фре работает?
У них там LSB-библиотеки, вытащенные из какой-то федоры, ЕМНИП.
>разработчики которых не желают сформировать специфичные для дистрибутива пакетыВ том и беда, что для каждого крупного дистра нужены
>специфичные для дистрибутива пакеты
И если нужного пакета а репах нет, то всё: либо сам делай, либо обломись. Потому линух на ПК и не преодолеет даже 5%, несмотря на кучу других плюсов.
> И если нужного пакета а репах нет, то всёИ какого нужного тебе пакета нет в репах дебиана, болезный?
qucs
Убунтовский ставится на jessie без бубна, все зависимые либы в jessie есть
https://packages.gentoo.org/packages/sci-electronics/qucs
Даже ебилдов ждать не нужно!
Начни с простого, посчитай количество пакетов с модулями из CPAN, потом сравни с общим количеством модулей на CPAN. Счет недостающих пакетов будет идти на тысячи, здоровячок.
Легли под монолитный зондокомбайн SystemD
Передали имущественные права на код
Теперь отказались от стандарта LSBнеладно что-то в Датском королевстве
В Красной хате не лучше. Я считаю что у них - синдром Висты. После успеха 95-й у Гейтса была эйфория. После неудачи 2000 - депрессия. Исследователи назвали причину провала безошибочно: раньше каждый новый год компов продавалось больше, чем за все годы до этого. Поэтому новая версия винды сразу начинала доминировать (даже если она глючная). А тут - действительно хорошая система, но юзеры просто отказываются её покупать! "Спасибо, но нас устраивает предыдущая версия". А новых юзеров не появляется - рынок насытился.Что они решили? Выпустив XP и кое-как переведя мир на Win2k, они поняли что ещё раз они так сделать не смогут - надорвутся. И тогда они решили ломать совместимость. Расчёт был на то, что весь новый софт чисто теоретически не сможет запуститься на XP, так как не будет использовать Win32 API. Поэтому пользователям XP хочешь-не хочешь, а придётся обновиться. Результат - феерический провал Vista, а XP поддерживалась до 2014 года!
Что же теперь? Отказ от Win32 не случился - напротив, в "восьмёрке" прекрасно работает любой софт от 95-ки, даже в 64-битной! А ставка теперь сделана не на "всем придётся купить новую систему, потому что старая не запускает новые программы", а на новые фичи. Собственно, ради фич новую систему и должны были покупать! А "нет изменений, но вы всё равно купите, пожалуйста".
Red Hat тоже понял что каждый новый релиз покупается всё хуже и хуже, вот и ломает теперь всё, с нетерпением ожидая, чтобы у семёрки было >25%. Тогда энтерпрайзный софт начнёт требовать семёрку, и все массово кинутся обновляться с 4/5/6. Но их ждёт то же, что ждало Microsoft с Вистой.
>> Расчёт был на то, что весь новый софт чисто теоретически не сможет запуститься на XP, так как не будет использовать Win32 API.
>> Отказ от Win32 не случился - напротив, в "восьмёрке" прекрасно работает любой софт от 95-ки, даже в 64-битной!Что-то вы не то говорите. "Этот софт" прекрасно работает и в Висте. В Висте сломали лишь совместимость с драйверами XP. И драйверы от XP точно так же не будут работать и в 7/8/10. Никакого отказа от Win32 не было. Некоторый софт сейчас уже действительно в XP не работает, поскольку, начиная с какой-то из версий Visual Studio, поддержку XP выкинули.
В общем, вы как-то в одну кучу намешали совершенно разные вещи и сделали неверные выводы.
>>> Расчёт был на то, что весь новый софт чисто теоретически не сможет запуститься на XP, так как не будет использовать Win32 API.
>>> Отказ от Win32 не случился - напротив, в "восьмёрке" прекрасно работает любой софт от 95-ки, даже в 64-битной!
> Что-то вы не то говорите. "Этот софт" прекрасно работает и в Висте.Суть в другом. Майкрософт думал что Vista сразу отхапает 25%, и тогда весь популярный софт будет компилиться под неё, а в этом случае совместимость с XP просрана. А значит, остальные 75% не заставят себя долго ждать. Заметь, сейчас совместимость с семёркой никто не ломает - Майкрософт один раз обжёгся на этом, и больше так делать не будет.
> В общем, вы как-то в одну кучу намешали совершенно разные вещи и сделали неверные выводы.
Это было всего лишь моё мнение. Я не брал интервью у Гейтса!
win2k была весьма удачной. Ты путаешь ее и миллениум и похоже совсем не в курсе, про то что до winxp было две параллельных линейки винды. Путаешь переход с winapi на .net c переходом с winxp на vista. Рассказываешь сказки про win8. В общем за знание истории винды незачет.
> win2k была весьма удачной. Ты путаешь ее и миллениум и похоже совсем
> не в курсе, про то что до winxp было две параллельных
> линейки винды. Путаешь переход с winapi на .net c переходом с
> winxp на vista. Рассказываешь сказки про win8. В общем за знание
> истории винды незачет.Ты тоже ошибаешься. WinAPI никуда не делся..
А под переходом на win2k, видимо, имелся в виду переход на семейство виндовсов с архитектурой NT.
Ну вот где ты увидел у меня, что winapi куда-то делся? Скажу страшное, даже winxp никуда не делся, его продолжают использовать. Речь шла о тенденциях и векторе развития разработки от мелкомягких.
winapi очень сильно меняется в каждой версии винды. Причём маразм - api не только расширяется, но и сужается. Некоторые функции, которые были в 2000-winxp, в win7 убрали.
В итоге, писание достаточно низкоуровневой программы (работаем с микрофоном, перехватываем клавиши и тд) под винду - это попаболь. А написать универсальную программу для 2000-win10 это вообще ненаучная фантастика.
Это у виндузятников проблема "а как бы нам впарить кому-то свежие продукты нашей жизнедеятельности", а красношляпе, в принципе по барабану, на чём конкретно сидит клиент, так как продают они по факту поддержку и им всё равно капают деньги, заплатил ли клиент за поддержку 7 или заплатил за поддержку 5.> Тогда энтерпрайзный софт начнёт требовать семёрку, и все массово кинутся обновляться с 4/5/6.
Вообще-то не будет шляпа такого делать, нехилую часть её клиентов составляют именно те, кто хочет один раз поставить систему на сервер и 10 лет его эксплуатировать с минимумом простоя, но при этом ещё иметь актуальные секьюрити-фиксы. Да и уверенность, что имеющееся ПО заработает без малейших проблем даже на современнейшем железе (даже на новейшие серверы, например поколение g8 от HP, пятый редхат становится без малейших проблем).
> Легли под монолитный зондокомбайн SystemD
> Теперь отказались от стандарта LSB
> неладно что-то в Датском королевствеГлавное забыли - переход с libav на ffmpeg.
> Передали имущественные права на код
Это в убунте было.
> Это в убунте было.ты похоже проспал недавние новости
>посчитай количество пакетов с модулями из CPAN, потом сравни с общим количеством модулей на CPAN. Счет недостающих пакетов будет идти на тысячиТак Perl умирающий язык, всё-равно рано или поздно придётся весь этот хламовник от Perl вычищать из Debian. И в Debian берут только то что используется другими пакетами как зависимость, никто не будет добавлять тысячи пакетов "чтобы было".
Но никак умереть не может. Как-нибудь под рождество умрёт?
Ну замени умирающий perl на php, ruby, python, nodejs, go или что там у вас сейчас в моде. Суть то не изменится. А если ты такого простого не можешь понять, то объяснять тебе про зависимости смысла нет. У тебя ведь мозг взорвется от такого:
$ apt-cache rdepends libmojolicious-perl
libmojolicious-perl
Reverse Depends:
...
libmojo-server-fastcgi-perl$ apt-cache rdepends libmojo-server-fastcgi-perl
libmojo-server-fastcgi-perl
Reverse Depends:
libmojolicious-perl
>Ну замени умирающий perl на php, ruby, python, nodejs, goПеречислены языки которые являются примерно таким же хламом как и perl, соответственно и отправятся эти языки в своё время туда же куда и perl.
>>Ну замени умирающий perl на php, ruby, python, nodejs, go
> Перечислены языки которые являются примерно таким же хламом как и perl, соответственно
> и отправятся эти языки в своё время туда же куда и
> perl.Ещё один адепт "Уверуй в Истинный Язык!"?
Дело не в истинности, дело в том что perl, php, ruby, python, nodejs, go - тормозное г@вно, которое просто не надо было создавать.
Только ассемблер, только хардкор? Или сделаешь милость и позволишь тормозному С существовать.
> таким же хламом как и perl:D
> Начни с простого, посчитай количество пакетов с модулями из CPAN, потом сравни
> с общим количеством модулей на CPAN.Я немного о другом спрашивал.
> Счет недостающих пакетов будет идти на тысячи, здоровячок.
А не задумывался что это множество может совпадать с никому не нужными нафиг проектами на CPAN?
Что за детский эгоцентризм? Повзрослей уже и перестань ставить знак равенства между своими нуждами и нуждами всего остального человечества.
> Повзрослей уже и перестань ставить знак равенства между
> своими нуждами и нуждами всего остального человечества.И каким образом туча никому не нужных модулей на CPAN отражают
нужды человечества? Человечество походу в основном о них просто не знает...Наличие модуля в дистрибутиве - вполне объективный показатель нужности. Если нужного вам
модуля в репах нет - давайте уже в студию его ФИО и будем разбираться почему его нет.
Ладно, поясню как законченному эгоцентристу. Есть ты, которому никогда не были нужны модули CPAN, неопакеченные ментейнерами дебиана. Есть я, которому были нужны десятки таких модулей. Остальное человечество оставим в стороне. Итого, в половине случаев такие модули нужны, но не имеют пакетов.
> Есть ты. Есть яВ любом случае - куцая статистика для выводов.
Ну тебе хватало одного себя, чтобы делать мощные выводы о ненужности чего-либо вообще никому.
Наличие или отсутствие пакета в дистре говорит не о его нужности/ненужности, а о наличии того, кто готов взять на себя труд создать и в дальнейшем поддерживать в актуальном состоянии этот пакет. И это в случае свободного софта, а для проприетари есть еще вопрос легальной возможности создать и распространять пакет с софтом.
> Ну тебе хватало одного себя, чтобы делать мощные выводы о ненужности чего-либо
> вообще никому.Вот потому я таких глупостей и не делаю, в отличие от.
> Наличие или отсутствие пакета в дистре говорит не о его нужности/ненужности
Говорит, конечно. Раз есть - значит точно кому-то нужен.
> о наличии того, кто готов взять на себя труд создать и
> в дальнейшем поддерживать в актуальном состоянии этот пакет.Да, и о том что ему нужен.
Ты дурачок или так умело им прикидываешься? В контексте обсуждения вроде должно быть ясно, что речь идет о том, что отсутствие пакета не означает его ненужности.
> отсутствие пакета не означает его ненужности.Сами сделали глупый вывод - сами его опровергли. Лепота.
> Начни с простого, посчитай количество пакетов с модулями из CPANНу в альте написали импорт, если вдруг кому-то нужен весь собирающийся на линуксе CPAN: https://lists.altlinux.org/pipermail/devel/2013-July/197587....
>И какого нужного тебе пакета нет в репах дебиана, болезный?deadbeef нет, хотя тут проблема не в Debian, а в том что у deadbeef автор слегка на своей волне, примерно так же как и ты на своей волне с "выпускниками технических университетов-пту".
>>И какого нужного тебе пакета нет в репах дебиана, болезный?
> deadbeef нетО ужас, в Debian нет проигрывалки музЫки...
Мне всё равно до дебиана. Даже не ставил никогда.Я о той проблеме, что для каждого дистра надо пилить свой отдельный пакет. Идёт фрагментация линуха даже в пределах одной версии ядра. Если для винды один установщик будет работать в пределах трёх-четырёх версий, то такие же условия для линуха невозможны (для каждой версии — свой пакет).
А если говорить о пакетах, то мне не хватает оригинального OO.
> Я о той проблеме, что для каждого дистра надо пилить свой отдельный пакет.Почему? deb/rpm. Внутри каждого семейства - есть стандарты, которые стараются соблюдать.
Это не супер, конечно, но судя по статистике - проблема в том что LSB просто не используют.
> А если говорить о пакетах, то мне не хватает оригинального OO.
Вы некрофил?
Использую! Помнишь первые несколько Humble Bundle? Три вкладки: Windows, Mac OS, Linux, ниже - ещё две вкладки: Direct Link и Torrent. В Linux - при кнопки: RPM, DEB, tar.gz. В некоторых случаях слева - переключатель 32-bit/64-bit. Так вот, эти игрушки до сих пор работают. Ибо LSB.Потом были разные порты игр. Те, что делал Icculus, работают и сейчас. Те, что делали разработчики игр сами, сейчас имеют проблемы в работе. Не знаю как у всех, но лично у меня некоторые игры требуют либ, которые давно устарели, и в дистрибутивы не кладутся. Вместо них лежат такие же, но на новом ABI. Это не тру. И вот почему нужен LSB.
отрадно наблюдать страдания юзера проприетарщины.
> отрадно наблюдать страдания юзера проприетарщины.Да вам любые страдания наблюдать отрадно, так ведь? ;)
конечно: совершенно неважно, как страдает проприерастная подстилка.
> конечно: совершенно неважно, как страдает проприерастная подстилка.И даже совсем не важно, проприерастная это подстилка, или нет.
>Внутри каждого семейства - есть стандарты, которые стараются соблюдать.Семейства! Для каждой версии — новый пакет. Эта политика не позволяет свободным разработчикам _самостоятельно_ поддерживать пакеты под несколько версий одного только дебиана. А дистров, что собак нерезанных. В результате тратится много ресурсов, и разработчики не всегда сами собирают пакеты.
Тот же OO ставится на винды версий от хп до 10-ки.
>Вы некрофил?
Нет. А вы?
>>Внутри каждого семейства - есть стандарты, которые стараются соблюдать.
> Семейства! Для каждой версии — новый пакет.Да нет, совершенно не обязательно.
> Эта политика не позволяет свободным
> разработчикам _самостоятельно_ поддерживать пакеты под несколько версий одного только дебиана.Теоретик?
>>Вы некрофил?
> Нет.А почему так похожи?
Ну т.е. если не получится поставить пакет 3 летней давности потому, что совместимых версий зависимостей в диструэибутиве нет, ты своей жопой ответишь за слова?> Теоретик?
> Некрофил?
> А почему так похож?Один дурак может задать столько вопросов, что не ответит тысяча мудрецов. Осебенно, если эти вопросы не по теме.
> Ну т.е. если не получится поставить пакет 3 летней давности потому, что
> совместимых версий зависимостей в диструэибутиве нет, ты своей жопой ответишь за слова?Да, конечно. Если сперва ты мне докажешь что LSB эту проблему решает.
>> Теоретик?
>> Некрофил?
>> А почему так похож?
> Осебенно, если эти вопросы не по теме.Я бы не сказал что "не по теме". Первый эпитет - отражает насколько поциент
знаком с тем как обстоит дело с совместимостью в Debian (вовсе не так плохо).Второй - использование OO. Некрофилия как она есть.
>Если сперва ты мне докажешь что LSB эту проблему решает.Доказывать что на ОДНУ ВЕРСИЮ программы в РАЗНЫХ версиях lbcnhb,enbdf kbye[f могут быть РАЗНЫЕ пакеты? Да сплошь и рядом!
>Второй - использование OO. Некрофилия как она есть.
Я не нуждаюсь в диагнозах некомпетентных людей. Свои бурные фантазии при себе оставьте. Факт остаётся фактом: для разных дистров и версий дистров — разные пакеты, что делает заявление, что на линухе можно любую прогу, главное исходники бы были, не совсем честной. Запустить-то может и можно, но нередко придётся и с бубном потанцевать, в то время как в венде всё работает.
Так яснее? Или снова будет недодиагноз?
>>Если сперва ты мне докажешь что LSB эту проблему решает.
> Доказывать что [...бредогенерация...]Нет. Доказать, что LSB решает проблему совместимости даже в отдельно взятом дистрибутиве.
Это всего-лишь куцый стандарт, который не решает проблему совместимости даже
для десятой доли архива Debian, если быть оптимистом.>>Второй - использование OO. Некрофилия как она есть.
> Я не нуждаюсь в диагнозах некомпетентных людей.У "компетентных" кончились аргументы и они начали какашками кидаться?
> что делает заявление, что на линухе можно любую прогу
Можно любую прогу что?
>Это всего-лишь куцый стандарт, который не решает проблему совместимости дажедля десятой доли архива Debian, если быть оптимистом.
Мне плевать на дебиан. Я говорю о Линуксе в целом. Отсутствие общих стандартов делает малоудобным использование старых программ (которое вы, в силу своих сексуальных проблем называете некрофилией). В винде нет таких проблем.
Я опять приведу вам в пример винду, где почти всё, что писалось даже для вин2000 работает до сих пор (кроме драйверов и очень уж специфичных вещей).
Если вам нужен пример, то почитайте форумы про запуск нативных героев 3 РоЕ. Так прям инструкции выкладывают от того, что поддержки нет.
>У "компетентных" кончились аргументы и они начали к@к@шк@ми кидаться?
Видимо так. Какими словами ещё описать ваши откровения вида:
>некрофилия
>[...бредогенерация...]Явно тут прослеживается мощь интеллекта и воспитанность, впитанная с молоком матери.
Кстати, пришлось вашу цитату подправить, ибо фильтр опеннета не позволяет анонимам быть такими же хамами, как зарегистрированным пользователям.>Можно любую прогу что?
Запустить. С запуском программ, которых нет в репах, у обычных пользователей нехилые проблемы.
>>Это всего-лишь куцый стандарт, который не решает проблему совместимости даже
>>для десятой доли архива Debian, если быть оптимистом.
> Мне плевать на дебиан. Я говорю о Линуксе в целом.Так экстраполяция на весь Линукс будет только хуже, соответственно.
> Отсутствие общих
> стандартов делает малоудобным использование старых программ (которое вы, в силу своих
> сексуальных проблем называете некрофилией).Некрофилией я называю использование заброшенных проектов, а не
просто "старых программ". Со старыми программами - все пучком. Тянем
исходники, собираем и поем. Да, это работает иначе чем в виндофс, но
работает надежно.LSB - прежде всего для пропиетарного софта. Как оно оказалось востребованым - см.
статистику в тексте топика. Проблемы с совместимостью для ПО дистрибутива - LSB
не решает от слова вообще, т.к. учитывает самый мизер необходимых пакетам зависимостей.> В винде нет таких проблем.
Сборка чего либо в виндофс - отдельная песня.
> Я опять приведу вам в пример винду, где почти всё, что писалось
> даже для вин2000 работает до сих пор (кроме драйверов и очень
> уж специфичных вещей).Последний раз, когда я с этой гадостью сталкивался - "специфичной вещью" оказалась
Mathematica. Кстати, в Linux оное без проблем работало на протяжении трех релизов
Debian. Это сколько в поп^Wвиндовсах?> Если вам нужен пример, то почитайте форумы про запуск нативных героев 3
> РоЕ. Так прям инструкции выкладывают от того, что поддержки нет.Ну так и у меня в Linux герои работают, самые нативные из нативных.
>>Можно любую прогу что?
> Запустить. С запуском программ, которых нет в репахА почему их нет в репах?
>Некрофилией я называю использование заброшенных проектов, а не просто "старых программ".У слова есть конкретное значение. Остальное — фантазии.
Да и оценка заброшенности необъективна, ибо в мире СПО на многие продукты годами может не выходить обновлений. Я же лично сам недавно отсылал баг ОО, и получил ответ разработчика.
>LSB - прежде всего для пропиетарного софта.
И тем не менее. Я не говорю что нужен именно этот стандарт. Я говорю что нужна хоть какая-то унификация, чтобы можно было делать универсальные пакеты... Или мне просто кажется?
>А почему их нет в репах?
Как мне говорят на форумах «нет желающих поддерживать». Однако не у всех пользователей (у меня, к примеру) хватит квалификации самим создать пакет.
> Да и оценка заброшенности необъективнаНе хочу спорить, т.к. смотрю на LO и OO исключительно со стороны. Слухи ходят, что
разработчики с OO сбежали, может после того как оракел скинул проект под
крылышко апача - ситуация переменилась.> Я говорю что нужна хоть какая-то унификация, чтобы можно было делать
> универсальные пакеты...А смысл в унификации, которая все равно де-факто не работает?
>>А почему их нет в репах?
> Как мне говорят на форумах «нет желающих поддерживать».На каких конкретно "форумах"?
> Однако не у всех
> пользователей (у меня, к примеру) хватит квалификации самим создать пакет.Зависит от. Для модулей CPAN, к примеру - это шаблонное действие.
>А смысл в унификации, которая все равно де-факто не работает?А другая есть вообще? Хоть какая-нибудь?
А то как только идёт новость о внедрении линух в госучреждения, то появляется куча «специалистов», которые даже понятия не имеют о поддержке и сопровождении. Даже простого понимания, что отсутствие стандарта уже сокращает выбор дистра, у них нет.Как-то, лет 10 назад, участвовал в переводе парка маших с вин98 на винХП. Получилось завести все самописные программы, у которых исходники давно были утеряны. Среди них были и досовские, с фокспрошной базой, и на VBA написанные, которые нужно было между версиями офиса прокинуть (между 97 и 2003). Всё заработало.
В линухе бы хз как провернул бы...>На каких конкретно "форумах"?
АльтЛинуха. Когда-то спрашивал про наличие того или иного продукта, который в репах абанты был, а в альтовских нет.
>>А смысл в унификации, которая все равно де-факто не работает?
> А другая есть вообще? Хоть какая-нибудь?Лучше плохую и никем не используемую, потому что потому?!
> А то как только идёт новость о внедрении линух в госучреждения, то
> появляется куча «специалистов», которые даже понятия не имеют о поддержке и
> сопровождении. Даже простого понимания, что отсутствие стандарта уже сокращает выбор дистра,
> у них нет.Никакое отсутствие стандартов мне не запрещает запускать древние приложения под Linux. Не было
просто LSB во время их написания/портирования...Да и зачем госучереждениям упала бинарная совместимость? Mathematica запускать?! Не
жирно будет? Для местного легаси-гуано ("без исходников") из виндовс - есть вайн.> В линухе бы хз как провернул бы...
В "линухе" есть исходники.
>>На каких конкретно "форумах"?
> АльтЛинуха.Не удивляюсь что у местечкового дистрибутива "нет желающих". Не нужен, вот и.
>Лучше плохую и никем не используемую, потому что потому?!Нет. Вменяемую, конечно же. Но не предвидится. Потому и 2% рынка...
>Никакое отсутствие стандартов мне не запрещает запускать древние приложения под Linux. Не было просто LSB во время их написания/портирования...
Не запрещает. Но, во многих случаях, нужны танцы с бубном, которые не все осилят.
>В "линухе" есть исходники.
Опять же, не все умеют собирать из исходников.
>Не удивляюсь что у местечкового дистрибутива "нет желающих". Не нужен, вот и.
В дебиане XnView MP и OO в официальных дистрах? Или они добавляются, потому что сам разработчик позаботился о ПОПУЛЯРНОМ дистре? Когда сам разработчик подсуетился, я не считаю, ибо решение не универсально для всех остальных. А в винде будет работать, что в хп, что в 10-ке.
> Потому и 2% рынка...Какие еще 2%?!
>>Никакое отсутствие стандартов мне не запрещает запускать древние приложения под Linux. Не было просто LSB во время их написания/портирования...
> Не запрещает. Но, во многих случаях, нужны танцы с бубномА можно не рассказывать про вкус устриц тому, кто их на самом деле ел?
>>В "линухе" есть исходники.
> Опять же, не все умеют собирать из исходников.Аллилуйя!
>>Не удивляюсь что у местечкового дистрибутива "нет желающих". Не нужен, вот и.
> В дебиане XnView MP и OO в официальных дистрах?В дебиане есть LO вместо OO. Т.к. в правилах дистрибутива отдельно оговаривается, что
дохлые проекты в архив не берут.Должен быть живой проект и он должен быть хоть кому-то нужен. Не такие уж большие
требования чтобы оказаться в архиве.> Когда сам разработчик
> подсуетился, я не считаю, ибо решение не универсально для всех остальных.Т.е. в Windows так можно, а тут почему-то разработчикам запрещается паковать для дистрибутивов?
> Мне плевать на дебиан. Я говорю о Линуксе в целом. Отсутствие общих
> стандартов делает малоудобным использование старых программ (которое вы, в силу своих
> сексуальных проблем называете некрофилией). В винде нет таких проблем.
> Я опять приведу вам в пример винду, где почти всё, что писалось
> даже для вин2000 работает до сих пор (кроме драйверов и очень
> уж специфичных вещей).Хочешь я открою тебе секрет, как это делается? Все очень просто, там каждая прога таскает с собой нужные либы и/или статически их линкует. Ты удивишься, но в линуксе ты можешь сделать точно также, man ld.so в помощь. Кроме того есть несколько системных либ, которые для многих прог под винду ставить отдельно. Не пораженные избирательным склерозом виндузятники обязательно вспомнят Visual C++ Redistributable разных годов, пакеты directx, которые зачастую надо индивидуально ставить для каждой игрушки, ну и конечно .NET разных версий. И это не говоря про целую кучу проблем совместимости, которые обсуждаются виндузятниками между собой, но мгновенно забываются, когда надо рассказать сказку про то, что в винде все работает.
>И это не говоря про целую кучу проблем совместимости, которые обсуждаются виндyзятниками между собой, но мгновенно забываются, когда надо рассказать сказку про то, что в винде все работает.Я столько раз сделал оговорку что ПОЧТИ всё, чтобы такие, как вы не придирались. Но это ПОЧТИ вы не заметили. Я в курсе проблем виндовых. В конце концов я не говорил что венда идеальна. Проблемы винды не отменяют косяков линукса.
Почти не считается. В винде xp работает, в 7 рушит систему. Таких программ кучи.
Только есть важный момент. Почти у всех программ есть указанные мной особенности переносимости, а ты говоришь, что почти у всех их нет. Забей в гугл "not valid win32 application" и посмотри на количество результатов. А ведь это только одна из особенностей и только в том случае, когда юзер ее заметил, пошел сам искать решение, но при этом не воспользовался поисковиком.
Каждый судит со своей колокольни. Мне в винде ни одной программы не попадалось, которая работала бы в хп, а в 7-ке не работала. Зато обратная ситуация была: ну нет в репах ОО или XnViewMP, и всё, либо всё ручками настраивай, либо обходись.
Ну я же говорю, избирательный склероз. Крайне распространенная болезнь на форумах.
Это опыт. По работе не сталкивался (хотя знаю что такое бывает), а с линухом — было дело.Что вы пытаетесь доказать? Что у венды есть проблемы с совместимостью? Я этого не отрицал. Просто в моём опыте в линухе эта проблема куда как более чаще встречается. Особено если дистр не совсем популярен. Т.е. каждый пилит свою среду, вместо того, чтобы быть единым фронтом.
Ну выберите популярный дистрибутив и воспринимайте его как замену винде. А то у вас как то странно, жалуетесь на существование множества дистров и при этом хотите выбрать непопулярный и чтобы в нем все было. Неужели непонятно, что дистры существуют как раз потому, что их создатели не хотят делать все так как другие, хотят идти своим путем. Если сделать кишки всех дистров одинаковыми, то чем они будут различаться кроме выбора дефолтного DE и обоев?
>воспринимайте его как замену виндеТ.е. не весь линух должен быть заменой, а отдельная часть? Т.е. фрагментация линуха, о чём я и говорил.
>Неужели непонятно, что дистры существуют как раз потому, что их создатели не хотят делать все так как другие, хотят идти своим путем.
Даже самые популярные дистры друг с другом не совместимы. Потому и нужны стандарты (не конкретно этот, а вообще).
>Если сделать кишки всех дистров одинаковыми, то чем они будут различаться кроме выбора дефолтного DE и обоев?
Унификация должна быть разумной, не? Отличия должны быть, но и клепать под каждую задачу свой дистр (а здесь новостей, про такие дистры навалом), тоже нет смысла.
> Даже самые популярные дистры друг с другом не совместимы. Потому и нужны
> стандарты (не конкретно этот, а вообще).В целом, набор основных пакетов схож, что уже можно считать своего рода стандартом. FHS тоже обычно передерживаются.
Различия в флагах сборки, патчах, пакетных системах и естественно в версиях софта и библиотек.
>>Если сделать кишки всех дистров одинаковыми, то чем они будут различаться кроме выбора дефолтного DE и обоев?
> Унификация должна быть разумной, не?Приведите ваши критерии разумной унификации.
> Отличия должны быть, но и клепать под
> каждую задачу свой дистр (а здесь новостей, про такие дистры навалом),
> тоже нет смысла.Уже есть несколько универсальных дистрибутивов, нет смысла делать новые универсальные дистрибутивы. Но дистрибутивы фокусирующиеся на определенных задачах нужны, так как позволяют отказаться от ограничений накладываемых универсальностью и сфокусироваться на оптимальном решении конкретной задачи: OpenWrt/RIPLinux/RetroPie/etc.
Да, запустить в винде можно, только работать не везде.
Сначала они кричат "LSB не нужен! Я компилирую свой софт в Linux Mint 17, и у меня всё работает! А у кого не работает - вы все ненормальные, и юзаете ненормальные дистры!". А потом выясняется, что не только в других дистрах, но и в том же Mint на одну версию старше всё отвалилось, так как системообразующие либы поменяли ABI. И тогда они кричат "нет стандартов, всё плохо, ужасный линукс, нет, всё, портирования новых версий не будет!"
Какие проблемы со сменой ABI в открытом софте? Вопрос одной пересборки - и выкладывания нового пакета, да. Учитывая, что популярных дстрибутива полторы штуки - не проблема вообще. Пользователи остальных уж как-нибудь разберутся, им не впервой. А если вы о проприетарщине заботитесь - то пройдите лесом, товарищ.
Ты все правильно написал
Судя по описанию стандарта:> Стандарт LSB (Linux Standard Base), определяет единые для всех
> Linux-дистрибутивов правила, средства разработки, бинарные
> интерфейсы и библиотеки. Поддержка LSB позволяет обеспечить
> возможность выполнения продукта в любом LSB-совместимом
> дистрибутиве Linux, без внесения в него специфичных для каждой
> системы изменений.https://www.opennet.me/opennews/art.shtml?num=42360
Отказ от него - не очень хорошо,
ибо бинарные приложения Debian перестанут запускаться на других дистрибутивах Linux без перекомпиляции с соотвествующими путями.Голактеко опасносте!
По описанию да, а по факту он по-моему сдох уже давно...Толку от стандарта, которым никто не пользуется?
ну между рпм дистрами кой какая совместимость все же есть и по сей день, разве что suse подкачала. я вот из федорки еще в мандриву ставил и ниче все ок. из красеой шапки в тож в мандриву и все ок. хотя они конечно близкородственные. а вот если дебианоподобные поломают совместимость по интерфейсам... то ж о па)) будет 2 базы исходников , а то и 3 . между деб пакетами и рпм, ну еще убунтята выделятся. и начнется ад для сборщиков и писателей ))) потому как они тогда будут именно что писать, а не кодить))
У debian есть alien, позволяющий конвертить rpm в dpkg. Так что дебианщиками даже проще, чем любителям скрещивать rpm дистры.
Вы так говорите, будто alien не умеет из dpkg делать rpm.Только качество подобных преобразований с учетом разницы путей (/usr/lib64 в RH против /usr/lib в дебиане), скриптов инициализации (до прихода systemd, во всяком случае) и прочего не слишком велика. Про конфликты версий библиотек я уж не говорю.
Бред это все, в 2015 году проще поставить нужную версию нужного дистрибутива в каталоге и пускать прогу в нем через docker или systemd-nspawn, если под основной используемый ее нет.
что правда то правда alien усть и в рпм дистрах если че. лично пользовал как то раз. но да несовместимость библиотек это болезнь. точнее их путей и названий. пришлось малость поиграть.
Это точно! Мы наблюдаем последние дни, когда можно создатьтакой бинарник, который подходит к абсолютно любому дистру! Теперь хочешь-не хочешь, а компиляй два: для всего Linux, и отдельно для Debian.
> По описанию да, а по факту он по-моему сдох уже давно...
> Толку от стандарта, которым никто не пользуется?Ты реально представляешь себе человека, который строить билд-ферму на базе убер-современного дистра? Для наибольшей совместимости со всеми дистрами, всегда берут немного устаревший дистр. А совместимость между старым и новым обеспечивает как раз-таки LSB!
Не будет LSB - не будет обратной совместимости между Debian 8 и 9, и Ubuntu 15.10 и 16.04. Потому что (в частности) Glib 2.50 не сможет гарантированно запускать софт, скомпиленный с Glib 2.40.
Я Вам открою глаза на некоторые вещи: билд фермы строятся на базе любого дистра, и собирают под любой дистр.Алгоритм их работы простой: разворачивается минимальное окружение целевой системы, в неё устанавливаются сборочные зависимости пакета, после чего в это минимальное окружение делается chroot и выполняется сборка.
Вопрос лишь в том, что потребуется дополнительно прописать зависимости для каждого дистра, будь то rhel/centos, fedora, debian/astra или вовсе какая-нибудь solaris. Их, увы, может быть конечно довольно много, но выяснить их итеративным путём запуска сборок и анализа выявленных проблем, не представляется очень сложной задачей. Единожды выявив эти зависимости, потребуется лишь небольшая корректировка зависимостей при выпуске версии под новую платформу.
Что касается LSB, то для зависимостей продукта он обычно слишком избыточен, так что в условиях столь простой подгонки зависимостей многие предпочитают им попросту не заморачиваться.
> Отказ от него - не очень хорошо,
> ибо бинарные приложения Debian перестанут запускаться на других дистрибутивах Linux без
> перекомпиляции с соотвествующими путями.
> Голактеко опасносте!Эта радость тащит в систему Qt3 и прочий шлак. Оно надо?
Хотя тот же гуглохром или google-musicmanager хотят LSB по зависимостям :(
> Эта радость тащит в систему Qt3 и прочий шлак. Оно надо?А кому-то оно мешает? Либа же не висит в памяти, если не пользуешься софтом, от неё зависящим!
Суть LSB: даже если сейчас актуальна libpng17, то в /usr/lib ОБЯЗАНА лежать также и libpng12, ибо стандарт. Даже если ни одна программа из репозитория старой либой не пользуется - только ты полезешь в интернет и скачаешь скайп или флеш плеер, как либа сразу начнёт использоваться.Две либы - это в случае, если ABI менялся. А если ABI не менялся, то железобетонно обязана быть обратная совместимость. Скомпиленная с Glibc 2.4 программа обязана нормально работать с Glibc 2.22. С GTK+ 2.10 - в 2.24. С Freetype 2.2 - в 2.6. Всю эту тягомотину с обратной совместимостью в этих либах, уверенно тащит на себе Red Hat, а вовсе не Debian.
Так что окружение сборки имеет значение. Берём для примера игру TuxRacer. Исходные коды 2005 года, плюс набор патчей для совместимости с новыми компиляторами.
Компилируем в CentOS 5. Попробуем потом запустить в Ubuntu 12.04. О, чудо! Оно работает! А в Fedora 17? Работает! 23? Работает! А в Ubuntu 15.10? Да!
Компилируем в Debian 7 Wheezy. Пробуем запустить в Ubuntu 12.04. О нет, у нас нет либы libjpeg.so.8, а есть только libjpeg.so.62! Пробуем запустить с Fedora 17 - о нет, нам нужен Glibc 2.14, а в системе только 2.12!
Пробуем компильнуть в Ubuntu 15.10 - вообще нигде не запускается, так как хочет каких-то нереально бешенных версий либ и Glibc, хотя исходник - напомню - 2005 года.
Попробуйсте откомпилить в Генту или Слаке :)
лучший коммент
> Компилируем в Debian 7 Wheezy.А какие lsb-пакеты установлены у компиляльщика? // скрипач пытается измерить радиус кривизны рук докладчика.
> Скомпиленная с Glibc 2.4 программа обязана нормально работать с Glibc 2.22Вопрос с задних рядов: а что, разве во всех линуксах это не должно работать так по-умолчанию? Я считал, что программа, которая только обращается к библиотеке, вообще никак не зависит от внутренних заморочек библиотеки и обязана работать с любой её ABI-совместимой версией. Откуда в Линуксе взялись "хочу библиотеку libzip 1.2.3"? Что там творит gcc, что программа не может подхватить существующую "libzip 1.3.7"?
> Откуда в Линуксе взялись
> "хочу библиотеку libzip 1.2.3"? Что там творит gcc, что программа не
> может подхватить существующую "libzip 1.3.7"?Это не gcc творит, а автор конкретной программы прописал конкретную версию для линковки. Причины у него могут быть разные, но наиболее простая - в версии 1.3.x мог изменится api или поведение по-умолчанию в сравнении с 1.2.x.
Суть ухода от LSB: нет смысла морочить голову с тем, что тривиально решается пересборкой. Ах, вы хотите мимо репозиториев что-то распространять? Вы хотите тащить проприетарщину, для которой исходники недоступны? Ну так сами и мучайтесь и не перекладывайте свои проблемы с больной головы на здоровую.Нет, серьёзно - на кой в открытом софте бинарная совместимость на этом уровне?
Пересборкой и тестированием , мой йуный друк ! Ибо аффторы либ тоже делают ошибки,для которых время от времени приходиццо делать workaround.
> Суть ухода от LSB: нет смысла морочить голову с тем, что тривиально
> решается пересборкой. Ах, вы хотите мимо репозиториев что-то распространять? Вы хотите
> тащить проприетарщину, для которой исходники недоступны? Ну так сами и мучайтесь
> и не перекладывайте свои проблемы с больной головы на здоровую.Обычному пользователю (не фанату FOSS) пофиг, проприетарная программа или нет. Ему важно, чтобы она делала свое дело. Он выбирает инструмент, исходя из задачи, а не из религиозно-политических пристрастий.
Стандарт LSB, по сути, и был защитой от перекладывания с больной головы (зоопарка версий библиотек) на здоровую (вендоров, которым можно было не собирать свой продукт под 100500 дистрибутивов).
для «нормальных пользователей» есть окошечки и огрызки. го‐го‐го.
ОС, как и прикладное ПО, можно выбирать, исходя из задачи.
А вы опять сводите все к религии.
> А вы опять сводите все к религии.А как ещё говорить со свидетелями "обычного пользователя есть"?
Перекидывал с дебиана на арч, и какой итог? Упало с ошибкой сегментации, при этом быстро.
Нужно что Торвальдс сказал: Или LSB или выкидывайте из дистрибутива все слова Linux.
У ядра новая лицензия? LSB-GPL? Использующий исходный код ядра обязуется использовать корпоративный стандарт, только в том случае он имеет право упоминать название ядра в исходных текстах своего продукта.
Торвальдс может поддерживать соответствующие пакеты Debian для обеспечения совместимости с LSB.Debian первичен, Торвальдс с ядром вторичен.
> Debian первичен, Торвальдс с ядром вторичен.Вот когда Hurd или kFreeBSD станут первичным ядром Debian, тогда и будете так говорить.
А пока - идите в сад.
>> Debian первичен, Торвальдс с ядром вторичен.
> Вот когда Hurd или kFreeBSD станут первичным ядром Debian, тогда и будете
> так говорить.
> А пока - идите в сад.Пока только посылалка выросла?
Хочешь LSB - сделай его.
Gentoo и все что на нем основано вы уже линуксами не считаете? А ведь оно никогда, изначально, не поддерживало LSB.
Кроме лицензированных программ, есть ещё куча не-лицензированных, но на 100% совместимых с LSB. Меня Debian вообще удивляет: за МЕСЯЦ до релиза 7.0 Wheezy один из мейнейнеров начал чистить Qt3 и зависящий от него софт. Притом что все заморозки перед релизом уже были применены - а в реалиях Debian-а "месяц до релиза" - это как в нормальном проекте "за день до релиза". Зачем?!Недавно вышел LSB 5.0, где авторы стандарта пошли на уступки для Debian. В манифесте LSB 5.0 сказано, что на Debian и Ubuntu теперь тоже делают ставку: видимо, в прошлый раз (2007 год) эти дистры не были достаточно популярны для этого. Qt3, так и быть, исключили. И ещё там что-то, кому интересно - в "Похожих новостях" есть ссылка...
То есть для них идут на уступки, а они вот так! Что ж, дебианщики, когда Flash Player в вашем дистре не заработает, уверен что определённый процент юзеров ливанёт на RPM-based, где проприетарный софт гарантированно запускаетсяна любом из них. Спасибо одному из разработчиков с шилом в *опе!
> Поддерживаемый в Debian стандарт LSB 4.1 описывает 1493 компонентов, 1672 библиотек, 38491 команд, 30176 классов и 716202 интерфейсов.Так говорят, как будто сами денно и нощно это поддерживают. А не разработчики Glib, Gtk+, Cairo, Pango, libjpeg62, libpng12, fontconfig, freetype (и всего прочего GTK-стека) из компании Red Hat.
Живые стандарты - хорошо и очень хорошо.Мертвые стандарты - плохо.
Мертворожденные стандарты - вообще беда.
Вот так все переберутся на генту
Если действительно от него нет пользы практически никакой, что никто(!) из разрабов не желает дальше его поддерживать - то реально, на кой он нужен? Чё толку со стандартов, если они практически не имеют смысла? Да и потом, минимальная поддержка останется, а прогибаться под прорпиерасов негоже. Тем более для Дэбиана.
>>С момента предложения о прекращении поддержки LSB прошло три месяца, за которые не нашлось желающих взять на себя работу по поддержанию пакетов, связанных с LSB.Чтож никто из "борцов за стандарты" не вызвался на помощь? Zenitar, ты тут больше всех бугуртишь. Слабо было? Или это как с systemd - обосрать проще, чем что-то сделать?
Вы задаете неудобный вопрос и потому будете наказаны презрением со стороны добрых, честных и последовательных линукс-активистов выступающих за все хорошее против всего плохого.
> Если действительно от него нет пользы практически никакой, что никто(!) из разрабов
> не желает дальше его поддерживать - то реально, на кой он
> нужен? Чё толку со стандартов, если они практически не имеют смысла?
> Да и потом, минимальная поддержка останется, а прогибаться под прорпиерасов негоже.
> Тем более для Дэбиана.
>>>С момента предложения о прекращении поддержки LSB прошло три месяца, за которые не нашлось желающих взять на себя работу по поддержанию пакетов, связанных с LSB.Не переживайте, отвалится что-нибудь у кого-нибудь важное, покроют толстыми дебиан и хипстоту, которая такие решения принимает и сразу найдется тот, кто будет поддерживать.
> Чтож никто из "борцов за стандарты" не вызвался на помощь? Zenitar, ты
> тут больше всех бугуртишь. Слабо было? Или это как с systemd
> - обосрать проще, чем что-то сделать?Это не умаляет важности LSB как такового. Мусорить вдоль дороги на трассе плохо, но никто сам не остановится и не уберет чужое. Из этого не следует, что надо отменить моральный принцип "не мусорить" раз никто не хочет убирать. А у вас логика именно такая.
Все очевидно. Ликвидация Linux началась с systemd... Ктото всерьез заинтересован в смерти операционной системы Linux и целенаправленно бьет по самым важным позициям системы. Скоро от Linux останется только одно слово. Большинство дистрибутивов исчезнут. Это заговор больших корпораций против системы Linux! Заговор в котором никто не признается и все будут отрицать о том что существует заговор. А если вы будете настаивать о существовании заговора, то вас будут воспринимать как шутника. Ибо все испытывают страх перед большими корпорациями. Господину Торвальдсу пора всерьез начать искать себе союзников и начинать разрабатывать методы защиты системы Linux... иначе гибель системы произойдет очень скоро. Запомните мои слова!!!
Тьфу-тьфу, systemd принёс в мир Linux-based систем то, чего им давно не хватало: унификацию. Сама система может быть достаточно разной, но теперь ты точно знаешь, что тебе не надо перепиливать инит-скрипты под каждый конкретный релиз.
> Сама система может быть достаточно разной, но теперь ты
> точно знаешь, что тебе не надо перепиливать инит-скрипты под каждый конкретный релиз.Ура! Теперь перепиливать будешь юнит. Ты довольно, школие?
Вспомни когда принимались решения о переходе основных дистрибутивов на systemd тут и на ЛОРе была гигантская толпа ненавистников systemd. Переход состоялся и как-то тонны комментариев о ужасном systemd больше никто не пишет. Не наводит ни на какие мысли? По-моему так кто-то очень не хотел унификации инит системы в огромном и разрозненном семействе дистрибутивов Linux, но systemd приняли и комментарии о ненавистном systemd резко иссякли.
Просто надоело спорить об одном и том же, тем более что каждый остался при своем мнении. IMHO с systemd будет тоже, что и с pa - те кому не нравится будут выпиливать его или использовать дистрибутивы без него. Огорчает только то, что будут systemd-only приложения (как сейчас есть некоторые завязанные за pa). Остается надеяться на здравый смысл разработчиков.
> Огорчает только то, что будут systemd-only приложениянаоборот, радует: сразу ясно, на что не стоит тратить время.
> Просто надоело спорить об одном и том же, тем более что каждый
> остался при своем мнении. IMHO с systemd будет тоже, что и
> с pa - те кому не нравится будут выпиливать его или
> использовать дистрибутивы без него. Огорчает только то, что будут systemd-only приложения
> (как сейчас есть некоторые завязанные за pa). Остается надеяться на здравый
> смысл разработчиков.О, если бы мы говорили о «жесткой» логике. А так, наверняка «здравый смысл» в области разработки программного обеспечения у меня и у самих разработчиков отличается.
И да, Вам же дали несколько свобод в области свободного программного обеспечения. Но дышать то за Вас никто не сможет :) Или за Вас еще и жизнь прожить? Я то себе три намерил, а тут еще за Вас жить ;)
Прочитал ваш пост три раз, но так и не понял, что вы хотели сказать ...
> Прочитал ваш пост три раз, но так и не понял, что вы
> хотели сказать ...Что русскому хорошо, то немцу смерть. (авторство автора)
И прочая лабуда про GPL и про то кто кому и чего должен. И как быть хозяином своей жизни, и той лабуды которую вы в свою жизнь пускаете (на примере программного обеспечения).
А вообще не стоит "запариватся"! Можно просто и счастливо плыть по течению.
> systemd принялиЯ лично в упор не вижу никакого "принятия":
https://qa.debian.org/popcon.php?package=sysvinit
https://qa.debian.org/popcon.php?package=systemd
Кстати да. Судя по этой статистике инсталляций с sysv в полтора раза больше, чем с systemd. Очень познавательные цифры, спасибо.
По-моему, вполне соответсвует соотношению stable/(old)oldstable систем.
> Не наводит ни на какие мысли?Недавно здесь один уважаемый человек комментировал.
http://thequestion.ru/questions/17479/naskolko-teoriya-okna-...Так что продолжайте расслабляться и получать удовольствие!
> Тьфу-тьфу, systemd принёс в мир Linux-based систем то, чего им давно не хватало: унификацию.Ага, даже стандарт не осилили разработать и поддерживать. О какой унификации тут идёт речь? Завихрения в мозге Поттеринга на неё не тянут.
О какой, о какой. О той самой родной, в стиле майкрософта.
Хоть ваше заявление и тупое, позволю его прокомментировать: http://suckless.org/sucks/systemd
Истинно вам говорю: 4 мая 1925 года земля налетит на небесную ось !
> Все очевидно. Ликвидация Linux началась с systemd... Ктото всерьез заинтересован в смерти
> операционной системы Linux и целенаправленно бьет по самым важным позициям системы.
> Скоро от Linux останется только одно слово. Большинство дистрибутивов исчезнут. Это
> заговор больших корпораций против системы Linux! Заговор в котором никто не
> признается и все будут отрицать о том что существует заговор. А
> если вы будете настаивать о существовании заговора, то вас будут воспринимать
> как шутника. Ибо все испытывают страх перед большими корпорациями. Господину Торвальдсу
> пора всерьез начать искать себе союзников и начинать разрабатывать методы защиты
> системы Linux... иначе гибель системы произойдет очень скоро. Запомните мои слова!!!Поздно. На последнем всегалактическом масонском совете представитель Омикрона V явно и однозначно просигналил своими псевдоподиями земному представителю совета (Обаме) - Линукс НИНУЖНА!!
> операционной системы Linuxтакой ОС никогда не существовало. скилл «убить то, чего на свете нет» — очень крутой.
Под убунту прогиб наверное Дистр самодостаточный как и фряха но и та трещит
из за этого
А матлаб с математикой не отвалятся? У математики так точно LSB в требованиях есть.
> А матлаб с математикой не отвалятся? У математики так точно LSB в
> требованиях есть.Ну, значит буду её теперь в chroot-е гонять. А вообще, использую её только потому, что некоторые индивиды только в ней расчёты делают, и мне надо их как-то читать. Для личных нужд и Maxima сгодится.
переходят потихоньку от linux'а к lindows'у.
Новость читал? Все совсем наоборот.
Без стандартов будет больше бардака (даже если они не соблюдались полностью и прежде);
в бардаке работать трудно, поэтому можно только из-под палки;
поэтому работа перетекает в руки компаний;
компании делают проприетарные системы;
потому lindows.
Началась трансформация в DebianD? Или в Debiantu?
Раньше уже говорил: у меня очень переработанный lfs - нет udev/dbus/pulseaudio/systemd, busybox вместо *nix utils, не придерживаюсь строго FHS, glibc тоже существенно подрезана.Opera ставилась без проблем. Лень было собирать LO4 - взял сборку для дебиана - ругнулась, что у меня libdbus нет. Взял libdbus с дебиана - и все заработало (без демона dbus!). Pianoteq, Unreal, ET:QW - тоже работали.
Если не завязываться за дистроспецифичные вещи (привет systemd,pa) и вообще сводить внешние зависимости к минимуму (статическая линковка и включение в поставку редко используемых lgpl библиотек), то все будет работать и без LSB.
ты предлагаешь сделать то от чего в линукс уходили годами)) или разделяемые либы и тому подобное пидумали тупые люди?
Не все так просто: разделяемые библиотеки имеют выигрыш только если используются большим количеством одновременно запущенных программ. Да и то не всегда.Есть мнение, что от разделяемых библиотек больше вреда, чем пользы: http://sta.li/faq
Мое личное мнение - если думать об экономии памяти, то оптимально оставить широко используемые библиотеки разделяемыми, а все остальное - статикой.
Если же речь о максимальной производительности, а экономия памяти не критична - то все статикой.
и медленно превращаемся, превращаемся медленно.... в виндовс...)) меня все больше беспокоит современное пренебрежение ресурсами системы. полагая что их всегда хватит на все. знаешь отличием линукса всегда была стабильность за счет того, что каждую задачу выполняет одно маленькое приложение и передает обработку другому маленькому. это всегда был процесс надежного и нетребовательного использования компьютера, что и сделало линукс одной из ведущих систем в веб, но вы предлагаете сделать из него виндовс. это не может не беспокоить. а по различию дистров дебиан давно уже в переди планеты всей. нет чтоб договориться о единообразном именовании либ, они стали именовать их иначе. как итог нигде кроме дебианоподобных систем их не используешь. и это конечно печально для опен сурс
Возражения технического характера против моего мнения есть?Если вы сходите по ссылке то там и будет про "пренебрежение ресурсами системы" и "каждую задачу выполняет одно маленькое приложение и передает обработку другому маленькому".
Статическая линковка всегда быстрее и в ряде случаев более экономна по памяти.
> различию дистров дебиан давно уже в переди планеты всей
Вы не находите странным, что именно дебиновская сборка LO4 без проблем заработала на очень нестандартной системе?
> и медленно превращаемся, превращаемся медленно.... в виндовс...))DLL hell?
> знаешь отличием линукса всегда была стабильность за счет того, что каждую задачу выполняет одно маленькое приложение и передает обработку другому маленькому.
Называется скромно: "юниксвей", хотя дивано-аналитическая хипстота на опеннете утверждает, что это ненужный пережиток прошлого.
> что и сделало линукс одной из ведущих систем в веб
Ну да, ведь в бздах все было ну совсем не так. Там о юниксвеях ни ухом, ни рылом ...
Так ведь LSB это и есть узаконенный DLL-hell, просто в нем перечислены все возможные версии либ, которые могут потребоваться какому то проприетарному приложению.
> Не все так просто: разделяемые библиотеки имеют выигрыш только если используются большим
> количеством одновременно запущенных программ.Не только. Например, если найдена проблема в либе, её новая версия компилируется и перезаписывает старую - вот тебе минимальный апдейт!
Аналогично, если ты НЕ хочешь чужих реализаций - кладёшь разделяемую либу на r/o том и все программы юзают одну доверенную либу.
Вощем, преимуществ shared море, просто бардак в линуксах мешает юзать его в полный рост.
>> Не все так просто: разделяемые библиотеки имеют выигрыш только если используются большим
>> количеством одновременно запущенных программ.
> Не только. Например, если найдена проблема в либе, её новая версия компилируется
> и перезаписывает старую - вот тебе минимальный апдейт!
> Аналогично, если ты НЕ хочешь чужих реализаций - кладёшь разделяемую либу на
> r/o том и все программы юзают одну доверенную либу.1. Многие программы тягают библиотеки с собой, например ff.
2. Программа может завязаться за подверсию (или вообще конкретную версию) библиотеки.
3. Часть функции может быть размещена в заголовочном файле и есть большая вероятность что такие функции будут внедрены (inline). Соответственно, при изменении заголовочных файлов библиотеки, нужно все пересобрать, дабы гарантировать корректность обновления.Как вы предлагаете отслеживать подобные ситуации при обновлении только разделяемой библиотеки?
> Вощем, преимуществ shared море, просто бардак в линуксах мешает юзать его в
> полный рост.Перечислите все преимущества.
Я же приведу недостатки:
1. относительно сложный и медленный механизм загрузки библиотек
2. требуется загрузка в память всей библиотеки и всех ее зависимостей, даже если используется всего одна функция одной программой
3. сложности с inline и lto - меньше итоговая производительность приложения
4. переносимость приложения
5. сложности при необходимости собрать разные приложения (или одно и тоже приложение) с разными версиями
6. overlinking: частично решается --as-needed, но не полностью и не все приложения собираются с этим флагом
Я хоть и не Kodir, но отвечу.От таскания бибилиотк с собой тот же Firefox прекрасно отучался, в генте для него и для seamonkey апчка флажков вида use-system-X.
Если софт завязывается на подверсии - обычно от него стоит держаться подальше - либо автор чудит, либо авторы используемых библиотек. На моей памяти исключением, с которым пришлось смириться, является только ffmpeg.
Насчёт заголовочных файлов - а в чём проблема? Изменил внешний интерфейс (а заголовки - это именно оно) - меняй вторую цифру, показывая сломанный ABI.
А преимущество для меня очевидно - автор приложения не обязан следить за минорными версиями библиотеки, корректное версионирование автоматом даёт возможность исправлять ошибки в библиотеке, не затрагивая автора приложения вообще никак. Остальное, по большому счёту, шелуха.
> От таскания бибилиотк с собой тот же Firefox прекрасно отучался, в генте
> для него и для seamonkey апчка флажков вида use-system-X.В FF да, там не понятно зачем они библиотеки с собой таскают, может что бы под виндой проще собирать было. Но обычно для этого есть повод - библиотека может быть модифицирована под нужды проекта или она настолько редко встречается, что озадачивать пользователя ее отдельной установкой не имеет смысла.
> Если софт завязывается на подверсии - обычно от него стоит держаться подальше
> - либо автор чудит, либо авторы используемых библиотек. На моей памяти
> исключением, с которым пришлось смириться, является только ffmpeg.Согласен, обычная практика - завязываться только за первую цифру версии, так как ее смена часто связана со сменой api. Но эта же практика приводит к сложностям при обновлении abi (второй цифры). Получается, что при смене abi в библиотеке, мы должны атомарно (в один заход) обновить библиотеку и весь софт ее использующий, иначе мы потенциально можем получить частично сломанную систему.
Обновление glibc это вообще черная магия :) А ведь если линковать ее статически, то мы сможем обновить любой пакет в любой последовательности и на каждом этапе система будет полностью работоспособной.
> Насчёт заголовочных файлов - а в чём проблема? Изменил внешний интерфейс (а
> заголовки - это именно оно) - меняй вторую цифру, показывая сломанный
> ABI.В целом согласен, но не уверен, что крупные библиотеки меняют вторую цифру, если в одной функции в заголовочном файле исправили одну ошибку.
> А преимущество для меня очевидно - автор приложения не обязан следить за
> минорными версиями библиотеки, корректное версионирование автоматом даёт возможность
> исправлять ошибки в библиотеке, не затрагивая автора приложения вообще никак.А при чем здесь автор приложения? Вы случайно не путаете статическую линковку со встраиванием библиотек в исходный код?
Автор выложил исходники и отметил минимальные рабочие версии библиотек, дальше собирайте как угодно, хоть статически, хоть динамически.
У меня гента, так что о пересборках после смены второй цифры я некое представление имею :) Но вот сломать систему как-то не выходило. Как делается - не знаю, я, честно гвооря, в детали не лез. Ноработает вполне приемлемо, включая апдейт libc. То есть это не проблема, к которой решения нет. Впрочем, с вариантом "пересобирать, используя старую библиотеку, потом разом всё заменить" тоже особых проблем не вижу.Статическая линковка обычно ходит с тасканием библиотеки с собой - здесь да, попутал немного. С другой стороны - даже с просто статической сборкой в source-based мы имеем гору лишних пересборок, а в бинарных - свалившуюся с ровного места нагрузку не на авторов, так на маинтайнеров. А shared libs - отличный способ делегирования.
Кроме того, лично мне очень не нравится идея параллельного наличия нескольких возможно несовместимых версий чего угодно (библиотеки, приложения - не важно) в системе без особых мер предосторожности - побиться можно отнюдь не тоько об abi а, например, о формат конфигов, или временых файлов, или ещё чего. Это всё лечится - но как бы не получить в итоге GoboLinux.
> У меня гента, так что о пересборках после смены второй цифры я
> некое представление имею :) Но вот сломать систему как-то не выходило.А я вот сталкивался с глюками, после обновления отдельных нижних gtk библиотек - приходилось пересобирать все библиотеки и приложения их использующие.
> Как делается - не знаю, я, честно гвооря, в детали не
> лез. Ноработает вполне приемлемо, включая апдейт libc. То есть это не
> проблема, к которой решения нет.Все это существенно усложняет систему сборки - нужно сперва собрать toolchain, который потом пересоберет binutils/glibc/gcc.
> Впрочем, с вариантом "пересобирать, используя старую
> библиотеку, потом разом всё заменить" тоже особых проблем не вижу.Canonical уже пришла к выводу, что надежнее и проще обновлять нижний уровень за один заход.
> Статическая линковка обычно ходит с тасканием библиотеки с собой - здесь да,
> попутал немного. С другой стороны - даже с просто статической сборкой
> в source-based мы имеем гору лишних пересборок, а в бинарных -
> свалившуюся с ровного места нагрузку не на авторов, так на маинтайнеров.Для маинтайнеров это не проблема - эта операция может происходить полностью автоматически.
> Кроме того, лично мне очень не нравится идея параллельного наличия нескольких возможно
> несовместимых версий чего угодно (библиотеки, приложения - не важно) в
> системе без особых мер предосторожности - побиться можно отнюдь не тоько
> об abi а, например, о формат конфигов, или временых файлов, или
> ещё чего. Это всё лечится - но как бы не получить
> в итоге GoboLinux.В целом согласен, но есть ряд ситуаций, когда это необходимо. Иногда нужно держать стабильную и нестабильную версию одновременно. Есть софт, который уже не обновляется или завязан за старые api библиотек. Да и просто при выходе новой версии библиотеки с новым api нужно либо ждать пока все нужные программы перейдут на него либо держать две версии.
Сразу вспоминаются gtk2/3 и qt4/5.У каждого способа линковки есть свои сильные и слабые стороны. Как я отметил в самом начале, хорошим решением могло бы быть использование разделяемых широко используемых библиотек и статики для редких. Возможно стоит сделать исключение для glibc, так как в разделяемом виде ее сложно обновлять, а учитывая что из нее часто вызываются мелкие функции в цикле, то статическая линковка могла бы хорошо сказаться на производительности практически всех приложений (за счет inline/lto).
Очевидный минус - то, что исправление бага в библиотеке может дойти только через новую версию приложения. Лично для меня этого достаточно, чтобы как чёрт от ладана шарахаться от статически собранного софта.Впрочем, стонов по LSB я тоже не разделяю - это затрагивает только проприетарщину, а с ней в любом случае лучше не связываться по возможности. А в тяжелых случаях - виртуалка с нужной системой в помощь.
> Очевидный минус - то, что исправление бага в библиотеке может дойти только
> через новую версию приложения. Лично для меня этого достаточно, чтобы как
> чёрт от ладана шарахаться от статически собранного софта.а также не работает няшный хак с перехватом функций через LD_PRELOAD. да, это нужно далеко не каждый день; да, можно извращаться с ptrace() и динамическим анализом… а можно просто LD_PRELOAD.
Согласен, возможность интересная, хоть и редко используемая. Мне лично еще не хватает аналога ldd, чтобы можно было понять какие библиотеки использовались при линковке.
согласен, ldd тоже полезная штука.
Убивать надо за советы использовать ldd. Хотите подробностей без риска — objdump -p.
Убивать надо тех, кто тянет стремные бинарники не пойми откуда. Точнее они сами себя убьют.
убей себя, пожалуйста. или по крайней мере научись молчать, когда умные люди беседуют, чтобы твоя глупость не так отсвечивала.
Культурный уровень гопника из подворотни еще не делает вас умным человеком.
Поэтому, не отсвечивайте, пожалуйста.
> Культурный уровень гопника из подворотни еще не делает вас умным человеком.само собой. умным меня делает интеллект — но тебе этого не понять, в твоей оценке разумности интеллекту места не нашлось.
> Очевидный минус - то, что исправление бага в библиотеке может дойти только
> через новую версию приложения. Лично для меня этого достаточно, чтобы как
> чёрт от ладана шарахаться от статически собранного софта.Суеверия и предрассудки :) Зачем ждать новую версию? Достаточно пересобрать (или скачать пересобронный) пакет с новой версией библиотеки.
утомляет пересобирать половину мира при апдейте какой‐нибудь часто используемой библиотеки.
Согласен, но при смене abi все равно придется это делать и гораздо более болезненно.
> Согласен, но при смене abi все равно придется это делать и гораздо
> более болезненно.поэтому я, например, намерен сидеть на gcc 4.9 о‐о‐очень долго.
sidenote: не понимаю, зачем опять было ломать плюсы в gcc5. шило в заднице жить спокойно не даёт, что ли?
Для бинарных дистрибутивов - не суеверия и не предрассудки, а механика работы пакетной системы.P.S. Я просто и Дебиан и Генту испоьльзую, поэтому с обеих точек зрения всё это вспринимаю. для source-based - это просто морока с пересборкой, существенно большая, чем сейчас. А вот для бинарных (которые, чрёт возьми, действительно оптимальнее для большинства) - это масса проблем со своевременным обновлением.
> А вот для бинарных (которые, чрёт
> возьми, действительно оптимальнее для большинства) - это масса проблем со своевременным
> обновлением.ИМХО, нет.
Допустим у пользователя 20-30 программ. Соответственно в худшем случае, на апдейт придет 20-30 бинарных файлов (целиком ведь пакет в таком случае не обязательно обновлять). При этом будет 100% гарантия, что в системе ничего не сломается и обновлять он может эти пакеты выборочно.
Сейчас же на апдейт приходит 200-300 библиотек, которые могут быть не совместимы с установленным софтом, все это нужно установить атомарно и если что-то пошло не так, то есть вероятность битой системы после перезагрузки.
Сейчас у того же дебиана сложнейшая зависимость пакетов друг от друга. В случае же со статической линковкой, пользователь вообще не будет ставить/обновлять библиотеки. Он просто будет ставить/обновлять нужные ему программы. Система (с точки зрения пользователя) станет на порядок проще и понятней.
LOL, читаю на wikipedia:> Стандарт LSB критикуют за то, что он не принимает предложения проектов, в особенности Debian, находящихся за пределами круга его членов.
Понятно теперь, почему отказываются )
> LOL, читаю на wikipedia:
>> Стандарт LSB критикуют за то, что он не принимает предложения проектов, в особенности Debian, находящихся за пределами круга его членов.
> Понятно теперь, почему отказываются )systemd тоже редхат пилит. Однако протолкнули с причмокиванием.
>> LOL, читаю на wikipedia:
>>> Стандарт LSB критикуют за то, что он не принимает предложения проектов, в особенности Debian, находящихся за пределами круга его членов.
>> Понятно теперь, почему отказываются )
> systemd тоже редхат пилит. Однако протолкнули с причмокиванием.Тестеры, расширение рынка за счет подконтрольных продуктов - это выгодно. А уж как данная новость выгодна редхат...
> systemd тоже редхат пилит. Однако протолкнули с причмокиванием.С тем же успехом можно сказать, что systemd пилит Debian.
Hint: посчитайте количество разработчиков с правом коммита.
>Hint: посчитайте количество разработчиков с правом коммита.А LSB кто тогда принимал? Контора, которая не имеет отношения к дебиану и линуксу вообще, или всё же представители linux-дистрибутив, в т.ч. и дебиана? А то складывается такое впечатление, что systemd проталкивает сообщество и Поттеринг живёт исключительно на пожертвования, а LSB разработан исключительно RedHat-ом в своих корыстных целях.
RH не всегда был рассадником портерингов. по крайней мере, таким открытым.
> systemd тоже редхат пилит. Однако протолкнули с причмокиванием.Потому что sysvinit уже начал попахивать, а убунтовский upstart с его CLA мог запросто порвать то, куда его проталкивали.
>> systemd тоже редхат пилит. Однако протолкнули с причмокиванием.
> Потому что sysvinit уже начал попахивать, а убунтовский upstart с его CLA
> мог запросто порвать то, куда его проталкивали.Убунтвоский upstart уже проработал лет 7 и никому ничего не порвал. Даже впиливался небольшой командой из Сanonical вместо sysvinit легко и непринуждённо. А вот после systemd впилить другой инит не представляется возможным.
> Убунтвоский upstart уже проработал лет 7 и никому ничего не порвал.
> Даже впиливался небольшой командой из Сanonical вместо sysvinit легко и непринуждённо.
> А вот после systemd впилить другой инит не представляется возможным.тут всё ещё хуже: upstart мог работать не «вместо», а «вместе». представляешь, какой ужас: выбор давали *всем*! понятно, что upstart был утоплен с максимальной скоростью и надёжностью.
p.s. кто не в курсе — upstart не требовал делать его pid 1, и мог спокойно сосуществовать с другим инитом.
> какой ужас: выбор давали *всем*!С ненавязчивым впариванием бубунтовской CLA в комплекте.
Тоже хороши, чо.
>> какой ужас: выбор давали *всем*!
> С ненавязчивым впариванием бубунтовской CLA в комплекте.э… наблюдаю GPLv2. ЧЯДНТ?
> э… наблюдаю GPLv2. ЧЯДНТ?Не умеешь наблюдать, ессно.
СLA - это про http://assets.ubuntu.com/sites/ubuntu/1533/u/files/section/l...
ещё раз повторяю: открыл исходники, наблюдаю GPLv2. что там карябают убунтята на своём сайте — мне неинтересно.
> ещё раз повторяю: открыл исходники, наблюдаю GPLv2.Если на клетке слона прочтёшь надпись «буйвол», не верь глазам своим.
> что там карябают убунтята на своём сайте — мне неинтересно.
Вот на своем сайте они накорябали, что имеют исключительное право послать тебя на юх и
сделать закрытый форк любого твоего upstart.Это похоже на GPL? Нет, это похоже на BSD, только для избранных.
> Вот на своем сайте они накорябали, что имеют исключительное право послать тебя
> на юх и
> сделать закрытый форк любого твоего upstart.что волнует меня примерно настолько же, насколько волнуют проблемы африканских жителей.
p.s. и, конечно, ты неправ. потому что не «любого моего апстарт», а только кода, который я им отдал с отказом от прав. а если я этот код не отдавал, а просто себе веду форк в сторонке — то весь кайф закрывания развалился.
>> Вот на своем сайте они накорябали, что имеют исключительное право послать тебя
>> на юх и
>> сделать закрытый форк любого твоего upstart.
> что волнует меня примерно настолько же, насколько волнуют проблемы африканских жителей.Зато это волнует разработчиков, не желающих вкладываться в развитие
проектов, паразитирующих на идеях GPL.
> p.s. и, конечно, ты неправ. потому что не «любого моего апстарт», а
> только кода, который я им отдал с отказом от прав.Естественно, все в нужном контексте: "любого твоего" - это про
то, которое взяли себе юбунтовцы (мы же об апстарт, да?). Не подпишешь
CLA - твой код они к себе не примут.
> Не подпишешь CLA - твой код они к себе не примут.ну и отлично, вот и решение. не подпишу. всё, RESOLVED FIXED.
>> Не подпишешь CLA - твой код они к себе не примут.
> ну и отлично, вот и решение. не подпишу. всё, RESOLVED FIXED.Дык а я о чем. Вот так просто и умер апстарт. Без жидомасонских заговоров и
козней бандерорептилоидов из RH.
умер он потому, что хипсторы не умеют программировать, а нехипсторам он нафиг не нужен: у них sysv/monit давно работают.
> а нехипсторам он нафиг
> не нужен: у них sysv/monit давно работают.Это ненаучное объяснение, оно подошло бы и systemd, ан тот не
загнулся. Или подразумевается что systemd развивают нехипстеры?
системдец точно так же не нужен людям — но он нужен красношапке. как только он красношапке нужен быть перестанет (ну, вдруг), системдец впадёт в анабиоз (такой же кривой, как и всё остальное в системдеце) и будет отравлять своим полуразложившимся трупом дистрибутивы, которые об него испачкались. ну, как пшшшшаудио примерно.
> системдец точно так же не нужен людям — но он нужен красношапке.Ну а почему бы красношапке не взять upstart? Ведь запихнула же его в RHEL6.
напиши в красношапку, спроси.
> напиши в красношапку, спроси.Так я ответ уже итак знаю, он озвучен выше. Возглавить прогресс они в случае с upstart не сумели бы из-за CLA.
> Так я ответ уже итак знаю, он озвучен выше. Возглавить прогресс
> они в случае с upstart не сумели бы из-за CLA.конечно. форкнуть апстарт и спокойно развивать самим — это так сложно. каноникал обещали взвод автоматчиков прислать и бомбу скинуть.
Чтобы каноникал пользовался твоими наработками нахаляву, сделав закрытый форк?
> Чтобы каноникал пользовался твоими наработками нахаляву, сделав закрытый форк?у тебя проблемы с чтением и пониманием GPL? попроси тогда кого‐то пояснить, почему с GPL это не работает.
>> Чтобы каноникал пользовался твоими наработками нахаляву, сделав закрытый форк?
> у тебя проблемы с чтением и пониманием GPL?Нет, это ты почему-то читать не научен.
> попроси тогда кого‐то пояснить, почему с GPL это не работает.
Прекрасно работает, если авторские права у кого надо. CLA именно это Марку
и обеспечивает. Все горбатятся за иде^WGPL, а права отдают ему.Это только у RH с закрытым форком ничего не получится как раз из-за GPL лицензии апстарта.
> Все горбатятся за иде^WGPL, а права отдают ему.а теперь приступаем к самой интересной части аттракциона: ты показываешь, где *в* *upstart* такое требование. вот прямо файл в архиве или ссылку на репозиторий. эта часть всегда моя любимая.
>> Все горбатятся за иде^WGPL, а права отдают ему.
> а теперь приступаем к самой интересной части аттракциона: ты показываешь, где *в* *upstart* такое требование.Я тебе давал уже ссылку на CLA бубунту, глупый башка забыл?
>> попроси тогда кого‐то пояснить, почему с GPL это не работает.
> Прекрасно работает, если авторские права у кого надо. CLA именно это
> Марку
> и обеспечивает. Все горбатятся за иде^WGPL, а права отдают ему.Когда участвуешь в разработке проекта входящего в GNU, тоже подписываешь соглашение (присылают бумагу по обычной почте), с передачей авторских прав в пользу FSF.
Естественно все свободы лицензии GPL при этом сохраняются.
Закрытый форк со стороны правообладателя (Canonical/FSF) возможен , если в соглашении не указано обязательство дальнейшего распространения только под свободными лицензиями. У FSF есть подобный пункт. Про Canonical не знаю, не подписывал ;)
>>> попроси тогда кого‐то пояснить, почему с GPL это не работает.
>> Прекрасно работает, если авторские права у кого надо. CLA именно это
>> Марку
>> и обеспечивает. Все горбатятся за иде^WGPL, а права отдают ему.
> Когда участвуешь в разработке проекта входящего в GNU, тоже подписываешь соглашение (присылают бумагу по обычной почте), с передачей авторских прав в пользу FSF.Угу.
> Естественно все свободы лицензии GPL при этом сохраняются.
Разумеется. Но наличие авторских прав в одних чотких руках внезапно может
сделать некоторых людей чуть более свободными. И в частности, разрешить
им то, что по GPL запрещено другим...> Закрытый форк со стороны правообладателя (Canonical/FSF) возможен , если в соглашении не
> указано обязательство дальнейшего распространения только под свободными лицензиями.Или явным образом оговорено то, что правообладатель разрешет (себе) выпуск
производного продукта по произвольной лицензии.> Про Canonical не знаю, не подписывал ;)
Ну так вот узнай. Подписывать для этого не обязательно, ссылки выше были.
> Ну так вот узнай. Подписывать для этого не обязательно, ссылки выше
> были.Почитал - пункт 2.3 разрешает выпуск продукта под любой лицензией, но не понятно, что значит: As a condition on the exercise of this right, We agree to also
license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date.Но все же главное, что любой желающий (в том числе и RH) может сделать форк и развивать его самостоятельно. И в этом случае для RH все равно - взяла она проект, который был только под GPL или под GPL+CLA.
> Почитал - пункт 2.3 разрешает выпуск продукта под любой лицензией, но
> не понятно, что значит: As a condition on the exercise of
> this right, We agree to also
> license the Contribution under the terms of the license or licenses which
> We are using for the Material on the Submission Date.да, в общем‐то, понятно: это про contributions to the original project. а если просто форкнуть и развивать — то GPL. все исходники upstart помечены обычной, немодифицированной GPL. ну и всё, на этом можно заканчивать.
p.s. ок, чуть‐чуть модифицированной «шапкой»: насколько помню, там v2 only.
> если просто форкнуть и развивать — то GPL.Это для смердов GPL, а каноникалу - как пожелает.
>> Ну так вот узнай. Подписывать для этого не обязательно, ссылки выше
>> были.
> Почитал - пункт 2.3 разрешает выпуск продукта под любойНу и что тут непонятного?
> не понятно, что значит: As a condition on the exercise of
> this right, We agree to also
> license the Contribution under the terms of the license or licenses which
> We are using for the Material on the Submission Date.Ну вот на момент подписания upstart был под GPL, это и означает,
что Марк "license the Contribution under the terms of the license". Все,
больше тебе ничего не должны - Марк может далее окуклиться
и развивать только закрытый форк.> Но все же главное, что любой желающий (в том числе и RH)
> может сделать форк и развивать его самостоятельно.Да может, конечно. Но у бубунты - приемущество, они могут сделать
в т.ч. и закрытый форк. Формально - проект под GPL, но фактически
условия распространения кода более походят на BSD.
речь вообще шла про *форк*. код которого будет GPL, и «отдавать» ничего никому не надо. но оппонент, извиняюсь, идиот, с чтением там нескладухи.
> речь вообще шла про *форк*. код которого будет GPLТебе тогда надо было другие слова употреблять, а не прямо
противоположные. Речь шла о возможности закрытого форка, см. #260.
то, что ты идиот, и не умеешь читать — не мои проблемы.
>а убунтовский upstart с его CLA мог запросто порвать то, куда его проталкивали.Не трожь выскочку (upstart)! На нём все RHEL-ы 6-ые, весь ынтерпрайс!, работает!!
>>а убунтовский upstart с его CLA мог запросто порвать то, куда его проталкивали.
> Не трожь выскочку (upstart)! На нём все RHEL-ы 6-ые, весь ынтерпрайс!, работает!!Rhel6 работает на init scripts. Апстарта рядлм не стояло.
>>>а убунтовский upstart с его CLA мог запросто порвать то, куда его проталкивали.
>> Не трожь выскочку (upstart)! На нём все RHEL-ы 6-ые, весь ынтерпрайс!, работает!!
> Rhel6 работает на init scripts. Апстарта рядлм не стояло.Ж) Марш уроки учить!
# grep Red /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)
# ps -fp 1
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Oct12 ? 00:00:03 /sbin/init
# rpm -qf /sbin/init
upstart-0.6.5-13.el6_5.3.x86_64
>> Rhel6 работает на init scripts. Апстарта рядлм не стояло.
> Ж) Марш уроки учить!
> # rpm -qf /sbin/init
> upstart-0.6.5-13.el6_5.3.x86_64да-да, мой косяк )) если я его никогда в нем не использовал, это не значит что его нет )
Debian же только для серверов. Всё правильно, совместимость не нужна. Ну а у опеннетовских "аналитиков" в треде - у них Ubuntu.
Сейчас только настоящие профессионалы хмыкнут, вспомнив Gobo-linux - вот она, непонятая хомячками революция! Им объясняешь прелесть новой системы - упираются рогом "да не, да не надо, нам и так хорошо с десятью */bin каталогами!".
Сейчас мы наблюдаем, как менее поворотливые тугодумы из Дебиан постепенно приходят к мысли - "действительно, ЧЕГО РАДИ?". И даю ещё 5 лет их интеллекту допереть до мысли, что давно пора перейти на структуру Gobo и навсегда решить проблему как дурацких "менеджеров пакетов" (десяток несовместимых извратов), так и гармоничности системы в целом.
> пора перейти на структуру GoboЭто в которой для каждого пакета есть свой каталог в /Programs , а потом симлинками всё линкуется во все те же */bin-каталоги?
Я бы этой штуке не доверял. Я вообще не доверяю системам, которые пытаются хранить в одном каталоге больше пары сотен подкаталогов/файлов. А с дебиановскими повадками каждый файл хранить в отдельном пакете (привет, bash-doc, bash-dev, bash-lib) с этим будут проблемы.
> Я бы этой штуке не доверял. Я вообще не доверяю системам, которые
> пытаются хранить в одном каталоге больше пары сотен подкаталогов/файлов.сделай «ls /usr/bin | wc -l» и немедленно сноси мерзкий GNU/Linux!
> сделай «ls /usr/bin | wc -l» и немедленно сноси мерзкий GNU/Linux!В /usr/bin хранятся только бинарники, и обращение к каталогу (и поиск в нём) идёт один раз - при запусе приложения. В /Programs/* хранится вообще вся установленная информация приложения, и обращения к ней идут гораздо чаще.
Хранение бинарников в одном каталоге решает техническую проблему - упрощает запуск через PATH, в который не надо прописывать 100500 значений, каждое для своего приложения. Какую проблему решает /Programs/* ?
Поиск по списку всех бинарников - необходимость. Когда вы запускаете ls, системе в любом случае надо будет просмотреть все места, где может храниться бинарник, на предмет наличия там этого ls, и нет особой разницы - будет это делать userspace перебором каких-то каталогов, или это будет сделано драйвером файловой системы при поиске в одном каталоге.
В случае же какого-нибудь /Programs/Glibc/Current/share/timezone у вас приложение всегда знает полный путь, и нет смысла заставлять kernelspace просматривать весь /Programs/ в поисках Glibc.
Если же делать, как вы предлагаете, то зачем вообще отдельные каталоги, всякие bin, lib, doc, share/man? Давайте всё в одно место класть, будет /Programs/Bash/Current/bash , /Programs/Bash/Current/bash.info , /Programs/Bash/Current/bash.1.gz и т.д.
> В /usr/bin хранятся только бинарники, и обращение к каталогу (и поиск в
> нём) идёт один раз - при запусе приложения. В /Programs/* хранится
> вообще вся установленная информация приложения, и обращения к ней идут гораздо
> чаще.какое это отношение имеет к твоим словам? я их процитирую: «Я вообще не доверяю системам, которые пытаются хранить в одном каталоге больше пары сотен подкаталогов/файлов.» GNU/Linux хранит. поскольку ты заведомо не доверяешь GNU/Linux по идиотской причине, и открыто это признал, никакой практической ценности у твоих дальнейших рассуждений нет.
> «Я вообще не доверяю системам, которые пытаются хранить в одном каталоге больше пары сотен подкаталогов/файлов.»имелось ввиду "Я вообще не доверяю системам, которые пытаются хранить в одном каталоге больше пары сотен подкаталогов/файлов при наличии вариантов." :(
Для кого может и неочевидно. А если например надо найти настройки приложения то гораздо легче их найти в /etc или в ~/.config чем черт знает где.
> Разработчики Debian поставили под сомнение целесообразность обеспечения поддержки в дистрибутиве стандарта Linux Standard Base (LSB)Ждем новости
«Разработчики Ubuntu поставили под сомнение целесообразность обеспечения поддержки в дистрибутиве стандарта Linux Standard Base (LSB)…»
>> Разработчики Debian поставили под сомнение целесообразность обеспечения поддержки в дистрибутиве стандарта Linux Standard Base (LSB)
> Ждем новости
> «Разработчики Ubuntu поставили под сомнение целесообразность обеспечения поддержки
> в дистрибутиве стандарта Linux Standard Base (LSB)…»Воистину ))
Я конечно понимаю, что это всё стандарты, совместимость... Чтобы всё то проприетарное говно, что работало в линуксе 5 лет назад, работало и сегодня(как и в винде с этим их WINAPI). Даже если создатели этого проприетарного говна уже сами забили огромный хер на этот софт, в том числе и на поддержку, но чтобы оно всё равно работало. Даже если оно написано на GTK+ 1.0, или Qt 2.0, или ещё на каком говне мамонта, которое никто не поддерживает, это говно всё равно должно работать, ибо за это говно заплатили бабки. И так далее.Но ведь так вечно продолжаться не может. Чем больше старого говна тащат в новые дистрибутивы, тем больше костылей и работы по их поддержке. Когда-то его да надо сбрасывать, говорить что - "это мы больше не поддерживаем, идите нахер", удалять костыли и перекинуть силы на развитие чего-то нового.
Это в назидание тем ораторам, что страстно бомбят тут по поводу выпила LSB.