Не хватает создания еще одного Desktop-дистрибутива Linux

Заминусовали скорее всего из стадного инстинкта. Один минусанул, 10 человек увидели заминусованный комментарий. Ну, или такой вариант. В жизни убунтоида есть три стадии: первая «скорее бы вышла новая версия системы, я её в первый же день скачаю и установлю, я прочитаю ChangeLog в новости о релизе, и попробую нововведения!». Вторая «ну вот, опять вышла новая версия, недавно же выходила, что-то они зачастили». Третья «да ну нафиг, буду пользоваться LTS-релизами». Если первой группы в комментах было больше, то заминусила тебя она.

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

Не прав же) вот для таких как ты и есть lts, который выкатывается раз в 2 года. И да, я даже одобряю что раз в 2 года, а не раз в год как до этого было.

Так вот - зачем такие частые релизы. Потому что разработчикам очень сложно редко выпуски делать. Вся мотивация отпадет если будешь раз в 2 года релиз делать..

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

Это издержки модели распространения ПО для Linux, которую установили до Canonical. Canonical только попробовала решить проблему частыми релизами.

Вот был Red Hat 7.3 в 1999 году. Вот был репозиторий Freshmeat, в котором была RPM-ка с любой новой софтиной. Устанавливаешь ты такой систему. Все программы старые. А из Freshmeat ты можешь выборочно обновить софт до последней версии, и новый установить. Базовая система остаётся старая (но с обновлениями безопасности), а прикладное ПО - новое.

Было хорошо. Потом вышел Red Hat 9.0. Он был обратно совместим с Red Hat 7.3 (ты мог установить любую RPM-ку для RH7 в RH9). Но не обратно (бинарник для RH9 не работал в RH7). На Freshmeat выкладывали два RPM-пакета: для RH7 и RH9. Ну, либо только для RH7, потому что в RH9 он тоже будет работать. А выкладывать только для RH9 не нужно, потому что на RH7 сидит довольно много людей (не всем нужен юникод).

И всё было хорошо. И всё было прекрасно. и тут Red Hat говорит «больше не будет Red Hat Linux. Всё. Пользуйтесь мандривами, сусями, дебинами и слакварями. А ред хата не будет». Вы скажете «но ведь взамен Red Hat вышла Fedora». Да, но Fedora была ужасна, на неё никто не перешёл.

Во времена RH7 и RH9, авторы программ компилировали свои программы в RH7 и RH9. Лишь некоторые авторы компилировали в Slackware, потому что там - не патченные библиотеки, ванильные, а значит совместимость со всеми дистрами будет безупречная. А в Мандрейке всё работало, потому что там тоже RPM-пакеты. В SUSE всё работало. Для Debian существовала программа-конвертер alien.

Когда Red Hat предал десктопный Linux, то всё рухнуло. Вот допустим, ты - автор некоего абстрактного ПО, например Gaim (Pidgin). Под какой дистр надо скомпилировать, чтобы работало у всех? Последний релиз RH? Ну можно. В 2005. А в более поздние годы тебе явно будет не хватать нового компилятора. Mandriva? Но остальные дистры не пытаются поддерживать с ней совместимость (сейчас такая же картина с Убунтой). Тогда Fedora? Но там либы СЛИШКОМ новые, и не у всех такие есть. Вот попросит твоя прога какой-нибудь системный выздов из Glib, которого у юзера нет, что будешь делать? Тогда RHEL? Да вы что сдурели, покупать его что ли? (CentOS появился не сразу). Остаётся одно: ен делать сборку для Linux вообще, выкладывая exe для Windows, dmg для Mac OS X, и tar.gz с исходными кодами для Linux.

Потом появился дефолт линукс - убунта. Все начали собирать под Ubuntu 6.06. Это стало новым RH7. Но. Всегда есть но. Ubuntu не является промышленным стандартом, под который подстраиваются все дистры. Скажем, скомпилировать под Ubuntu 6.06 можно, и у всех будет работать. Потому что в марте 2007 года вышла RHEL 5, и набор либ в этих дистрах примерно схож. А если компилировать в Ubuntu 8.04, а потом начать распространять готовые бинарники, то у юзеров могут быть проблемы. То GCC 4.2, а у юзера GCC 4.1, то новая мажорная версия какой-нибудь библиотеки (впрочем, умелый мейнтейнер положит «всё с собой», все нестандартные либы вроде libSDL, libavcodec, которые не обязательно есть у пользователя). Valve с этими граблями столкнулась в полный рост. А будь Red Hat - дефолт линуксом по сей день, то не было бы таких проблем. У нас уже была ситуация, когда Mandrake популярнее Red Hat, но софт всё равно собирают под Red Hat, и он работал в Mandrake. А теперь МОЖНО собирать под CentOS 6, но никто этого не делает, а собирают под Ubuntu даже не LTS-версий. Я думаю, не нужно рассказывать, что будет, если попробовать установить программу, скомпилированную в Ubuntu 15.04. в Ubuntu 19.10. Или если сейчас скомпилировать в 19.10, а потом попробовать запустить в Ubuntu 24.10

