LINUX.ORG.RU

Netscape Navigator 9 в Debian 11

 , ,


2

3

Качаем бинарную версию Netscape Navigator 9 for Linux, ставим пакеты `libgtk2.0:i386`, `libpangox-1.0-0:i386`, `libxt6:i386`, `libstdc++5:i386` в Debian 11 Bullseye и все работает!

Забавно, что если перетащить вкладку из нетшкафа в современный firefox она в нем откроется, а наоборот, увы, не работает.

>>> Просмотр (1920x1032, 328 Kb)

★★★

Проверено: hobbit ()
Последнее исправление: zx_gamer (всего исправлений: 2)
Ответ на: комментарий от grem

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

Werenter ★★☆
()

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

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

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

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

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

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от alex1101

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

mittorn ★★★★★
()

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

TheForgetfulGamer
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

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

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

wandrien ★★
()
Ответ на: комментарий от mittorn

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

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

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

alex0x08 ★★★
()
Ответ на: комментарий от wandrien

Пример где вынесение аллокатора и динамического загрузчика очень простой - ты можешь вообще не линковаться к системному 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

mittorn ★★★★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

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

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

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

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

wandrien ★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

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

wandrien ★★
()
Ответ на: комментарий от mittorn

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

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

wandrien ★★
()
Ответ на: комментарий от skiminok1986

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

damix9 ★★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

А является ли 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.

wandrien ★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Ответ на: комментарий от alex1101

4.2

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

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

skiminok1986 ★★★★★
()
Ответ на: комментарий от alex1101

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

hateWin ★☆
()
Ответ на: комментарий от Vsevolod-linuxoid

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

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

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

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

Exmor_RS ★★★
()
Ответ на: комментарий от Exmor_RS

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

alex1101
()
Ответ на: комментарий от alex1101

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

mittorn ★★★★★
()
Ответ на: комментарий от alex1101

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

Exmor_RS ★★★
()
Ответ на: комментарий от mittorn

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

$ ./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 в системе это уже вводное условие.

alex1101
()
Последнее исправление: alex1101 (всего исправлений: 1)
Ответ на: комментарий от Exmor_RS

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

mittorn ★★★★★
()
Ответ на: комментарий от Exmor_RS

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

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

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от mittorn

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

Exmor_RS ★★★
()
Ответ на: комментарий от mittorn

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

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

Exmor_RS ★★★
()
Ответ на: комментарий от Exmor_RS

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

mittorn ★★★★★
()
Ответ на: комментарий от wandrien

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

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.