Все же с библиотеками и зависимостями Linux куда-то не туда идет

Поставил, обновил всё до sid — всё работает. Так что похоже на проблемы конкретно Arch. Как можно было xlib сломать, ума не приложу.

Последняя версия 1.32

Мдааа. На винде все старое ПО работает. Ну т.е. не все ПО, а только определенных версий. А ну да, иногда разрешение будет только 800×600, ну пофиг, ведь запускается. Ах да, еще иногда нужно реестр подправить. Но все равно, в линуксах вообще все плохо.

В Quake 1.32 есть список того что они поправили в 1.32. Возможно если поразбираться, то можно найти причину почему 1.32 работает на Windows 10, а 1.31 нет. Хотя возможно 1.31 тоже работает на Windows 10, а не работает именно на отдельном компьютере с Windows 10.

В 1.32 есть вот такие строки про Linux:

- no longer trying to load libMesaVoodooGL.so
  obsolete code, was confusing when trying to setup correct OpenGL acceleration
- changed default GL driver from libGL.so to libGL.so.1

Возможно 1.31 не работает и под современным Linux, а не только на Windows 10

Я выбрал первый попавшийся софт.

Кстати, есть один курьёзный случай. Самый крупный производитель ПЛИС отказался в новой версии своего ПО поддерживать «устаревшие» модели (на самом деле в этой индустрии они так быстро не устаревают). В итоге, последняя версия ISE Design Suite 14.7 2013-го года по-прежнему работает в современном Debian testing. А под винду новее 7-ки - нет. И какое решение выбрал производитель? Наконец-то добавить поддержку в новое ПО? Нет. А выбрал он засунуть ISE в виртуалку и предлагает к загрузке образ для VitualBox. И без того жирный инсталлятор увеличился ещё раза в 2. А что же там за гостевая ОС в виртуалке? Ну, 7-ка, наверняка? Нет. Там Red Hat :)

P.S. Тем временем, есть уже кое-какие уловки чтобы с теми или иными ограничениями запустить ISE нативно под 10-ой, которые, правда, после очередного обновления винды перестают работать, и надо искать новые.

Хотя возможно 1.31 тоже работает на Windows 10, а не работает именно на отдельном компьютере с Windows 10.

Ты в курсе, что этот прекрасный прием можно применить где угодно? Возможно курение вовсе не вредно, а только в случае определенного человека. Возможно Дом Дракона не тупой сериал, а только в случае отдельно взятой серии (или двух, или трех…).

мне тут писали что GTA 3 не работает на Windows 10, я показал что работает, нужно просто установить Direct Play(в новых версиях он не устанавливается вместе с системой, а раньше в XP шел вместе с системой)

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

Или будет уже статистика, что у двух человек не работает эта версия.

Мдааа. На винде все старое ПО работает. Ну т.е. не все ПО, а только определенных версий. А ну да, иногда разрешение будет только 800×600, ну пофиг, ведь запускается. Ах да, еще иногда нужно реестр подправить. Но все равно, в линуксах вообще все плохо.

На Windows возможно написать приложения, которые будут работать на всех Windows с Windows 95 до Windows 11. Есть примеры таких приложений.

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

А если на винде что-то там нужно доустановить, чтобы старое приложение работало, это не равносильно тому, что в линуксе тоже что-то нужно доустановить?

На Windows возможно написать приложения, которые будут работать на всех Windows с Windows 95 до Windows 11.

Судя по примерам выше, на линукс тоже.

Судя по примерам выше, на линукс тоже

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

В Windows разработчик использует системное API и SDK.
За наличие остальных dll и своих он отвечает сам.
И это правильно.

Особо нет, но соображения такие:
1. Полезно иметь возможность кастомизации установочного гуя, чтобы сложные пакеты могли спрашивать у одмина данные для предварительной настройки;
2. если ПМ умеет в кастомный гуй, то возможность сделать его вырвиглазным и попугайским надо как-то умышленно ограничивать. А зачем? Ну хочет, например, автор инди-игрухи сделать КРАСИВО - пускай.

