Netscape Navigator 9 в Debian 11

Конкретные примеры привести к сожалению не могу. Просто видел где-то, что они сломали обратную совместимость. Ну и сам факт того, что Arch питон не обновляет, несмотря на свою политику постоянных обновлений, скорее всего вызван именно проблемами с совместимостью.

Вот теперь узнаю старый ЛОР, такой-то эпичный срач.

Вкину ряд тезисов:

1. Обратная бинарная совместимость для линуксов действительно нетипична и является проблемой. Одно из решений: линковка с системными библиотеками в момент инсталляции. Те. вы поставляете *.o файлы а линкуются они уже на машине клиента. Так делает например Оракл.
2. Статичная линковка в один огромный бинарь не означает что все автоматически заработает на более старых линуксах - можете проверить на том же клиенте телеграма, который как раз так собирается и поставляется.
3. На виндах все тоже теперь плохо с обратной совместимостью. Золотые времена патчинга ОС ради работы клиентского ПО (классическая история с SimSity) прошли и видимо больше не вернутся - всем стало проще выкинуть и переписать.

В 3.11 не то чтобы сломали, а удалили то, что было помечено к удалению со времён 3.3, а то и более ранних версий.

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

И они заработают ЧСХ. Хотя там не 10 лет а 20 прошло

Да любой бинарь. Я до сих пор portable бинари в 10летнем убунте/днобиане собираю и ничего не ломается. Это в обратную сторону не работает так

Настоящий Netscape это только третий. И только под FreeBSD. Всё остальное это подделка

Да с musl та же самая проблема будет, только в меньшей степени. И там тоже при статической линковке dns не работает

Ну поставь, ага.

Да с musl та же самая проблема будет, только в меньшей степени. И там тоже при статической линковке dns не работает

DNS можно заставить работать через локальный DNS-прокси. А вот юзеры через LDAP не заработают.

А можно узнать зачем?

10 лет это 2013й год, не так давно по меркам отрасли да и линукса. Точно не сопоставимо с например Total Commander, который до сих пор собирают 3м Borland Delphi ради поддержки Windows 98.

Еще это примерно совпадает с периодом LTS, особенно платным - т.е вообщем-то для серверов это практически современная ОС.

А в чем пердолинг? В том что не положили эти либы рядом с бинарником и не дали скрипт с LD_PRELOAD?

Пример где вынесение аллокатора и динамического загрузчика очень простой - ты можешь вообще не линковаться к системному libc, а линковаться только к той библиотеке которая это всё реализует. Если туда пропихнуть ещё и врапперы сисколов - то ты ещё и от ядра отвяжешься таким образом. Главное чтобы у этой библиотеки не было версионируемых символов.
Проблема glibc в том что он версионирует символы (как же так, у нас поведение sin или pow изменилось - а вдруг старый софт развалится???) И потом слинкованный на 22й убунте бинарь не работает на 21й. Вот она и решается - ты линкуешься к тому libc, с которым твой софт точно работает и дальше либо тащишь его с собой (можно и статически), либо тащишь как зависимость. Да, получается жирновато т.к софт тащит с собой libc и все потроха, зато эти потроха вполне уживаются с системным libc в одном бинаре - 2 верси просто загрузятся параллельно. Что решит вынос аллокатора? То что выделенный в одном libc кусок памяти может быть своболно освобождён из другого. Это же касается TLS, работы с потоками - всё это системная часть которая должна быть общей и не должна версионироваться ломая совместимость каждый год.
Но т.к этого нет - сейчас изобретают snap и flatpak. Которые вынуждены не пару мегабайт библиотек тащить, а десятки потому что им нужен libgl со всеми зависимостями, libX11 или wayland-client, zlib, libpng и ещё с десяток всего что могло бы использоваться из системы.
Ещё проблема, которую это решит: есть rust, pascal и go, которым стандартная библиотека C нафиг не сдалась. Но они всё равно от неё вынуждены зависеть потому что даже банальный dlopen без неё не сделаешь. В винде тем временем есть куча рантаймов для других языков и никакой msvcrt им не нужен - всё делается поверх winapi

Ну вот и смотри, если API платформенной части стандартизовать и не ломать в нём совместимость, то остальные части можно будет таскать с собой. Если вторую тоже держать в системе - то можно будет бинари эти хоть на винде запускать без изменений (при условии что системная и платформенная будет на неё портирована)

Проблема glibc в том что он версионирует символы (как же так, у нас поведение sin или pow изменилось - а вдруг старый софт развалится???) И потом слинкованный на 22й убунте бинарь не работает на 21й.

Ну так надо собирать на 21-й убунте. В контейнере делать сборку, и нет проблем. В винде тоже, если собирать со свежими API, то на старых ОС получим «символ не найден» при попытке запуска.

Что решит вынос аллокатора? То что выделенный в одном libc кусок памяти может быть своболно освобождён из другого. Это же касается TLS, работы с потоками - всё это системная часть которая должна быть общей и не должна версионироваться ломая совместимость каждый год.

Это в целом разумно, про общий аллокатор. Правда версионирование тут вообще ни при чём.

Это кстати ещё одна проблема. Но когда библтотека указана в DT_NEEDED, линковщик знает где искать функцию. Проблемы будут если ещё и имена библиотек совпадают при разных версиях. Тут кстати хорошее решение сделали в bionic (имхо самой лучшей из линуксовых libc сейчас). В нём можно создать неймспейс для загрузки библиотек и в нём иметь свои LD_LIBRARY_PATH и наборы библиотек. И они никак не юудут конфликтовать с библиотеками вне неймспейса даже при совпадении имён. Смотри реализацию android_dlopen_ext в android 7+

