Что-то дикое происходит с линукс-программерами

Просто люто плюсую! Именно так оно и есть.

OpenSource’ная на Qt 3 – moto4lin, в Windows она и её аналог до сих пор работает отлично, под Linux – не работает, потому что Qt 3 удалили из реп, а Linux-дистрибутивы не произвели на свет адекватных механизмов для работы ПО, которое раньше запускалось

Ну если очень нужно и она попенсорснутая, то можно попробовать собрать статиком.

Тут я смотрю всему форуму почти, надо прописать чтение man chroot на ночь, курсом два месяца.

Что вы все мучаетесь с несуществующими проблемами. Старое запускается в chroot окружении, это базовый механизм линукса. Есть и более расширенные аналоги этого, например bubblewrap.

Тоже вариант. В целом все зависит от конкретных условий.

Mac всё чётко и одним файликом

От совсем не обязательно, в ябле зоопарк похуже онтопика. Этакая смесь оффтопика и онтопика.

Да и Win32 местами сильно лучше чем

Очень-очень сильно местами… эти места надо не то что с лупой, с микроскопом выискивать.

а недостатки можно простить

«Понять и простить» (c) ?

учитывая невероятную стабильность по сравнению с текущим Linux миром.

Тут согласен полностью, это невероятно стабильное УГ по сравнению с миром Linux.

В итоге приходится держать несколько версий софтины, написанной на разных языках для разных версий винды.

А ЯП то тут причём? Я понимаю просто разные версии, но переписывать софтину заново из-за смены WINVER эт имхо перебор.

Ну при том, что есть языки без обратной совместимости. Проще написать на питоне, чем изучать особенности раста 1.4 - всеравно придется полностью переписывать.

В итоге на раст для вин8-10 и на питоне для вин7. А еще есть винхр, там вообще надо на си делать, но я забил. Ну ее нахрен.

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

Была вроде такая хрень как dlackware это слака с ненужнод, незнаю правда живо ли оно сейчас.

На вендах даже малые дети знают, как обновить приложения.

Вы про вариант «приложуха спросила «Бум Обновлять меня?», пользак ответил Да!» ?

В основном - про классический вариант «скачать новую версию и ткнуть в setup.exe».

Понял, вы написали на том, что вам нравится и только под последний оффтопик, а проблемы возникли когда понадобилось поддержку предыдущих версий запилить.
Это не платформо зависимая проблема, в том или ином виде подобное будет на любой платформе. Запилили в приложуху использование функции ZdelayMneZashibis которая появилась только в последней версии ОS/lib/etc и внезапно вам нужно запилить поддержку вашей приложухи в систему где этой функции нэма, остаётся только писать эту ZdelayMneZashibis самому.

В основном, про классический вариант «скачать новую версию и ткнуть в setup.exe».

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

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

А можно выбрать Java 1.6 и не иметь таких проблем.

У явы свои приколы есть. Нужна ява, например. Ты сам будешь объяснять юзерам, как ее поставить?

Но я уже изучаю как раз сейчас котлин и мне нравится в принципе. Интересный язык, объединяющий лучшее из других.

Нужна ява, например. Ты сам будешь объяснять юзерам, как ее поставить?

Для этого есть launch4j. Но можно и объяснить.

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

Чем меньше пользователю нужно делать, тем меньше тебе потом нужно объяснять как это сделать. В идеале просто один клик. Кликнут туда то и все работает.

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

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

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

Не у всех знания и опыт, как у тебя. Это неросети могут знать все и распознавать. А пользователи чего то не знают, чего то не умеют на что то забили и что то не заметили. Проще дать самое простое: тыкнул - получил результат.

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

А пользователи чего то не знают, чего то не умеют на что то забили и что то не заметили. Проще дать самое простое: тыкнул - получил результат.

Для этого делают инсталлятор, причем можно и вшить в инсталлятор нужную версию jre.

Ага.. И еще разбираться с десятками виндовых инсталляторов, как чего куда, не имея доступа к винде. Затем объяснять, что нужно дать ему администратора. Зачем? Ну нада..

