А почему вы не занесли openSUSE в чёрный список?

«Тормозит сетевой софт». Мало ли почему он может тормозить.

Так сложно приложить результат профилирования?

А маинтейнеры openSUSE выбирают только что-то одно, а остальное заносят в свой чёрный список. В т.ч., например, у них и systemd-resolve в дистрибутиве нет.

Как по мне, решение так себе. С другой стороны, в Windows или MacOS есть зоопарк загрузчиков, инитов, DNS-резолверов, звуковых серверов, WM/DE? На возможность накатить дистрибутив и начать работать подобные решения не влияют. Поддерживать меньшую пакетную базу проще. Допилить до работоспособного состояния – тоже.

Тем не менее, файл libcurses.so есть и там. А исключения везде можно найти потому, что дистрибутивов сотни.

Тем не менее, в таких дистрибутивах как LFS, Slackware, Mageia, Arch, Debian, Ubuntu, Gentoo,... и т.д. реализовано именно через симлинки.

А метод с «INPUT(-lncurses)» упоминался маинтейнером при обсуждении багрепорта, но он и его забраковал. Потому, что у него есть ещё пакет termcap с .so'шниками libcurses.<цифры>.so и он боится как бы введение libcurses.so не зацепило их.

он дал тебе совет, как собирать ископаемый софт не корёжа систему, но ты внёс дистр в чёрный список
nuffsaid

не корёжа систему

Маинтейнеры остальных дистрибутивов спокойно вводят файл libcurses.so в том или ином виде. И "-lcurses" в них прекрасно работает из коробки.

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

Одно дело когда просто твои багрепорты отфутболивают, а совсем другой этот самый элитизм, когда работающее в других дистрах называют «грязными хаками».

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

Ну а в дебиане вот есть пакет в 10ке с плагинами для firefox. Но ни не работают с лисой из реп, внезапно. Как мне тут объяснили, потому что лиса не разрешает не подписанные дополнения.

Но пакет зачем-то оставили. Везде есть «мелочи», просто если долго пользуешься - знаешь и обходишь

Andreas Stieger Head of Product Security SUSE Linux GmbH

Но это в 2019. Вроде потом он «taking a break», но в чем конкретно не в курсе.

Артёмка! Не бузи!

Дескать, маинтейнеры остальных дистрибутивов ничего не понимают и делают дистрибутивы на «грязных хаках», которые в их элитном дистрибутиве просто недопустимы.

Всё правильно сделали

А почему вы не занесли openSUSE в чёрный список?

NYPA

/thread

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

А маинтейнеры openSUSE выбирают только что-то одно, а остальное заносят в свой чёрный список. В т.ч., например, у них и systemd-resolve в дистрибутиве нет.

Resolved есть в пакете systemd-network

Что сделал SUSE/OpenSUSE (куча компаний его разрабатывающих) для мира Linux? Вот серьёзно. Даже Ubuntu-разработчики и то весомый вклад имеют. А эти? Даже вывести KDE в enterprise-лигу не смогли.

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

Тот же OBS https://build.opensuse.org/

Насчёт hostname надо смотреть что за баги у них были. Следовало привести примеры проблемных софтин с твоей стороны именно в opensuse, а не в произвольном дистрибутиве. Ты этого не сделал, поэтому жалоба выглядит неубедительной.

Насчёт

libcurses.so must be symlink to libncurses.so

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

Snapper прикольная штука, в федорку утащил

У него проблемы с головой и он ищет повод поныть, чтобы привлечь к себе внимание. Достаточно успешен в этом плане.

можешь открыть и посмотреть коммитеров ядра, кедов, алсы, btrfs

Считался распространённым в сфере HPC у ряда поставщиков. Cray Linux Environment использует SLES как операционное окружение для запуска сервисов.

Клиенты SAP частенько используют Suse в случае запуска на Linux.

Что сделал SUSE/OpenSUSE (куча компаний его разрабатывающих) для мира Linux?

Интересно услышать что сделал Debian кроме своей системы пакетов не входящей в LSB. Авторам дистрибутивов вроде бы вообще не положено что-то своё делать, только собирать разные чужие пакеты в одно целое.

Novell не один год был одним из крупных контрибьюторов, крупнее Canonical. Когда наблюдал за этим, первые места всегда были за красношапкой, новеллом и айбиэмом или интелом.

Так что это ты зря так про зюзю.

Да и сейчас примерно также, только ибм=редхат

Поставь NixOS уже.

жалоба выглядит неубедительной

Возможно, но в самом hostname в /etc/hosts нет ничего страшного, в то время как маинтейнеры в один голос заявляют, что, дескать, его в любом случае никогда там не должно быть. Что уже весьма подозрительно.

ты должен при сборке подправить список линкующихся библиотек

Нет, не должен. "-lcurses" - это стандарт. Выучил его по манам и книгам и пользуюсь в новом софте с 2006-го года. И он просто работает. Везде. Кроме openSUSE.

Они объяснили, почему это оттуда убрано.

стандарт

Ссылку на стандарт. Мало ли что было в книгах 2006 года.

Если сама библиотека по сборке не поставляет файл с таким именем, то с чего бы его создавать?

«-lcurses» - это стандарт

Покажите место в LSB или POSIX.

Выучил его по манам и книгам

Ваши книги устарели.

Они объяснили, почему это оттуда убрано.

По мнению маинтейнера это вообще не должно работать:

This does not work with shared ELF libraries due to the soname used. The linker does not accept libraries over symlinks with wrong soname. That is if a program is linked against the original libcurses a symbolic link point to libncurses as replacment for libcurses will not work

