Почему падает активность в проекте Debian?

Это потом пришла бубунта и все испортила со своей работой изкаропки.

Это где всю дорогу ничего не работало, всё падало и глючило? Наверное, как дистрибутив для только что пришедших с Windows годится, но никогда убунта нормальной не была.

никогда убунта нормальной не была

И не может быть, потому что за основу взято говно (дебиан)

Заведите себе два разных дистрибутива в дуалбуте, и грузитесь то туда, то сюда - по необходимости :)

Не обязателен даже дуалбут: https://bedrocklinux.org/

Каждый минимальный дистрибутив превращается в базар. Даже если договориться какой один десктоп мы будем поддерживать, постоянно люди будут спрашивать «а почему у вас есть приложение Х а нет приложения У?»

Ну вообще-то Арч именно так и устроен как минимальный дистрибутив.

Сама ОС - это репозитории core + extra.

А Community и AUR - это «пакеты сообщества».

Вообще я считаю, что в понятие «стабильный релиз» должна входить «платформа», а не «дистрибутив».

Платформа - это набор различных программных интерфейсов и прочих соглашений о взаимодействии софта.

А пользовательские приложения отдать на откуп демократическим репозиториям, как community+AUR в Арче. И максимально упростить сборку пакетов с нуля, дать плавную кривую входа для стороннего человека. Тогда энтузиасты быстро опакетируют всё, что есть, и во всех видах билдов.

В таком виде релизная модель будет хоть какой-то иметь смысл. Но не как у дебиана.

Стабильный релиз в разрезе платформы - это вам в windows и macos. Линукс либо стабилен как дебиан - т.е. лучше многих иных дистров линукса, но хуже винды и макоси, либо нестабилен в принципе. То же самое с безопасностью.

Линукс либо стабилен как дебиан - т.е. лучше многих иных дистров линукса

Раскройте понятие термина «стабилен».

Сначала вы.

Я под стабильностью подразумеваю совместимость программных интерфейсов в рамках релиза.

Когда ты ставишь на (прежнюю) центось стороннее приложение, и оно получает ровно такую же среду исполнения, как и на машине разработчика.

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

Практика показывает, что всё в линуксе нормально с этим.

Я-то специально на локалхосте сижу на bleeding edge, а для производственных задач существует RHEL и её бесплатные пересборки.

если приложение не написано специальным образом.

Приложение тут ни при чем, это задача сборщика дистрибутива ОС.

Когда ты ставишь на (прежнюю) центось стороннее приложение, и оно получает ровно такую же среду исполнения, как и на машине разработчика.

А что на машине разработчика-то? Дебиан, генту, арч?

Да, но камюнитю надо к ногтю. куча того что мне не надо и нет всего того что мне надо.

А что на машине разработчика-то? Дебиан, генту, арч?

Дак тоже центось.

Дак, если в дебиане разрабатывать - и на дебиан накатывать, то, в рамках одной мажорной версии проблем тоже, не будет, разве нет?

Причём тут CD вообще я так и не понял. Это получается, что любой дистр с автоматической сборкой пакетов – роллинг?

https://wiki.centos.org/Manuals/ReleaseNotes/CentOSStream:

Это протухшая вики с устаревшей информацией.

Какие тут ещё могут быть вопросы?

Это такой тРоллинг или что? Как может дистр быть роллингом, если у него фиксированная база? Centos Stream 9 это будущий минорный RHEL 9.x, оно всё основано на базе Fedora 34 и друг с другом гарантированно совместимо.

Совместима, только в другую сторону. А если версии пакетов фиксировать в соответствии с релизами RHEL, то вообще один-в-один.

Дак, если в дебиане разрабатывать - и на дебиан накатывать, то, в рамках одной мажорной версии проблем тоже, не будет, разве нет?

Можно, но зачем? Если современные rpm-based технологичнее, а дебиан - это неповоротливый проект с болячками из 90-х.

Вот сейчас очередной пример оверинженернутой пакетной базы вспомнил.

Берём любую программу, смотрим зависимости:

# apt show gmrun | grep Depends
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libglib2.0-0 (>= 2.35.9), libgtk2.0-0 (>= 2.8.0), libpopt0 (>= 1.14), libstdc++6 (>= 5.2)

