Проект KDE создает собственный дистрибутив KDE Linux

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

Часто бывает так что встроенную систему на Линуксе разрабатывают на компьютере с Windows/MacOS

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

Так есть же официальный неон, я и думал что это будет эталон, но почему-то им удается делать его более проблемным чем арч.

По-правде говоря, я бы ещё добавил для рифмы «не нужно».

Потому что смысл этого франкенштейна от меня ускользает. Разве что «тестовый стенд — демонстратор технологий». Кто этим будет пользоваться на ежедневной основе — загадка.

Впрочем, могу лишь присоединиться к голосам, отметившим, что кеды и гном явно идут куда-то не туда, если их нельзя нормально интегрировать в обычный дистр. С другими DE, тем же xfce, или mate, или cinnamon — почему-то таких проблем нет. Видимо, мысль о том, что «пора бы откусить кусок побольше, чем мы традиционно могли прожевать» всё-таки была порочной.

KDE это системный компонент

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

Как раз для тестеров необходимы равные условия, одинаковое состояние базовой системы.

Утро перестает быть томным

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

Я на линукс пытаюсь перелезть с 2006 года.

А ты упорный…

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

Очень хороший подход. Я бы так же делал примерно.

Потому что смысл этого франкенштейна от меня ускользает.

Монстр Франкенштейна – это как раз бессмысленное нарезание дистрибутива на кучу мелких пакетов в результате чего можно сломать всю систему установкой или обновлением какой-нибудь мелкой библиотеки. Сложный серьёзный софт вроде браузеров старается носить мелкие зависимости с собой.

Ну правильно, мелкая нарезка нам не годится, давайте сделаем полярно противоположное — вообще всё одним куском будем вываливать. «Промежуточные варианты — нет, не слышали».

А vscode-то зачем? Да и насчёт gcc вопросики… Или флатпак развалился и превратил карету в тыкву размером немного большим, чем бизибокс?

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

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

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

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

Все меинстримные ОС (Windows, MacOS, Android, ChromeOS) так делают. Вот зачем в Windows есть Блокнот когда есть множество сторонних текстовых редакторов?

Более того, арч с его … несовершенным в плане отслеживания зависимостей пакманом как раз и подталкивает к полным, а не точечным апдейтам.

Все меинстримные ОС (Windows, MacOS, Android, ChromeOS) так делают.

Ага, понятно, откуда ноги растут. А ничё, что у тех ребят денег куры не клюют?

1)KDE Linux уже существует, это KDE Neon 2)KDE + Arch уже пробовал, бред получается, так как: 3)Очень плохо согласуются, ресурсов жрёт столько же сколько Ubuntu, на моём железе без файла подкачки можно было открыть не больше 3-х приложений, дальше зависал напрочь. Установил Python IDLE, так он только из терминала открывался, в меню его не было. Перешёл на Linux Mint - намного лучше работает, без багов совсем и не требовательно к ресурсам. На Arch больше не вернусь.

KDE + Arch уже пробовал, бред получается … очень плохо согласуются,

Бред получается из сложенных тобой букв. Что там у тебя плохо согласуется?

на моём железе без файла подкачки можно было открыть не больше 3-х приложений

Может это проблема твоего железа?

Установил Python IDLE, так он только из терминала открывался, в меню его не было

неосилятор

На Arch больше не вернусь.

Аминь!

у кривого вечнодохнущего Neon

Так он скорее для демо бета-версий KDE, а не для мониторинга за состоянием АЭС через плазмоиды.

Интересный вариант арча, как понимаю, причина то что steam использует KDE, а вместе и батьку бить веселее.

Да и вообще, кде и гном достаточно большие, чтобы иметь собственный дистр, как deepin.

не задумываясь сделав там sudo pacman -S

Да, совершенно ничего не предвещало. Прямо ничегошеньки.

Системное окружение в KDE Linux представляет собой неделимый образ

Неделимый на что? Может быть integral?

Да всё понятно, только по-прежнему удивляет как можно таким говном пользоваться. Ещё и популярное.

Представляю KDE Linux, в котором открыт GNOME, в котором открыт xterm, в котором открыт tmux.

Я-то это знаю.

А вот некий процент обывателей, начитавшийся «топ 10 Linux для десктопа» от глубокоумных блоггеров (Каля кстати в тех же топах), то и дело его ставят, и совершено внезапно огребают ворох проблем (отчасти унаследованых от любвеобильного чернокожего папеньки)

в виртуалке под виндой

KDE это системный компонент, тут нужна изменяемая именно СИСТЕМА, нельзя засунуть KDE в докер, флатпак, шизовтак и прочее.

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

Не ври себе, у тебя работа стала на линуксе?

На маке