> Это издержки модели распространения ПО для Linux, которую установили до Canonical. Canonical только попробовала решить проблему частыми релизами.

Так вот. С чего я начал. Когда Red Hat не стало, а Fedora никому не была нужна, то все пользовались Mandriva, SUSE и Debian. А у них были не частые релизы. Возникла пробелма с обновлением софта (в репо же прилетали только фиксы безопасности, а не новые версии программ). Первые годы на FreshMeat выкладывали бинарники с новым софтом, скомпилированным под RH9, и он работал в Mandriva и SUSE. Потом перестали выкладывать, потому что годы шли, компилятор из RH9 устаревал, а нового Default Linux, с бинарниками для которого каждый дистр будет обеспечивать совместимость, на горизонте не было.

Появился свой FreshMeat для SUSE, это Packman. Что же теперь, под каждый дистр свой FreshMeat «пилить»? А как же «одна RPM-ка для всех дистрибутивов»? А если у тебя не мейнстривовая Mandrake и SUSE, а какой-нибудь Alt Linux? Хрен же кто соберёт для тебя редкую софтину. Большая общая база сборок ПО была бы лучше...

Вот в Ubuntu и были обновления раз в полгода. Необходимости в дополнительных репозиториях не было, потому что в репозитории Universe были сборки вообще всего, даже LADSPA и модулей perl.

Было бы здорово, если бы у тебя старый GIMP, а ты просто устанавливаешь в Ubuntu 18.04 пакет из 19.10. Но это невозможно, так как пакет потребует более нового GTK, а то и вовсе Glibc и Python. Red Hat такое проворачивает для RHEL: можно установить в CentOS 6.0 пакет от CentOS 6.10. Но что-то я не видел в CentOS 6.10 ни новый GIMP, ни новый Audacity, LibreOffice и т.д.

Кстати, LibreOffice это пример такого софта, который компилируют не в домашней убунточке, а в RHEL. Я имею в виду RPM-пакеты с официального сайта. Полгода назад они обновили билд-ферму с RHEL5 до RHEL7. Правда, у меня LibreOffice 5.3 не запустился в CentOS 5, пока я не обновил libstdc++ до 4.8. Видать, билд-ферма, хоть и была RHEL5, но компилятор был новый.

Другие примеры такого софта: Oracle Java (SUSE 9.3), драйвер NVIDIA (версия 410.xx компилировалась в RHEL4, версия 413.xx и новее компилируется в RHEL 6), драйвер Catalyst 15.12 (SUSE 11), Adobe Flash (версия 11.2 в RHEL5, версия 23.x и новее - в RHEL 6)

Жду профиля, в котором запретят html и разрешат только js-фреймворки, прошло две недели с момента релиза - объявлять устаревшим.

leftpad делать через leftpad.io, без вариантов.

Где вас штампуют, смузихлёбы?

Наш новый js-фреймворк и данные, и стили засунет в json, не переживайте.

разделение ответственности

В прародителе не было разделения ответственности. И от всего этого мой браузер не выжимает раму гигабайтами.

Ну а вот я бы наверное был бы за то что программы требующие таких версий уже бы заворачивались в flatpak/snap и не имели бы возможности установить через apt/yum

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

Точно такие же люди, как ты, у меня на работе гадят докером для опакечивания скриптов направо и налево, берут громоздкие java-решения, оправдывая это своим «А вы планок памяти ведь докупите?», а потом пишут на корутинах код, говоря, что так РЕСУРСОВ РАСХОДУЕТСЯ МЕНЬШЕ.

Предлагаю тебе все системные демоны закинуть в flatpak/snap. Ну или собрать статично.

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

Да, полировать и тестировать - очень сложное занятие.

Какая прелесная простыня... ну что я скажу: история мягко говоря, странная. Вот подумайте когда был 1999 год. Да у меня под окном моей хрущёвки мамонты ходили. За это время APT/dpkg уже мог обзавестись и поддержкой версионности, и установки библиотек/программ рядом выбирая из списка версий(Привет libpng12.0.so!), и создание бекапов в виде одного большёго deb пакета в качестве бекапа, и раздачу пакетов по торренту со всех зеркал сразу, а когда появился git то можно было бы отдавать только изменившиеся части нового пакета, тем самым уменьшая трафик сервера, и графический софт для создания пакетов в 1.5 клика...
Это просто мечты. И дальше будут какие-то flatpack, appimage, snappy и прочие сатанинские приблуды. Будут просто засорять систему. Места ж не жалко. Ты легко выделишь 1 тб под корень на своем SSD, ибо на диске это будет ставится вечно. Фе, такое будущее нинужно.

кстати, а оно вообще развивалось?

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