Подобные идеи лишь множат проблемы. Я просто сделал бинарник. Кидаешь его в папку с игрой и все. Дальше он все сам.

https://github.com/Vladgobelen/NSQCuR/releases/download/v1.0.0/NSQCuR.exe Растовый для вин8+

https://github.com/Vladgobelen/NSQCuP/releases/download/v1.0.1/NSQCuP.exe питон для вин7

Просто и понятно…казалось бы. Но даже с этим бывают проблемы. И их приходится объяснять пользователям.

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

скачать архивы с исходниками ... собрать из этих исходников ...

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

Забросили, systemd много ограничений на систему накладывает, не думаю что кто то будет продолжать работу. За время «паузы» в разработке dlackware, systemd успел отказаться от классических скриптовых сервисов, разделения /usr, и наверное много чего другого.

Да и Win32 местами сильно лучше чем

Очень-очень сильно местами… эти места надо не то что с лупой, с микроскопом выискивать.

Ну вот взять GUI, реактивный, стабильный, многопоточный, с кучей возможностей. IOCP пусть и не io_uring, но появился намного раньше, приложения из 1980х запускаются нормально на HiDPI мониторе. Если рассматривать более низкоуровневые функции, то легче обрабатывать режимы энергопотребления, можно детально настраивать приоритеты для страниц памяти, для чтения из файлов.

Ну вот взять GUI, реактивный, стабильный

Стабильно падающий, одна ошибка в вызове функции может и нередко приводит к «программа выполнила недопустимую…» ну вы поняли.

с кучей возможностей.

Тут не отнять, возможностей под капотом реально дофига.

IOCP пусть и не io_uring, но появился намного раньше

Ну появился и появился, только подождите у меня дискета отформатируется :)

приложения из 1980х запускаются нормально на HiDPI мониторе.

А чего бы им и не запускаться? Моник как-то мешает запуску?

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

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

можно детально настраивать приоритеты для страниц памяти, для чтения из файлов.

Что именно вы под этим подразумеваете?

Ясно. Спасибо за ликбез.
ЗЫ Ну забросили и ладно.

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

Кстати, а как в линуксе почистить /etc и /home/*/.config после удаления программы?

В программах постоянная проблема с MS C++ Runtime и прочими зависимостями, вроде бы поставил приложение, а потом вылезает непонятная ошибка, или просто тишина и отсутствие реакции. В deb например это решено автоматизацией.

В deb можно поставить две версии libstdc++ (например, от gcc-14 и gcc-10)?

Или под автоматизацией подразумевается это: Игра «Бездна света» на свободном движке INSTEAD (комментарий) ?

Например для вин7 на нем писать уже нельзя

Вин 7 это 2009 год. Для Debian 5 писать можно?

Как показала практика, даже для дебиан12 писать нельзя.

А так - вин7 одна из популярнейших ОС сейчас. Не важно - устарела она или нет, на ней есть пользователи и под нее писать приходится.

Тут вопрос не в желании. Когда у меня попросили бинарник под дебиан, я дал команду как собрать под дебиан софтину. Вопрос в необходимости.

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

Тут вопрос не в желании. Когда у меня попросили бинарник под дебиан, я дал команду как собрать под дебиан софтину. Вопрос в необходимости.

Если бы там был Debian 5, то со сборкой тоже была бы проблема. Причём даже сборка в отдельном каталоге может не спасти: glibc требует ядро не меньше минимальной версии.

Софт развивается слишком быстро и обратной совместимости все меньше.

В мире windows стараются поддерживать. Программы для Win95 (кроме драйверов) устанавливаются и работают на Windows 11. В Linux всё хуже, там почти под каждую версию дистрибутива надо пересобирать. Ещё хуже в Haskell, там не всегда удаётся даже собрать непротиворечивый набор библиотек для сборки.

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

Если нативный гуй не нужен, то все просто - докер.

Так там в зависимостях всё равно дистрибутив ставить. Или, типа, если кому в арче надо, пусть в докере дебиан поставят и из него запускают?

Докер запустят и все. Ну с сабжем это не прокатит, ему гуй нужен.

ему гуй нужен

Его тоже можно в докер: https://habr.com/ru/companies/stc_spb/articles/657927/

Кстати, а как в линуксе почистить /etc и /home/*/.config после удаления программы?

