Почему дистрибутивы всё ещё считают нормальным иметь «версии»? Типа там Debian 8, 9, 10, 11? Почему это не просто Debian сквозной?

Например, захотел выпилить старые методы - идёшь нахрен - так нельзя.

Куда в твой автомобиль сено пихать? И как часто нужно шины перековывать?

Потому что не софт для ОС а ОС для софта. Если в какой-то ОС не работает какая-то программа (которая работает в других) - то это проблема ОС, а не программы.

Это проблема ОС, да. Но т.к. линуксовый мир - это не обязательно корпоративный (где билл гейтс может загнать кнутом тыщу разрабов пилить костыли, которые позволяли бы запускать старый софт), а мир, движимый во многом энтузиастами, то ЭТО ДРУГОЕ.

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

Смотря что называть «проблемами ОС». Для меня проблема дебиана - что мне нужно знать какая у него версия и париться-обновлять, если поддержка закончилась. Я бы предпочёл, чтобы этой проблемы не было и мой подход эту проблему убирает - я в 2020 ставлю такой дистрибутив и в 2040 он всё ещё актуален.

Для стабильности. Не всем нужны глюкодромы Full Rolling Release'ов.

Так не катите либу, пока на неё так же не будет поставлена печать «стабильно». В этом «моём дистре» у тебя такой же выбор: катить только стабильное или катить свежее. Свежее просто чуть свежее стабильного, но история так же линейна.

Я не против. Предложи такое авторам GTK и Qt, например. :)

И подобное длительное время практиковали в Windows, кстати. Поэтому там в API много функций с суффиксом Ex :). См. также древнюю статью Спольски «Как Microsoft проиграла битву за API» (русский перевод, например, здесь), особенно про «лагерь Реймонда Чена», который как раз и боролся за обратную совместимость и по мнению Спольски в итоге проиграл. (Помимо прочего, статья даёт ключ к пониманию, почему веб-разработка, от которой все плюются, вытесняет всех и вся — за годы, прошедшие с момента её написания, тенденция стала ещё более очевидной.)

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

я в 2020 ставлю такой дистрибутив и в 2040 он всё ещё актуален.

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

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

Ты только что изобрёл Яву
Поздравляю

Это проблема ОС, да. Но т.к. линуксовый мир - это не обязательно корпоративный (где билл гейтс может загнать кнутом тыщу разрабов пилить костыли, которые позволяли бы запускать старый софт), а мир, движимый во многом энтузиастами, то ЭТО ДРУГОЕ.

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

Скажи это Яве 6, 8, 11 и 17, или какие там сейчас актуальные.

Ну так под 17 работает написанное под 6 - в этом и цимус.
Я до сих пор на 8 пишу, притом с 6 перешёл в прошлом году.

В том и суть что нет, не работает. Под каждый софт своя версия Явы.

В том и суть что нет, не работает. Под каждый софт своя версия Явы.

Лолшто? Пользуюсь софтиной, которая работает в 8, 11, 17 и 18 (потому что на разных машинах установлены разные версии OpenJDK/ Oracle JDK).

Лолшто?

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

Другая софтина требует обязательно версии старше 11й, но это хотябы логично.

Потому что это отсталые ретрограды. В NixOS + flakes можно указать из какого коммита у нас система. Вот тебе и версия.

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

Это говорит только о квалификации программистов, писавших эту софтину, а не о языке в целом.

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

Ставь рачь и не долби людям мозги

Почему дистрибутивы всё ещё считают нормальным иметь «версии»? Типа там Debian 8, 9, 10, 11?

Есть дистрибутивы с моделью rolling release. Например, Arch Linux.

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

что за софтина и что за ошибки?
гвоздями к 8 прибито обычно то что требовало либо sun.* либо fx под арм, притом даже не просто 8 а 8 до емнип .65 но это не ява, это сторонние модули

Другая софтина требует обязательно версии старше 11й, но это хотябы логично.

все ява софтины требуют версию равную или старше той, на версии языка которой они написаны т.е. если разраб писал «на 11» то софтина работает на 11+.

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

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

А почему не декларировать инновационный подход к разработке библиотек, если ты не соблюдаешь который, то ты псина и тебе не место в мире нормальных дистрибутивов

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

если разраб писал «на 11» то софтина работает на 11+.

Таки не всегда

https://docs.oracle.com/en/java/javase/17/migrate/removed-apis.html

будет бардак с кучей функций формата functionA_v1 functionA_v2 functionA_v3 :)
которые никто не захочет поддерживать и их один херъ когданибудь придется вычищать.

Маркетинг. Постоянное новое хуже распространяется, чем дискретность с ожиданием

--add-opens ... ALL-UNNAMED

такие дистры уже есть

Конечно есть. NixOS.

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

+100500, в этом и причина.

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

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

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

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

Захотел навернуть офигенно новый функционал, который конфликтует со старыми версиями - пилишь новую либу с новым именем, старую не трогаешь.

Так всё так и есть. Номер в имени либы обеспечивает его уникальность.

Никто не выкидывает API из sobaka-1.0.42. Пишут новую библиотеку sobaka-2.0.13.

И номер версии в дистрибутиве имеет ту же функцию. Debian-11 и Debian-6 – это разные ОС. С разными наборами системных библиотек, местами даже с разными подходами к написанию конфигурационных файлов.

А «Debian сквозной» это усложняет. Либо в нём надо хранить все библиотеки, которые хоть раз установлены (в частности все промежуточные версии glibc, X и gtk), либо в любой день может что-то внезапно сломаться при очередном обновлении. Переход на новый формат конфигурационных файлов в такой системе вообще почти невозможен, то есть добавить новый формат можно, но запретить старый нельзя.