А еще говорят, что иксы не развиваются!

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

Как оно будет с .deb сочетаться?

А какие тут могут быть проблемы?

Я собирал deb пакеты. А какая там проблема?

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

Хороший разработчик не будет полагаться на ментеймеров, …

Ну так распростроняй в виде каталога со всеми либами. Или deb/rpm пакета, который нужно скачать с твоего сайта.

Я собирал deb пакеты через dpkg-deb и через встроенный функционал cmake (вполне удобно). В обоих случаях проблем не было.

Ты можешь написать, что конкретно у тебя не получалось?

Точно не могу сказать насчет перехода Qt4->Qt5, но у Qt4 с Qt3 обратной совместимости нет, там сами классы другие.

Linux не для слабых духом.

А вот и «Linux is for technical users» - самая мерзкая отговорка.

Сейчас в Debian вообще нет в репах Qt4.

Долбанутые люди.

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

Ну а чё, автору (авторам) же делать нефиг как переписывать на новый тулкит.

Я пишу сайт на React.js, так вот в этом React поменяли классовые компоненты на хуки. Т.е. сайтоделам надо переписывать нафиг всё, просто чтобы оно продолжало работать и оставалось новомодным. А потом другой фрейворк придумывают и опять переписывать. За такое обычно ругают веб, а оно оказывается и в настоящем программировании под онтопик есть.

Казалось бы вот что мешало сохранять в репах Qt4 и другие депрекатнутые либы для старого софта?

В статье https://ludocode.com/blog/flatpak-is-not-the-future

предлагается просто поддерживать GTK3 всегда.

The ongoing transition to GTK 4 gives us an opportunity here. The GTK 3 ABI is finally a stable target, and it’s still pre-installed in most distributions because lots of built-in apps haven’t upgraded yet. If we can get a sufficient number of binary apps depending on it, distributions will be forced to maintain it and even pre-install it “forever”, the same way Microsoft maintains the Win32 API “forever”.

irton пишет:

В Роса все еще в репе есть, в новую платформу переехал тоже.

Да и в Alt Qt3 до сих пор поддерживается, за что без дураков респект российским опакечивателям!

Im_not_a_robot, ответ на Все же с библиотеками и зависимостями Linux куда-то не туда идет (комментарий) :

И после этого говорят, что deb-based - это user-friendly.

Там же я прочитал, что flatpak, который обычно предлагают как альтернативу - та еще гадость. В нем приложения тащат с собой не только нужные им либы. Идиотизм доходит до того, что они Мезу с собой тащат. Библиотеки связанные с железом могут отличаться в зависимости от конфига компа и предпочтений пользователя.

Торвальдс все сказал по делу. Меня вообще интересует, что было бы, если бы он не связался с гнушниками, и руководил бы разработкой всей ОС, а не только ядра?

Вот еще очень по теме Устанавливать программы вместе с зависимостями, не портя стиль

Для маздая же собирают бинарники. И для нашей ОС могли бы. Тут даже проще - не надо писать свой установщик для каждого приложения, нужен просто стандартный формат для упаковки бинарников. И он даже есть - AppImage. Тут проблема чисто человеческая.

Ну раз ты не против некрофилии, поставь stretch. А ежели против - не жалуйся, что за двойные стандарты?

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

Если топишь за «свалить всё в кучу вместе с зависимостями» - ну так используй snap. А если за обратное - то зачем жаловаться?

Snap - это такая же гадость, как flatpak, только еще и вендорлочная. Выше объяснил, почему это не решение, а неудачная попытка решения.

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

Чушь. Вы, наверное, застряли во временах старого debhelper, где каждый шаг нужно было в debian/rules прописывать.

Точно не могу сказать насчет перехода Qt4->Qt5, но у Qt4 с Qt3 обратной совместимости нет, там сами классы другие.

Да. А у 4 и 5 есть. И у 5 и 6 есть. В обоих случаях изменения довольно минимальны и куча кода работает если просто версию библиотеки в сборочных скриптах поменять.