Но что такое эти «libgtk2.0-0» и «libgtk2.0-0»? В экосистеме ПО для линукс таких сущностей нет. Это чисто дебиановские заморочки.

Настоящие зависимости этой программы называются: libglib-2.0.so.0 и libgtk-x11-2.0.so.0. Именно с этими soname выполнено связывание.

Теперь берём пакет в Альте: https://packages.altlinux.org/en/p10/binary/gmrun/x86_64/depends/

И видим libgtk-x11-2.0.so.0 как и положено.

Да была ж, я даже помню конкретный релиз – 7.10. У меня там работало абсолютно всё (я в ней диплом писал) и ещё потом до 8.04 обновилось без проблем.

Как может дистр быть роллингом, если у него фиксированная база?

Если у него фиксированная база, значит я могу поставить центось конкретной релизной ветки RHEL-а. А если не могу, то это тРоллинг.

Предположу — потому, что как бы кому-то ни хотелось видеть «программы без идеологии», сперва всегда идут идеи, а потом уже их техническое воплощение.

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

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

значит я могу поставить центось конкретной релизной ветки RHEL-а

Ну так ты и можешь.

Можно, но зачем?

Ну, если топить за стабильность.

В принципе, я как разработчик, лучше на c# напишу - и будет работать и в линуксе, причём, и в дебиане, и в центоси, и в винде - и до уровня «libgtk-x11-2.0.so.0» мне не придётся спускаться никогда.

Ну блин, смысл читать кликбейтную новость с оупеннета, в которой написана неправда. Мало проголосовало? Ну да. Бывало и меньше? Бывало. Только при чем тут активность проекта непонятно.
А сколько проголосовал на выборах лидера арчлинукса? 0 человек. По этой логике проект вообще неактивен.

Не, не совместим. Он может быть совместим в какой-то момент, и не быть в другой. В итоге задача подбора правильных пакетов ложится на админа. Зачем все это нужно, когда есть Rocky?

Не, если тебе нужен бесплатный RHEL 1-в-1, то да, остаются только рокки и прочие клоны, причём скорее всего лучше взять оракл, а не васянов. А если ты разрабатываешь под RHEL, то Stream тебе подойдёт. То, что в ней работает сейчс, будет 100% работать в следующем минорном RHEL.

Но мы-то говорим не о разработке под RHEL. И нет, оракл не лучше.

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

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

Это протухшая вики с устаревшей информацией.

Ну конечно. 🤦

Причём тут CD вообще я так и не понял. Это получается, что любой дистр с автоматической сборкой пакетов – роллинг?

«Автоматическая сборка пакетов» ≠ «Continuous Delivery».

Давайте вы сначала почитаете и разберётесь в теме, а потом будете спорить, ладно?

Ну конечно. 🤦

Смотрим дату последнего редактирования и думаем.

«Автоматическая сборка пакетов» ≠ «Continuous Delivery».

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

Но что такое эти «libgtk2.0-0» и «libgtk2.0-0»? В экосистеме ПО для линукс таких сущностей нет. Это чисто дебиановские заморочки.

Настоящие зависимости этой программы называются: libglib-2.0.so.0 и libgtk-x11-2.0.so.0. Именно с этими soname выполнено связывание.

Зависимость от конкретного SONAME, конечно, дело хорошее, но в Debian версия ABI из SONAME входит в имя пакета по требованию Политики — такой вот способ решения проблемы без введения доп. сущностей.

Зато это позволяет легко параллельно устанавливать несколько версий одной и той же библиотеки, если требуется, например libncurses5 и libncurses6. В отличие от.

Не знаю как на серверах, но на десктопе дебиан просто лучший.

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

Вы всерьёз переносите количество проголосовавших на количество участников проекта, или это троллинг такой?

Зависимость от конкретного SONAME, конечно, дело хорошее, но в Debian версия ABI из SONAME входит в имя пакета по требованию Политики — такой вот способ решения проблемы без введения доп. сущностей.

Ты это всерьёз написал сейчас? Вместо указания реальной сущности - soname - придумали отдельную сущность, которой нигде больше нет. И это называется «без введения доп. сущностей».

Зато это позволяет легко параллельно устанавливать несколько версий одной и той же библиотеки, если требуется, например libncurses5 и libncurses6. В отличие от.