Да, заработает

В glibc есть dlmopen() с неймспейсами. Правда на практике с ним дела не имел, не могу прокомментировать, насколько оно решает задачи.

bionic

А как там с поддержкой nss?

В общем, как в 79-м году в коде на си была проблема отсутствия модульности, так с тех пор и мучаемся под юниксами с этим.

Я как раз недавно где-то на ЛОРе упоминал, что вся проблема в тупом линковщике для so, который концептуально не делает ничего сверх того, чо делал линковщик в 70-х для объектных файлов.

А про модульность средствами COM что думаешь?

Но пруфов этого конечно же не будет. У меня на сорвеменном смартфоне работает Tunein radio 6.7, ES explorer 4.0.2.3 из начала 2010-ых. Единственное - когда права, получаемые на рантайме, добавили в 6-ом, сильно подпортили функциональность приложений, которые про это еще не знали. А так, если что-то сделано для API версии n, то оно будет работать на любом API версии >=n.

Не хочу трогать 11. Но на десятке чего бы не работать дровам от XP64. На 32битной десятке дрова от XP юзались постоянно

Нельзя. gethostbyname просто выдаст ошибку что бы ты в resolv.conf не прописал

Потому что там были изменения в ядре, и нет 100% совместимости. Что-то может и работает, но далеко не всё.

А является ли nss задачей именно libc? Я думаю, если надо какой-то сложный dns делать то вообще нет смысла делать это в самом libc, лучше пускать прокси и пускай он адреса уже ресолвит локально. Какой профит от того, чтобы какой-нибудь условный doh с http + tls клиентом грузить в каждый процесс не понятно

Нельзя. gethostbyname просто выдаст ошибку что бы ты в resolv.conf не прописал

???

Разумеется не всё, но драйвера всяких usb-ttl и usb-can конвертеров работают

Когда я последний раз пытался линковтаь musl статически - там была та же проблема что и у glibc - ресолвинг просто перестаёт работать. Притом что у меня там просто 8.8.8.8

А является ли nss задачей именно libc? Я думаю, если надо какой-то сложный dns делать то вообще нет смысла делать это в самом libc, лучше пускать прокси и пускай он адреса уже ресолвит локально. Какой профит от того, чтобы какой-нибудь условный doh с http + tls клиентом грузить в каждый процесс не понятно

Там же не только резолвер доменов, а резолвер обобщенных «имён»:

$ cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd

publickey: files

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

Например, systemd таким образом на лету создаёт временные учётные записи, которые существуют лишь столько, сколько работает сервис, которому они нужны.

Я считаю, что всю эту машинерию, которая начинается от файла /etc/nsswitch.conf и уходит в кучу динамически подключаемых модулей, нужно вынести в отдельный демон, который слушает на прописанном unix-сокете. Тогда любая реализация libc может просто подключиться туда точно так же, как приложения подключаются к dbus или xorg.

Да, верно.
Что с этим в bionic - не знаю. Андройд старается не копировать архитектуру юникосв и gnu, потому вероятно нет ничего. Зато вместо этого система android properties

4.2

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

Есть у меня диск третьих варлордов. И вот не работают они на современной Windows. Ни в какую. И это не единичный случай.

Дай погонять несколько таких бинарей

Да

Нет, все таки любители кричать про пердолинг – кретины. Или очень неумелые тролли.

Тут пример непонимая тобою сути моих претензий.

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

Ты путаешь продукт (бинарник, все библиотеки необходимые для работы, ресурсы, стабильное апи+аби) и просто бинарник.

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

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

Ну например распакуй gqview отсюда:
http://prdownloads.sourceforge.net/gqview/gqview-2.0.4-1.i386.rpm?download
Тест очень даже честный поскольку это даже не статический бинарь, а gtk приложение, которому уже больше 15 лет и его не пытались делать портабельным, однако при наличии gtk2 в системе всё работает. Бинарь собирался под Федорино Горе 3

Я ровно о том же.
Мозиловские тгзшники в этом плане ок.

При наличии

Ну вы понели.

Не запустился:

$ ./gqview 
./gqview: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

хотя gtk2 в системе есть:

$ pacman -Q gtk2
gtk2 2.24.33-3

Ну и да, наличие gtk2 в системе это уже вводное условие.

Пример, который вообще безусловно на десктопе запустится тут приводили уже - старая опера. Даже gtk2 там опционален. Но это и не интересно т.к нифига не демонстрирует обратную совместимость, а опера специально собиралась так чтобы работала везде. То что сейчас так писать и собирать софт не умеют лишь говорит о некомпетентности современных девелоперов с менеджером головного мозга

pacman -S lib32-gtk2
бинарь то 32битный.

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

И чем в этом виноваты те, кто разрабатывает дистрибутивы Linux?

Тем что они оторваны от реального мира.

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

Общепринятая модель - йобнуть флетпаком по оперативке и диску

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

Общнпринятая модель это конечно же рпм/деб, попил продукта на миллион пакетов — и многократный перерасход человека часов на сборку приложений с немного другими версиями либ, под сотни разновидностей и подразности одной и той жп модели устройства ОС.

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

Пакеты - плохо, флатпак - плохо. Просвети же нас, как сделать хорошо.

бандлы? (незапускающийся из-за другой версии qt AppImage врывается в чят)