Из /etc обычно удаляется и так, если --purge применил.

В Clear Linux был еще разделен /etc на «пользовательский» и умолчательный, не помню названия папок, но логика простая, /etc.user/ перекрывает как бы /etc/, и тебе не надо гадать, какой файл в /etc был поставлен вместе с пакетом, а какой изменил ты.

Про /home/ ничего не знаю, подозреваю что никак.

В deb можно поставить две версии libstdc++ (например, от gcc-14 и gcc-10)?

В Debian по моему только один компилятор идет в комплекте, в Ubuntu в репозитории по умолчанию есть несколько компиляторов и сопутствующих пакетов к ним, их можно установить одновременно.

Или под автоматизацией подразумевается это: Игра «Бездна света» на свободном движке INSTEAD (комментарий)?

Debian при пакетировании пишет если ты не указал .so зависимость к программе, о том что нельзя разрешить ссылки.

Установка и в Windows и в Linux имеет недостатки, не считаю что какое либо из них вершина инженерной мысли.

Из /etc обычно удаляется и так, если –purge применил.

Ну да. Из реестра Windows тоже обычно удаляется. А потом приходится придумывать чистильщики.

Вот ставил когда-то fpc на Debian, теперь

ls /etc/fp*
/etc/fp-3.2.2.bak  /etc/fp-3.2.2.cfg  /etc/fpc-3.2.2.bak  /etc/fpc-3.2.2.cfg

/etc/fpc-3.2.2.cfg.d:
hardening

Про /home/ ничего не знаю, подозреваю что никак.

Значит если вдруг Linux станет популярным, придётся изобретать такие же чистильщики. Потому что /etc = системная ветка реестра, а /home/.config = пользовательская ветка.

В Debian по моему только один компилятор идет в комплекте, в Ubuntu в репозитории по умолчанию есть несколько компиляторов и сопутствующих пакетов к ним, их можно установить одновременно.

Что-то в Ubuntu тоже не вижу как поставить старую libstdc++. Там только для кросскомпиляции. Но их установленные программы использовать не могут.

Там, где в Windows достаточно поставить MSVC++ xx redist, в Linux приходится распаковывать вручную и делать LD_PRELOAD.

Debian при пакетировании пишет если ты не указал .so зависимость к программе, о том что нельзя разрешить ссылки.

$ find test
test
test/test-cpp
test/DEBIAN
test/DEBIAN/control

$ cat test/DEBIAN/control
Package: test
Maintainer: Test
Architecture: amd64
Description: test
Version: 1.0

$ ldd test/test-cpp
        linux-vdso.so.1 (0x00007f5e3d515000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5e3d200000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5e3d00a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5e3cf1a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5e3d517000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5e3d4c1000)

$ dpkg -b test
dpkg-deb: сборка пакета «test» в «test.deb».

Ничего не написал. А получатель будет искать нужную версию MSVC redist libstdc++.

Установка и в Windows и в Linux имеет недостатки, не считаю что какое либо из них вершина инженерной мысли.

Подход разный. В Windows ОС это только Windows. То есть установка в ней минимально зависит от реализации ОС, а интерфейс стараются поддерживать стабильным. От ОС зависят только драйвера.

В Linux ОС - это весь дистрибутив, включая графические библиотеки, СУБД и версии языков программирования. Поэтому если что-то зависит от компонента этого дистрибутива, то приходится делать отдельные версии программы для всех поддерживаемых версий этого дистрибутива. И, соответственно, почти нерешаемая проблема, если одна программа требует одну версию компонента, а другая другую.

Ну да. Из реестра Windows тоже обычно удаляется. А потом приходится придумывать чистильщики.

Повторю, я не писал что в линуксе идеальное решение. Я писал что в Windows решение тоже довольно убогое. Про проблемы в линуксе я конечно знаю.

Что-то в Ubuntu тоже не вижу как поставить старую libstdc++.