А что толку ее сохранять? Если бинарник слинкован с libqt3.so он этот файл и будет требовать.

Это везде так. Не только в линуксе. Должен быть толковый менеджер с большой палкой, который бы не давал программистам всё превращать в хаос. В этом смысле у Microsoft всё относительно хорошо. У джавистов вроде бы было неплохо до последнего времени. Остальным почему-то неважна долговечность не только программ и библиотек, но даже исходного кода.

Что касается линукса, это проблемы не только в старом ПО. Взять ту же Астру. Вроде бы на Дебиане основана. Но библиотеки устаревшие, поэтому программы с современных Дебиана или Убунты просто так не перенесёшь.

На счёт Delphi ещё скажу. Не знаю, как сама IDE, но программы, созданные на Delphi 3 (а не 6 или 7), спокойно работают в десятке.

Ещё тут про .Net Core говорили. Оно хотя и от Microsoft, но в Линуксе его как-то боязно использовать. Сырое. Mono чуть менее страшно, оно хоть проверено временем. Ну и с GUI там получше. Тут про Avalonia UI говорили. Выглядит красиво, но при её использовании будет больше зависимостей от кода разных корпораций (не только от MS, но и от Google), чем при использовании Windows.Forms, например.

Ну так распростроняй в виде каталога со всеми либами. Или deb/rpm пакета, который нужно скачать с твоего сайта.

В Windows много программ, которые (к примеру) при инсталяции устанавливают Python требуемой версии.
И они правы (хотя конечно лучше сначала проверить наличие/отсутствие репозиториев и.т.д.).

Только поэтому всё это счастье работает

У меня с приложениями из реп больше проблем, чем со стронними

работает безопасно

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

Чсх надо понимать что неподдерживаемое становится таковым только если оно НИКОМУ НЕ НУЖНО. Иначе тот кому оно нужно берётся за его поддержку. Если вам вдруг понадобилось то что никому больше не нужно, весьма вероятно что вы что-то делаете не так - например, не пользуетесь актуальным аналогом на который все ушли.

Вот из-за таких вредителей у нас нет и никогда не будет хоть сколько-нибудь специализированного софта. Нас мало того что 1%, так его ещё и размазали тонким слоем по дистрибутивам.

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

Мейтейнеры - это ненужная прослойка. Они не вникают, какие версии пакетов стабильные и выбирают версию для дистра от балды. Пруфов этого полно. В исходниках баг исправлен, в репах он остаётся навсегда.

Так эти вахтеры ещё и не опакечивают половину нужного софта. В Ubuntu нет Atom, Pale moon и OBS. А ведь это самые попсовые проги, известные даже каждому приличному виндузоиду. А потом, когда на форуме упоминаешь, что поставил PPA или из исходников, мерзкие зануды поднимают вой, что это не официально и ни в коем случае нельзя делать.

Единственное нормальное что есть - это AppImage. У него есть только 2 недостатка.

1. В нём нельзя сделать, чтобы все приложения выглядели согласно настройкам персонализации системы (или можно?).
2. Разработчики мало в нём выпускают софта.

Надо, чтобы дистростроители поддерживали только самое системное: ядра, реализацию OpenGL, программы в составе DE. А все остальное чтобы распространялось в AppImage. Где грань - спорный вопрос. Но Mesa точно в систему, а libcurl точно с приложениями. Кому-то может не нравиться, что AppImage хранится в сжатой ФС и монтируется при запуске, но ведь это просто формат файла, и технически его можно распаковывать при установке.

У меня есть идея создать пакетный менеджер здорового человека. Устанавливает программы из AppImage, распаковывает их в /opt/data/app, создавая папку для каждой программы, в которую кладет сам AppImage и бинарники, библиотеки и ресурсы из него. Настройки программ хранит либо в /opt/data/data, либо в ~, это поведение можно настроить для каждой программы.

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