sobaka

псина

trisobakov

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

Все инновации происходят в unstable версии и из меня не делают подопытного бесконечными автообновлениями.

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

То что ты хочешь это зло. :) Андроид качает обновления пока не сожрет всю память телефона. Винда тоже самое дерьмо. Теперь это говнище лезет и в линукс.

Гораздо более проблематично, что юзвери, не будучи увязаными к проприетарному софту с привязкой к редгаду 4.20, всё равно норовят поставить ЛТС пойнт-релиз вместо единственно-разумного роллинга, и сидеть на нём до усрачки.

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

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

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

Но если надо - это должно быть можно делать.

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

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

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

все ява софтины требуют версию равную или старше той, на версии языка которой они написаны т.е. если разраб писал «на 11» то софтина работает на 11+.

скажи это игрокам майнкрафта

Это какие?

То что ты хочешь это зло.

Автообновления - это однозначно зло.

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

А если профессор лопух, но аппаратура при нем - то приходится принудительно наносить добро.

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

Пора уже резать библиотеки на этапе сборки. Программа А хочет 7 функций из библиотеки Б которые хотят вниз по дереву зависимостей ещё 30 функций. На этапе сборки вычисляются адреса функций и их зависимости типа BSS данных и прочего всё это вырезается из библиотек сливается в один блобик и линкуется с программой ститически/динамически. Так будет создан компромисс между чистым разделением кода на библиотеки и проблемой версий одной и той же библиотеки. Вместо того что-бы тянуть с собой две версии по гигу можно будет тянуть основную версию на гиг + программу с вырезанными для неё функциями из старой (и её зависимостей) на пару килобайт.

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

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

Получится ХРЕНЛИОН микролиб, зато это на корню фундаментально решает любые проблемы с зависимостями, так как они будут от конкретных реализаций конкретных функций, а не от целых библиотек.

Может бред, а может нет.

Но если надо - это должно быть можно делать.

Это можно сделать на любом дистрибутиве. Snap и AppImage в помощь.

Поставить чужую библиотеку как системную сложно из-за конфликта имён. Например, sobaka имеет настроечный файл в /etc и разные версии требуют разный формат. Поэтому системная идёт в /usr/lib /etc /share, а дополнительные отдельно.

Но это не значит что вообще все приложения, каждое первое, должно иметь свои особенные версии библиотек.

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

Это можно сделать на любом дистрибутиве. Snap и AppImage в помощь.

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

То есть неизбежно тогда будет стоять какой-нибудь apt, плюс к нему snap, вручную appimage накидано, и flatpak потому что я так вижу. Все это не знает друг о друге, обновляется отдельно по разным законам, управляется совершенно разными командами.

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

Поставить чужую библиотеку как системную сложно из-за конфликта имён. Например, sobaka имеет настроечный файл в /etc

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

Кому надо особые тащит за собой.

Именно так, но желательно это делать средствами системного ПМ, а не как попало.

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

Ты же сам написал, что левые библиотеки только в исключительных случаях.

Не надо путать. Библиотеки не имеют настроечных файлов в /etc, их имеют сервисы либо приложения.

GTK и Qt имеют. Технически, конечно, приложения, их использующие, но, тем не менее, привязка жёсткая. Ещё и привязка к сервисам может быть. Например, старая программа использует старый Gtk, а в дистрибутиве заменили X на Wayland. Всё, старая программа не работает.

Именно так, но желательно это делать средствами системного ПМ, а не как попало.

Тогда Вам любой дистрибутив со слотами: Nix, Gentoo, …

Программа А хочет 7 функций из библиотеки Б которые хотят вниз по дереву зависимостей ещё 30 функций. На этапе сборки вычисляются адреса функций и их зависимости типа BSS данных и прочего всё это вырезается из библиотек сливается в один блобик и линкуется с программой ститически/динамически. Так будет создан компромисс между чистым разделением кода на библиотеки и проблемой версий одной и той же библиотеки.

Это и есть статическая линковка. Но Glibc так не умеет.

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

При статическо линковке неиспользуемые функции выкидываются.

Ты же сам написал, что левые библиотеки только в исключительных случаях.

Да. И что? Какой вывод?

GTK и Qt имеют.

И что они там в /etc имеют?

Например, старая программа использует старый Gtk, а в дистрибутиве заменили X на Wayland

А можно не высасывать какие-то странные неправильные примеры из пальца, типа вот этого, а привести нормальные примеры?

Старое GTK приложение будет работать через XWayland и никуда оно не денется. Старое pulseaudio приложение будет работать через pipewire, ну и так далее.

Тогда Вам любой дистрибутив со слотами: Nix, Gentoo, …

Об этом и речь - я имею в виду, что такие дистрибутивы лучше.

Автообновления - это однозначно зло.

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

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

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

АВТО ОБНОВЛЕНИЕ

Причем тут релиз? Я совершенно ничего не писал про релиз - нужен он или нет. Я писал про то, что обновления я хочу запускать сам, когда мне надо. А не АВТО.

И что это вообще за АВТО обновление на следующий релиз дистрибутива? Я такого в жизни не видел, даже на винде.

А без релиза ты сам обновляешь glibc

Я где-то писал что релизы не нужны? К чему это?

АВТО - имеется в виду, что оно запускается само, в фоне.

все ява софтины требуют версию равную или старше той, на версии языка которой они написаны т.е. если разраб писал «на 11» то софтина работает на 11+.

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

Хотя конечно мне встречался жавасофт, который работает нормально вне зависимости от версии.

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

Да это может породить ещё больше проблем что есть сейчас, я как то про это даже пока не думал. Но чисто как шиза идея чёбынет