Просто поставить пакет? Вот например несколько версий, их больше: https://launchpad.net/ubuntu/noble/ package/libstdc -12-dev
https://launchpad.net/ubuntu/noble/ package/libstdc -14-dev

Там только для кросскомпиляции. Но их установленные программы использовать не могут.

Что то ты не то смотришь.

cat test/DEBIAN/control

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

Установка и в Windows и в Linux имеет недостатки, не считаю что какое либо из них вершина инженерной мысли.

Подход разный. В Windows ОС это только Windows. То есть установка в ней минимально зависит от реализации ОС, а интерфейс стараются поддерживать стабильным. От ОС зависят только драйвера.

То что подход разный, не отменяет того что в двух случаях он не идеально реализован.

Ну а вообще в Linux тоже ставят сторонние программы и драйвера, в Slackware например не особо большой базовый репозиторий, но на стороннем SlackBuilds.org можно найти что угодно. Просто нету стабильного ABI, WinSxS, кроме Wine.

В винде есть Windows SDK. Его можно поставить на любую винду и собрать свой софт под любую другую винду. Т.е. SDK это по сути кросскомпилятор. Который несёт с собой много версий одних и тех же библиотек: vcrt, mdac, и т.д. И это очень круто: и возможность ставить на любую винду, и возможность таргетить любую винду.

В линуксе же нет The Linux SDK. Каждый дистрибутив несёт с собой компиляторы и библиотеки для одной единственной версии дистрибутива. Это давняя Unix традиция host компилятора, когда каждая Unix машина была уникальна, и весь софт для неё собирался бородатым вытираном на ней же. Но в современном мире такой подход отстоен.

Пока у линукса не будет такого же SDK как у винды, вендоры софта не будут собирать софт для линукса.

Но Линукс вендоры похоже не заинтересованы в превращении линукса в платформу. Каждый тянет одеяло на себя.

Просто поставить пакет? Вот например несколько версий, их больше: https://launchpad.net/ubuntu/noble/ package/libstdc -12-dev https://launchpad.net/ubuntu/noble/ package/libstdc -14-dev

Это не redist: This package contains the headers and static library. То есть программы его использовать не могут. Только для статической сборки.

Что то ты не то смотришь.

Там ещё есть с динамическими библиотеками, но с суффиксом cross.

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

dpkg рекомендованный. А если про всякие надстройки, так в Windows тоже библиотеки проверяются и redist прямо в пакет добавляется.

То что подход разный, не отменяет того что в двух случаях он не идеально реализован.

А что значит «идеально»? Подходы заточены под разные сценарии: в Windows предполагается, что у пользователя много программ не от Микрософта, поэтому надо предоставить удобную возможность ставить такие программы; в Linux предполагается, что пользователь всё ставит из репозитория, а если нужно что-то дополнительное, то либо сотрудник сопровождения дистрибутива (maintainer) эту программу должен добавить, либо пользователь сам должен выполнить его работу по адаптации к нужным версиям библиотек.

в Slackware например не особо большой базовый репозиторий, но на стороннем SlackBuilds.org можно найти что угодно

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

Пока у линукса не будет такого же SDK как у винды, вендоры софта не будут собирать софт для линукса.

Если брать не линукс вообще, то сборка под RHEL или Астру не слишком отличается от сборки под Windows. Всё равно надо указать, с какими версиями программа совместима, и протестировать для всех заявленных версий.

В линуксе же нет The Linux SDK.

Вместо него есть docker.

Это не redist: This package contains the headers and static library. То есть программы его использовать не могут. Только для статической сборки.

Да, действительно.

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

dpkg рекомендованный. А если про всякие надстройки ...

Не знаю какие там надстройки в Windows, видимо редкие и сторонние, а в Debian если следовать инструкции по опакечиванию своей первой программы, то не пропустишь никакие .so, если они конечно определяются через ldd у приложения, а не подключаются динамически. Разве кто то пакетит через dpkg? Я думал хелперы это рекомендуемый вариант + в репозитории же как то проверяются зависимости от .so.

А что значит «идеально»?