$ pacman -Qo /usr/lib/libncursesw.so.?
/usr/lib/libncursesw.so.5 принадлежит ncurses5-compat-libs 6.4-1
/usr/lib/libncursesw.so.6 принадлежит ncurses 6.4-1

Задавайте ваши ответы.

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

Здравствуйте… Вообще-то, есть небольшой набор пакетов, для которых изначально заявлено об ограниченной поддержке безопасности, а остальной архив main поддерживается в рамках заявленного срока.

Пакеты, для которых такая поддержка невозможна, просто выкидываются на мороз, например VirtualBox после изменения политики Oracle по патчам безопасности.

Смотрим дату последнего редактирования и думаем.

Дата — после анонса CentOS Stream и прекращения разработки классической CentOS. Что не так? Или что-то с тех пор поменялось, что потребовало бы редактирования страницы?

Только это не значит, что любой дистр с такой системой == роллинг.

Вы не поверите!

Всё, дальше продолжать этот разговор нет смысла. Можете продолжать пребывать на стадии отрицания.

И это называется «без введения доп. сущностей».

Поясняю: без введения нового типа зависимостей, используя текущие свойства пакетов (имя). Так что да, проблема была решена в рамках существующей системы.

Я согласен, что иметь такие зависимости было бы неплохо, и rpm мне этим нравится. Но и в Debian этот вопрос урегулирован, просто пока другим, менее изящным, способом.

ncurses5-compat-libs

Во-первых, это AUR, который:

The AUR is unsupported, so any packages you install are your responsibility to update, not pacman’s. If packages in the official repositories are updated, you will need to rebuild any AUR packages that depend on those libraries.

Во-вторых, я вам могу ещё несколько десятков таких пакетов накидать — уверены, что все в AUR найдёте?

Поясняю: без введения нового типа зависимостей, используя текущие свойства пакетов (имя). Так что да, проблема была решена в рамках существующей системы.

deb/apt не поддерживают поле provides?

Но и в Debian этот вопрос урегулирован, просто пока другим, менее изящным, способом.

Проблема в том, что вот этих «менее изящных способов» в системе набирается вагон. Когда это только несколько местных особенностей, с этим можно жить. Но когда их много, в какой-то момент понимаешь, что проще сменить дистрибутив.

Во-вторых, я вам могу ещё несколько десятков таких пакетов накидать — уверены, что все в AUR найдёте?

Какие в AUR нет, тем сам сборочный скрипт напишу. Пока ни одной библиотеки подобного рода мне пакетировать вручную не пришлось. За 10 лет. Но при чем тут сборка пакетов для Арча вообще?

Поясняю: без введения нового типа зависимостей, используя текущие свойства пакетов (имя). Так что да, проблема была решена в рамках существующей системы.

Я согласен, что иметь такие зависимости было бы неплохо, и rpm мне этим нравится. Но и в Debian этот вопрос урегулирован, просто пока другим, менее изящным, способом.

пока

Он урегулирован таким способом уже очень давно и сдохнет вместе с Debian. И именно из-за таких закидонов из прошлого проще поставить буквально любой другой дистрибутив.

deb/apt не поддерживают поле provides?

Поддерживает, но как там предлагаете указывать, скажем, минимальную версию? Provides вообще немного для другого.

А так можно просто указать Depends: libcurl4 (>= 7.62.0).

Проблема в том, что вот этих «менее изящных способов» в системе набирается вагон

Такого в абсолютно любой сколь-нибудь крупной системе полно, вообще-то. В том числе и в Arch. Одно использование левых инструментов для получения доступа к основному массиву ПО, без которого пакетов в репозитории кот наплакал, чего стоит.

Какие в AUR нет, тем сам сборочный скрипт напишу

Этот подход применим к абсолютно любой системе.

И именно из-за таких закидонов из прошлого проще поставить буквально любой другой дистрибутив.

…со своими, другими закидонами.

Поддерживает, но как там предлагаете указывать, скажем, минимальную версию?

В чем проблема?

provides=('libjpeg=8.2.2')

Этот подход применим к абсолютно любой системе.

Об том и речь. Поэтому заход «как в Арч ncurses5 поставить» заведомо бессодержательный. Ответ будет: «лапками, как и в любой другой дистрибутив».