С Аеоном они там что-то экспериментируют. Я даже RC2 не смог установить в виртуалку, чтобы просто попробовать. Но Kalpa (MicroOS), которая с KDE очень хорошо работает. Это практически тот же Tumbleweed, вид с боку. В MicroOS ты бутишься в неизменяемый btrfs снапшот. Обновления устанавливаются так: система создает новый снапшот, выполняет там zypper ref, zypper dup, и накатывает апдейты в этом снапшоте. Причём это происходит само собой (но можно и явно сделать transactional-update dup). После чего у тебя должно появиться уведомление в трее (сейчас не появляется, мне сказали, что это какой-то баг), что можно ребутнуться в новый снапшот. Если хочешь откатиться, у тебя есть штук десять последних снапшотов, а не два как в других атомарных дистрах (A/B). Пакетная база в MicroOS та же самая, что и в Tumbleweed.

а всё из-за чего? потому что openbsd не используете! пересели бы на опёнка, и не плодили бы лишние дистросущности

Вообще с точки зрения рядового пользователя - идея хорошая.

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

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

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

И здесь два варианта.

Первый: учитывать кишки всех более менее популярных существующих систем. Это не так-то и легко технически - код распухнет из-за ifdef'oв, и будет весьма уродски выглядеть визуально. Ну вот даже взять эту киллер-фичу резервного копирования, прибитую гвоздями к btrfs... А если у меня в дистре например стоит ext4 - мои кеды должны не показывать эту фичу? Показывать ее неактивной? Или делать ее нефункционирующей как это делается например в xfce (Xfce4 Power Manager not running, сорян, управление питанием не работаид)?

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

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

Они сделают в этом дистрибутиве неотключаемый Nepomuk и Akonadi? А то нормальные дистрибутивы отключают этот шлак, наряду с mlocate, и система работает быстро и никогда не парализуется внезапным непрошенным сканированием, когда пользователю нужно работать а KDE уничтожило все ресурсы компьютера на то, что он вообще не просил в самый неподходящий момент?

«Работа на линуксе стала» у меня еще в 2008.

Потому что средства разработки, как, например, у меня emacs, или vscode используют другие утилиты, которые установленны в системе. Vscode должен найти системный Python, если у тебя Python проект. А из флатпака он этот Python не найдёт. Или я как-то пробовал использовать Emacs из флатпака. Он даже мой .emacs не смог правильно загрузить. Да, можно делать пляски с бубном в флатпаке, и что-то даже получится, но стоит ли овчинка выделки? В том же Bluefin (который типа Fedora Silverblue для разработчиков) vscode установлен в систему.

они из юникс-системы делают противоположность юникс-вею

… практически с самого появления Линукса. X11, OpenGL, SELinux, CUPS, LVM, systemd, coreutils — где здесь Юникс? Убери эти вещи и что останется от Линукса?

В итоге каждый компонент системы восстает против такого непотребства

/etc/passwd объявляет войну SELinux. Смешно.

он спроектирован для работы в среде с прямо противоположной идеологией.

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

Современное оценивание ПО по критерию «юникс/не юникс» — это больше похоже на жабогадюкинг.

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

Ок, тогда см коммент про микросервисы. Возможно, не юникс-вей, но такой подход возможен.

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

То есть допустим цель - разработка самого KDE. Можно запустить неон и на нем это делать, это как бы основной штатный путь. Это может происходить на реальной, либо на виртуальной машине. Случай с виртуалкой вообще покрывает все кейсы, когда «надо иметь стабильную систему и не загадить ее».

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

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

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

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

С микросервисами обратная ситуация, они и разрабатываются, и эксплуатируются в том же контейнере, в чем и смысл.

Вообще переход на арч-базед вполне логичен. Вольво же собирается в арч вкладываться и уже пару лет как вкладывается в кеды. Тут со всех сторон вин-вин.

Тут со всех сторон вин-вин

Согласен

Жуть какая!

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

Однако ж, получилось как в Кавказской пленнице, «абидна, да?!»

Так-то, я в курсе, что оно так бывает с пакманом. «Не первый раз замужем».

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

И? Так надо писать, что собственный дистрибутив KDE меняет основу.

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

В целом, для сэндбоксов типа флэпака можно разрешить выполнение определенных запускаемых файлов извне сэндбокса или вообще дать доступ к /usr. Но лучше (перспективнее, более контролируемо) заходить через экстеншны. Да, это требует дополнительных телодвижений со стороны пользователя или упаковщика, но в качестве награды — лучшее понимание, что от чего зависит, и как использует.

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

Просто показалась забавной формулировка про «ничего не предвещало» :)

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

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

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

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

Есть ли информация как потом пропатчить под фрибсд?

Чего-то я не очень понял проблему :) Не обязательно же при установке нового пакета производить обновление репозитория? Я имею в виду, что у пакетного менеджера pamac есть опция –no-upgrade