Когда без проблем выполняются основые функции, не требуются подпорки к процессу типа CCleaner.

Подходы заточены под разные сценарии

PPA как то выбивается из этого, Flatpak, Snap тоже.

Когда без проблем выполняются основые функции, не требуются подпорки к процессу типа CCleaner.

Так это от программы зависит. Если она при первом запуске вносит дюжину ключей в реестр или файлов в /etc, как их пакетный менеджер должен ловить? Либо автор программы напишет правильный uninstall, либо кто-то напишет CCleaner, который будет чистить за всеми, про кого знает.

Не знаю какие там надстройки в Windows, видимо редкие и сторонние

Самые, что ни на есть, штатные: https://wladm.narod.ru/C_Sharp/setup_win.html

Когда-то для Win95 были сторонние.

И что делать, если программа на Java? Есть аналог install4j? Или если на Mono, вытащит зависимости?

PPA как то выбивается из этого, Flatpak, Snap тоже.

PPA — это расширение ОС. Вот Flatpak и Snap это попытка в мир Linux принести подход Windows.

Если она при первом запуске вносит дюжину ключей в реестр или файлов в /etc, как их пакетный менеджер должен ловить?

Да много вариантов, например складыватьв /real-etc/%programname%/*. Начиная с Vista и так уже есть виртуализация реестра.

Самые, что ни на есть, штатные: https://wladm.narod.ru/C_Sharp/setup_win.html

Не увидел тут про автодобавление зависимостей.

И что делать, если программа на Java? Есть аналог install4j? Или если на Mono, вытащит зависимости?

В Snap неплохо сделано, если ты чего то не добавил, то оно и не запустится.

Не увидел тут про автодобавление зависимостей.

Рис. 15, справа Detected Dependencies.

В Snap неплохо сделано, если ты чего то не добавил, то оно и не запустится.

Только, я так понимаю, общих библиотек в нём не бывает. Эдакое объединение недостатков статической и динамической линковки.

Да много вариантов, например складыватьв /real-etc/%programname%/*.

Это опять вариация докера. И опять, что делать, если к одним и тем же настройкам должны иметь доступ сама программа и webmin/ansible.

То есть, можно, конечно, каждому бинарнику дать своё пространство имён, а взаимодействие обеспечить исключительно через службы. Но это уже совсем не UNIX.

Вот было же хорошо. Когда имя динамической библиотеки гарантировало стабильность интерфейса (и моя программа имела бы в зависимостях не libc6 (>= 2.38), libstdc++6 (>= 13.1), а libstdc++.so.6, libc.so.6, libm.so.6, libgcc_s.so.1). Когда никто не заморачивался, что в реестре/etc после удаления программы остались какие-то настройки, которые никто не использует и которые съели целых 100КБ места на диске. Когда любая библиотека позволяла использовать её статически и без общесистемных настроек.

А потом пришли улучшатели… Прибили версии гвоздями друг к другу, графическую среду к системе инициализации, а систему инициализации к версии ядра. Тогда бы уж не стояли в раскоряку, а шли до конца по пути Embox, где вся ОС прибита к приложению.

Только, я так понимаю, общих библиотек в нём не бывает. Эдакое объединение недостатков статической и динамической линковки.

Бывают, например core22.

То есть, можно, конечно, каждому бинарнику дать своё пространство имён, а взаимодействие обеспечить исключительно через службы. Но это уже совсем не UNIX.

Уже и сейчас полно непонятных служб.

Вот было же хорошо. Когда имя динамической библиотеки гарантировало стабильность интерфейса.

Тогда даже если есть совместимость по символам, приложение не запустится. Два пакета в Debian никто делать не будет, и не даст нормально поставить. Все плюсы этого подхода можно повторить сейчас, сделав /usr/lib64/libc6.13.1/libc.so + LD_LIBRARY_PATH

Гы, по теме тут наткнулся:

>    required services

Kameleon?

That is pushing the bounds of “required”.

Do I really need to explain why this response isn’t necessary, it’s hurtful to the contributor of the feature, and it’s just plain unproductive? Either way, the discussion here is complete and specifics can be discussed in other threads.

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