Об том и речь. Поэтому заход «как в Арч ncurses5 поставить» заведомо бессодержательный. Ответ будет: «лапками, как и в любой другой дистрибутив».

Отнюдь. Реальный сценарий: есть у вас проприетарная программа, зависящая от libncurses.so.5, в репозитории обновили ncurses на 6.x — теперь вы или не сможете обновить ncurses, а значит, и зависящие от неё пакеты, или вам придётся удалить указанную программу. Ну или ставить васянопакеты из AUR/пакетить вручную. В любом случае придётся посношаться с системой.

В Debian же libncurses6 просто автоматически встанет рядом с libncurses5. Всё, вообще никакого ручного вмешательства.

(Конкретно ncurses в данном случае приведена лишь для примера — такое с любой библиотекой произойти может. Лично я сталкивался с этим сценарием для libstdc++5.)

Отнюдь. Реальный сценарий: есть у вас проприетарная программа, зависящая от libncurses.so.5, в репозитории обновили ncurses на 6.x — теперь вы или не сможете обновить ncurses, а значит, и зависящие от неё пакеты, или вам придётся удалить указанную программу. Ну или ставить васянопакеты из AUR/пакетить вручную. В любом случае придётся посношаться с системой.

О, очередные аргументы «от пердолинга» подтянулись. Слушай, ну серьёзно. Мне тут компы на винде приходится админить, в которых бывает весь день сидишь и пытаешься какую-то лажу исправить без документации и логов. А тут я запуска одной команды yaourt должен испугаться?

Я просто перестану воспринимать всерьёз людей, которые простую установку пакета называют словом «сношаться». Это уровень тупых троллей со SLOR-а.

В Debian же libncurses6 просто автоматически встанет рядом с libncurses5. Всё, вообще никакого ручного вмешательства.

В любом rpm-based встанет. Только там нет маразма с именованием зависимостей.

Ты не находишь странным, что в ветке, в которой я сравнивал rpm и deb, ты съезжаешь на «а вот в вашей слаке вообще зависимостей нет!»? Я еще не поехал, чтобы слаку и арч на сервер или в офис ставить.

А про сложность обслуживания debian на практике по сравнению с арчем см. описанное вчера юзером R_He_Po6oT. Его опыт хождения по костылям полностью согласуется с моим.

просто автоматически встанет рядом

Вот прямо совсем просто?

libХРЕНЬ1 зависит от libХРЕНЬ1-common, а libХРЕНЬ2 зависит от libХРЕНЬ2-common, при этом libХРЕНЬ1-common и libХРЕНЬ2-common конфликтуют по файлам. Может такое быть при дист агрейде?

В любом rpm-based встанет. Только там нет маразма с именованием зависимостей.

А вот и нет. Если имена пакетов совпадают (что в основных rpm-дистрибутивах обычно так), то не встанет.

Я не спорю, что rpm в целом получше dpkg (хотя про менеджеры пакетов над ними этого уже не скажешь). Но как показывает практика, все эти придирки к dpkg на самом деле малозначимы в общем пуле критериев, по которым происходит выбор дистрибутива.

О, очередные аргументы «от пердолинга» подтянулись

Угадайте, чья цитата 😉:

Арч намного меньше делает мозг при обслуживании

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

Выше уже был пример: все случаи необходимости ручного вмешательства при обновлении системы документированы на главной странице арча. На главной странице дебиана ты можешь прочитать только про то, что это универсальная операционная система.

Очередное «казаться, а не быть», как принято в мире линукса.

А вот и нет. Если имена пакетов совпадают (что в основных rpm-дистрибутивах обычно так), то не встанет.

[root@4f2a4736552b /]# dnf repoquery --whatprovides libpng16.so.16
libpng16-2:1.6.37-3.i686
[root@4f2a4736552b /]# dnf repoquery --whatprovides libpng15.so.15
libpng15-2:1.5.17-7.i686
[root@4f2a4736552b /]#

Так что да, проблема была решена в рамках существующей системы.

посношаться с системой

Нет, не решена.

Допустим, я скачал тарбол с бинарной сборкой с сайта поставщика ПО, и оно при запуске мне жалуется, что не найден libtiff.so.5.

Мне как, при помощи магического зеркала нужно узнать, какой пакет теперь ставить?