Остаётся только принять волевое решение и убедить разработчиков собирать свой софт в AppImage. Ну и решить проблему с look and feel.

DrBrown пишет:

Проще написать на божественной Java и запускать и на маке и на винде и на любимом линуксе.

А кстати почему на ней так мало десктопно-лэптопных приложений? Они же такие удобые: один файл - одна программа, просто кладешь куда угодно .jar и открываешь его джавой.

vbcnthfkmnth123 пишет:

Ага и затем хранить по отдельной Java для каждого проекта. Потому что это написано на Java 2, другое на Java 5, третье на Java 8, четвертое на Java 17.

Питона же храним несколько версий и ничего.

Ну а чё, автору (авторам) же делать нефиг как переписывать на новый тулкит.

Не хочет переписывать, значит идёт лесом. Всё правильно.

Ну пистон до 19-ой версии ещё не добрался.

за AppImage будущее!

А scantailor-advanced это не тоже самое?

Может проще распростронять тарболы.

Ну а чё, автору (авторам) же делать нефиг как переписывать на новый тулкит.

Этому автору вообще пофигу. Он не принимает пулреквесты, не добавил к проекту желающих его продолжать. Ему просто пофигу.

В Windows такой проблемы с прикладными программами за редким исключением просто нет.

Как и вообще Snap. Это отдельный прикол и не всем нравится такая снапизация. К тому же появляется риск установки неведомо чего неведомо откуда.

Так ты определись? Дистрибутивы Linux - это набор библиотек и ПО. Всё что внутри связанно, обновляется и работает. Нужно что-то за пределами этого набора:

• положи в /opt
• Snap, Flatpack, AppImage
• Nix

Автору ScanTailor давно предложили упаковать его проект в AppImage, если он не хочет дальше развивать систему. И даже всё подготовили для него. А он болт положил.

Он даже под Винду не собрал и не выложил последние релизы. Всё что предоставил – это исходники.

То что ScanTailor был доступен в дистрибутивах – заслуга не автора. Считай просто дополнительный бонус.

В принципе, нашел форк ScanTailor advanced в Snap

• Snap –> https://github.com/4lex4/scantailor-advanced
• Nix –> https://github.com/vigri/scantailor-advanced

Не был бы автор мудаком, не было бы такого количества форков (300 шт. уже).

P.S. А ведь Qt - это казалось бы для переносимости. Причем Qt - как бы изначально линуксовый тулкит. Итог - «переносимая» программа на линуксовом тулките через несколько лет продолжает нормально работать в Windows и не запускается в Linux без переписывания и всяких Snap.

Тут как-то путаются понятия работает и распространяется.

Ну так сделал бы кто архив со всеми зависимостями для установки в /opt ты бы им пользовался?

Всякий коммерческий софт и с более древними зависимостями нормально работает в современных Linux. Там так же как и в Винде «всё своё ношу с собой».

https://github.com/vigri/scantailor-libs-build

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

У меня с приложениями из реп больше проблем, чем со стронними

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

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

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

Короч ты преизобрёл флатпак но без изоляции и требующий стандартизации линуксовых дистров (чего пока не предвидится).

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

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

В реальности «приложения» используют пачку зависимостей, в каждой из которых постоянно находят дыры. (Пример: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libpng)

И централизованное управление этими зависимостями позволяет хоть как-то уменьшить влияние на безопасность.

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

В реальности мне постоянно нужны программы которых ещё нет в ubuntu и которых уже нет в ubuntu.

И в чём проблема? Каких-то 20 лет назад народ всё ручками собирал. А ОС была совсем минимальной.

Теперь что? разбаловались? «Flatpack/snap/AppImage не хочу, дайте всё и сразу!!!», «Собирать ручками не умею!!!»

То что «базовый состав ОС» сейчас содержит достаточно зависимостей для 100500 пакетов, ещё не значит что все приложения в ней должны быть из коробки. Нужно приложение которое требует зависимости не содержащиеся в стандартном наборе, собирай это приложение со всеми зависимостями и запускай. Лень/немогу – тогда Snap и т.п.