В то время как оно работает в остальных дистрибутивах и на ЛОРе уже раскрывали принцип работы: линковщик идёт по симлинкам и линкует уже конкретно с /lib64/libncurses.so.x.

Ссылку на стандарт. Мало ли что было в книгах 2006 года.

Бывают и неофициальные стандарты сложившиеся по историческим причинам.

Если сама библиотека по сборке не поставляет файл с таким именем, то с чего бы его создавать?

Для обратной совместимости нарушение которой можно рассматривать как нарушение исторических стандартов.

Ваши книги устарели.

Возможно, но описанное в них продолжает работать.

Не могу пройти мимо немцев. Имею отношения с продукцией smartmicro. Вроде железки хороши, но документация это просто «обнять и плакать».

линковщик идёт по симлинкам и линкует уже конкретно с /lib64/libncurses.so.x.

А они считают, что это не очень хороший подход.

обратной совместимости

Обратной совместимости с чем? Если ты что-то сам собираешь, то подправить, не обломишься. Ещё раз - исходная библиотека не предоставляет файла с таким именем и его делать никто 6е обязан.

Я не психотерапевт и не могу помочь тебе с твоими проблемами.

Ты олько что привёл пример, где не работает. И тут же начал требовать, чтобы работало.

Так в большинстве дистрибутивов работает.

Сегодня работает, завтра нет.

А они считают, что это не очень хороший подход.

с твоими проблемами.

А это их проблемы. А я могу спокойно юзать другие дистрибутивы, где всё работает. И "-lcurses" просто работает в большинстве дистрибутивов.

Обратной совместимости с чем?

Со старыми Unix'ами, где только библиотека curses же. К ним в т.ч. относится и Xenix, который можно завести на старых IBM PC.

Сегодня работает, завтра нет.

Вот когда маинтейнеры большинства дистрибутивов повыпиливают - тогда и будет о чём говорить. А пока что выделяется чуть ли не одна openSUSE (другие примеры пока что не обнаружены).

Давайте спорить о вкусе устриц и кокосовых орехов с теми, кто их ел, до хрипоты, до драки...

Если все будут ныть как ты и запиливать обратно, то не выпилят.

Да, они многое потеряли без тебя.

Обратная совместимость - важная вещь. Хотя, понятное дело, в том мире, где возможны всякие Python'ы (сам язык весьма неплох, да, речь о том, как его готовят), ломающие обратную совместимость между мажорными версиями, её, к сожалению, перестают ценить...

Обратная совместимость - важная вещь.

Важная но обратная совместимость действует только на публичные интерфейсы. Наличие libcurses.so к таковым не относится. Можете взять исходники libcurses.so, собрать и установить.

Держите в курсе

баг про /etc/hosts - какая-то клиника

баг про курсес тоже так себе.

майнтайнеры всё правильно закрыли с wouldnotfix

но 2й баг в арче например исправлен

# some packages look for -lcurses during build
echo 'INPUT(-lncursesw)' > "$pkgdir/usr/lib/libcursesw.so"
ln -s libncurses.so "$pkgdir/usr/lib/libcurses.so"

Суть в том, что библиотека ncurses изначально разработана совместимой с curses. Если бы между ними была бы такая же разница как между иксами и вейландом, то никто и никогда бы не делал libcurses.so симлинком на libncurses.so. Но его потому и делают, что прежние программы, делающие "-lcurses", не замечают разницы. Соответственно, если новый софт использует тоже самое, что и было в curses, то он может быть написан как для curses и собираться как в системах только с curses, так и в системах с ncurses. Это и есть настоящая обратная совместимость.

Зачем тогда выдумали название libncurses.so? Почему при сборке самого ncurses не создаётся символьной ссылки? Это выглядит как проблема в ncurses а не в дистрибутиве.

PS: ncurses и аналоги естественно не нужны ибо псевдографика в консоли - это костыль.

Смотри, ты же можешь сделать чтобы везде работало.

И в Xenix и в новой OpenSuse.

Рассказываю тайные знания.

Берешь пишешь hello world в пару строчек, и пробуешь его скомпилировать с pkg-config --libs ncurses и смотришь код возврата, если скомпилировалось, то запоминаешь это. Если не собралось, то пробуешь собрать с -lcurses, если собралось, то запоминаешь это, если нет выводишь сообщение об ошибке.

В Makefile это нетрудно интгрировать.

В autotools даже есть такое, вот смотри пример: https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L461-L477

И в cmake: https://stackoverflow.com/questions/19817495/cmake-ctest-check-if-code-compiles

И в meson: https://mesonbuild.com/Compiler-properties.html#compile-and-run-test-application

Затем, что, внезапно, это другая реализация. Тем не менее, маинтейнеры дистрибутивов много лет поддерживали и поддерживают совместимость с "-lcurses".

PS: ncurses и аналоги естественно не нужны ибо псевдографика в консоли - это костыль.

Нет, не костьль. Юзеры такого софта как mc, rtorrent, lynx, less, vim,... и т.д. подтвердят.

Да я был готов и на "-lncurses" переписать. Но это если бы объяснения были бы адекватными, а не «не будет такое работать и вообще это грязные хаки» (в то время как оно вполне работает и с точки зрения маинтейнеров большинства дистрибутивов это вполне норма). Людям, которые так объясняют, я доверять не могу. И их дистрибутиву, соответственно, тоже.

mc, rtorrent, lynx, less, vim,…

Список ненужно.

Затем, что, внезапно, это другая реализация.

В Wine (альтернативная реализация Win32) почему-то библиотеки тоже называются kernel32.dll, user32.dll и т.д.. Почему авторы ncurses не могли поступить также? Сами ломают обратную совместимость на пустом месте.