В HPC на суперкомпьютерах стоит древнее овно мамонта в качестве ОС, но при этом используют последние версии ПО (с.м. https://spack.io/ https://easybuild.io/)

Можно и тарболы принять за эталонный формат, но тогда надо, чтобы в корне тарбола лежал симлинк на главный исполняемый файл, и крайне желательно .desktop, по которому пакетный менеджер смог бы создать пункт в главном меню. Мне и самому больше понравились бы какие-то архивы, но спецификация AppImage уже существует и ей даже кто-то следует, остается только убедить всех остальных ей следовать. А создать спецификацию с нуля, которой не следует никто - почти невыполнимая задача. Меня на это вдохновили .apk, если кто не понял.

Даже если предположить что я тебе поверил (нет)

И кто же мне проплатил, интересно? Я ведь могу пруфы принести.

Вот только малая часть:

Как установить линукс, но сложнее (комментарий)

Вдогонку

builddeps:kodi : Зависит: libmodplug-dev но он не будет установлен

KMail - Количество непрочитанных сообщений в папке

NetworkManager-l2tp - использовать DNSы от VPN-сервера

Все эти проблемы возникли с пакетами из официальных репозиториев.

При этом Atom из .deb, QMMP из исходников, Yt-dlp с гитхаба, GIMP из исходников, Jdotxt из .jar, Avidemux из исходников, Pale moon, Textadept, Radeontop из бинарников работают правильно. Я специально не называю проприетарщину.

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

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

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

В том и дело, что я не поставлю то же самое из реп, потому что там его нет.

Кроме того, репозитории модерируются, поэтому в них, во-первых, не может закоммитить хрен с горы,

Если только этого хрена с горы не «рукоположил» кто-то из действующих мейнтейнеров. А при этом может существовать толковый человек, у которого нет знакомого мейнтейнера.

во-вторых, то что он закоммитят сразу кто-то посмотрит.

Судя по топорности багов, которые они пропускают, они даже собранные программы толком не гоняют. Эти вахтеры собрали QMMP, а QMMP plugin pack не положили, без которого эта программа не мыслится.

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

Этого будет недостаточно, кмк. Там нужна целая пачка технических решений вроде переработанной логики хранения файлов в иерархии и всеядного пакетного менеджера.

Если хорошо заморочиться, то можно обеспечить работу даже старого софта на каком-нибудь Qt3.

И в чём проблема? Каких-то 20 лет назад народ всё ручками собирал. А ОС была совсем минимальной.

Теперь что? разбаловались? «Flatpack/snap/AppImage не хочу, дайте всё и сразу!!!», «Собирать ручками не умею!!!»

А потом удивляются, почему у них 1%. Хочу, только по-нормальному реализованное Все же с библиотеками и зависимостями Linux куда-то не туда идет (комментарий). Я умею собирать, но преодоление трудностей ради преодоления трудностей бессмысленно.

То что «базовый состав ОС» сейчас содержит достаточно зависимостей для 100500 пакетов, ещё не значит что все приложения в ней должны быть из коробки.

Я это и утверждаю. Торвальдс и предлагал провести более четкую грань между ОС и не ОС. Все же с библиотеками и зависимостями Linux куда-то не туда идет (комментарий)

переработанной логики хранения файлов в иерархии

Не понял, чего там перерабатывать? /opt/ для того и предназначен. Иерархия внутри каждого приложения может быть любая.

всеядного пакетного менеджера

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

Достаточно, чтобы он ел один стандартный формат пакетов

Которого не существует.

Он существует, это AppImage. https://docs.appimage.org/reference/architecture.html

Никто не считает его стандартным форматом пакетов и немногие выпускают свой софт в этом формате. Поэтому твой подход безнадёжен примерно так же, как и «надо чтоб все дистрибутивы объединились»

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

немногие выпускают свой софт в этом формате.

Вот именно, выпускают. Т.е. стакан на четверть полный.

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

tarболл сорцов, ну