Мейнтейнеры Artix Linux отказались от поддержки GNOME DE 49+

Он про всякие podman quadlet видимо. Которые позволяют запускать контейнеры как сервисы сустемд, управлять ими через systemctl и т.п.

Народ хвалит, но лично моё мнение - чем меньше контейнеров на сервере, тем лучше.

Бедные Гномеры и куда им теперь? Удалять и ставить другой дистрибутив? Или можно переключиться на flavour c systemd и Gnome? Подстава от дистродержателей.

Этим артиксом пользуется полтора землекопа. «Бедные гномеры» сидят на fedora/ubuntu/arch где нет никаких проблем с Gnome 49+

Парни с яйцами. Молодцы. Пошёл читать кто такие.

Ну а в чём проблема установить systemd? Он что, не может загрузить систему? Может.

И ещё куча инит-систем может загрузить.

Тем временем Artix поддерживает 4 инит-системы на выбор.

Зачем ты перечисляешь минусы Artix?

dimgel почему баян? Текст подтверждает мой тезис и заслуживает прочтения.

В частности, определение, собранное по кусочкам:

The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.

…

This principle is about people.

…

… design your systems such that each module is responsible (responds to) the needs of just that one business function.

That’s how customers and managers feel when we break things they care about that they did not ask us to change.

Я, конечно, использовал другие слова, но разница между классом и модулем в данном контексте не столь важна, термин «владелец» подходит (кто ещё обычно требует ответственность?), а пример с отчётностью и GUI убирает любые разночтения.

Иными словами, SRP и Unix не имеют ничего общего, знаменитые принципы «do one thing and do it well» и «keep it simple» вообще не об этом, а пример любой успешной юниксовой утилиты демонстрирует нарушение SRP. SRP, кстати, объясняет каким образом утилиты GNU так сильно разжирели: желание угодить каждой аудитории в контексте архитектуры, неподходящей для этого.

Сила этих инструментов не в изоляции друг от друга, не в том, что /bin/cat не может написать номера строк, а в том, что все эти инструменты объединены общим окружением. Одним словом — интегрированы.

Этот тезис подтверждается и разработчиками самого Юникса:

Even though the UNIX system introduces a number of innovative programs
and techniques, no single program or idea makes it work well. Instead,
what makes it effective is an approach to programming, a philosophy of
using the computer. Although that philosophy can't be written down in
a single sentence, at its heart is the idea that the power of a system
comes more from the relationships among programs than from the
programs themselves.

(The Unix Programming Environment, Preface)

Обратите внимание на «from the relationships among programs than from the programs themselves.» Поэтому когда systemd выбрасывает на помойку старые инструменты, он всё правильно делает — они плохо встраиваются в новое окружение, «relationship» плохой.

Варианты отсутствия всяких изначально убогих концепций, вроде DE, в принципе не приходят в голову уже?

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

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

Нет, конечно, KDE там есть в репах. И Гном тоже вот был. Но причём тут «мейнстрим». Что хочешь, то и ставь из реп. В этом суть.

Мейнстримом я назвал дефолт, то что предполагается использовать теми, кто создает дистрибутив, то, что проработали, проверили, оптимизировали и сделали как надо. Если дефолта нет, то и смысла в дистрибутиве нет. Вот тебе мой дистрибутив - https://mirror.yansex.ru и ставь вообще что хочешь. В этом суть.

А с другой стороны браузер работает и чё ещё надо?

chromeos?

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

Возможно в этом и проблема, что я не смог. Мате можно пользоваться. Даже lxqt можно, а гномом имхо нет. Но я не навязываю.

Читни на досуге: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Читать инфоцыган? У тебя так много свободного времени?

Патамуштопатаму, гном г… гномеры п…

И ещё куча инит-систем может загрузить.

Чувак, мы буквально в теме про то, что башпортянки не могут загрузить гнома. Так что нет.

Какое низкопробное враньё.

А когда ГНОМ стал системой?

Стоит отметить, что зависимость KDE от systemd также постепенно усиливается

В КДЕ даже в системном мониторе без СистемД и СиГроупс не отображается в списке процессов сколько они потребляют памяти, сколько в них потоков и т.п. Так что в systemd-less средах (любая BSD, и некоторые дистрибутивы Линукс) системный монитор КДЕ не полнофункционален.

Когда человечество поняло, что сидеть в голой консоли это задродство.

ГНОМ - это единственно верная расовая система. Ну, окей.

S6 ни разу не использовал, ничего про неё не могу сказать.

Я могу: давно сформулированными впечатлениями поделиться.

Любая софтина по мере усложнения неизбежно выбирает один из двух путей:

(1) Монолитная супер-пупер вундервафля, предположительно-прекрасно справляющаяся с тем, что в ней предусмотрели разработчики, но шаг влево-вправо – расстрел. Как пример, сюда сразу и категорически отношу ВСЕ декларативные DSL (не буду уточнять, чтобы не плодить срач, но надеюсь, меня поняли).

(2) Мелкогранулированная хрень, SRP во все щели, и как следствие – 100% гибкая и расширяемая, но для простейших сценариев ВСЕГДА выглядит как оверкилл. Это unix way, и это s6. А также это например java: API мелкогранулированное, за что его все всегда хвалили, разные классы можно состыковать во что угодно, но состыковывать затрахаешься. Иначе не существовали бы библиотеки apache commons, как раз заворачивающие все эти мелкогранулированные приседания в простые хелпер-методы для типовых случаев.

А вообще s6 – очень элегантная штука (любая мелкогранулированная хрень обязана быть элегантной, иначе её же собственные разработчики в ней утонут). И как система инициализации и pid=1 – функционально полна (в отличие от всех остальных, с которыми я имел дело; уточнять опять же не буду).

У них все работает, а ты врешь. Тебе лично Билл Гейтс платит за такие комментарии. (Это бесполезное дело сектантов в чем-то переубеждать)

Знакомы ли вы с dinit?

А также это например java: API мелкогранулированное, за что его все всегда хвалили, разные классы можно состыковать во что угодно, но состыковывать затрахаешься. Иначе не существовали бы библиотеки apache commons, как раз заворачивающие все эти мелкогранулированные приседания в простые хелпер-методы для типовых случаев.

Хелпер методы для типовых случаев должны быть в самой библиотеке. И они со временем появились. Я уже давно не припомню, чтобы была нужда в этих commons. А вообще библиотека Java, особенно ранняя, спроектирована на редкость плохо. Да и поздняя тоже далеко не всегда образец для подражания.

Нет. Выше я писал об этом.

А вообще s6 – очень элегантная штука (любая мелкогранулированная хрень обязана быть элегантной, иначе её же собственные разработчики в ней утонут)

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

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

усилением зависимости GNOME от systemd

Зачем вообще нужно какую-то DE привязывать к иниту?

Зачем вообще нужно какую-то DE привязывать к иниту?

Чтоб не «падала», не? ;))

Чтобы не приходилось например самим писать инит.

усилением зависимости GNOME от systemd

Зачем вообще нужно какую-то DE привязывать к иниту?

Это шутка такая, да? Затем, чтобы создать единую экосистему, предсказуемую, управляемую, исключающую дубликацию. Ну прямо как дети малые!

И как, получилось?

не знаю, время покажет…

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

арч слишком сложный

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

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

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

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

100%

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

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

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

У меня всё нормально. Иногда по полгода не обновляю.

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

Вот единственный случай, когда я получил небутабельную систему. Но там я сам виноват.

Понедельник начинается в субботу, а пятница начинается в понедельник

Спасибо

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

Но 1) при этом ничего не разваливается 2) это лечится предварительным обновлением пакета archlinux-keyring или как его там, в котором и содержатся актуальные открытые ключи мейнтейнеров.

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

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

Например, недавняя история с разбивкой пакета linux-firmware — в Arch это потребовало ручного вмешательства и удаления пакета с нарушением зависимостей и последующей его переустановкой, при том что в Debian такая замена произвелась бы автоматически.

Ещё пример: pacman не отслеживает смену SONAME у библиотек, и это не компенсируется политикой сопровождения, как в Debian, — в результате это может приводить к внезапным проблемам после обновления. За примерами далеко ходить не надо: https://old.reddit.com/r/archlinux/comments/1dlsssl/libdisplayinfo_careful_with_updating/ . В Debian (да и в rpm-based дистрибутивах) такое не произошло бы.

В ту же копилку — отсутствие поддержки частичных обновлений. В новой версии пакета критичный баг? — откатывай назад всю систему и не обновляй ничего, включая обновления безопасности, пока тот баг не исправят. Ну или играй в русскую рулетку с partial upgrades unsupported.

Далее, нельзя забывать, что Arch — это bleeding edge. Например, после выхода релиза SDL3 мейнтейнеры тут же перешли на неё, выпилив при этом SDL2 из репозитория, понадеявшись на прослойку совместимости sdl2-compat. Результат не заставил себя долго ждать:

• https://gitlab.archlinux.org/archlinux/packaging/packages/sdl2-compat/-/issues/1
• https://youtu.be/tmTIToBuhZc?si=mzUrRdiK_8k60W98&t=3625
• https://youtu.be/A0FwQbeAVK0?si=L0mjdOegN_c_JNt5&t=300
• https://youtu.be/a0GXTAFHOtw?si=TIZ1vfeDRMh7fNRM
• …

Почему-то в том же Debian смогли оставить libsdl3 и libsdl2 в репозитории, и поэтому не рисковать сломать:

$ apt list '~D~n^libsdl2-2.0-0$' 2>/dev/null | wc -l
228

— пакетов из-за сырой прослойки совместимости.

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

Например, недавняя история с разбивкой пакета linux-firmware — в Arch это потребовало ручного вмешательства и удаления пакета с нарушением зависимостей и последующей его переустановкой, при том что в Debian такая замена произвелась бы автоматически.

Это прям хороший пример.

Во-первых про какие-то нарушения зависимостей ты не прав. Лично я просто удалил пакет linux-firmware и потом установил пакет linux-firmware-intel. Никаких зависимостей это не нарушило, по крайней мере в моей системе, от linux-firmware никто не зависит.

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

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

Одна процедура установки чего стоит.

Как раз установка-то там тривиальна - берёшь любой форк с нормальным инсталлером и вперёд: обычный calamares как правило.

А вот работать потом с этим убожеством это реально жесть: там даже аналога update-alternatives нет - то есть установка и удаление пакета может тупо сломать систему просто потому что это нетранзакционная операция. И это единственный дистр линукса из более-менее популярных где обосрались даже с настолько элементарными вещами.

достигается путём серьёзного усложнения процесса доставки кода от программиста до пользователя

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

Интересно было бы узнать, в каком дистрибутиве установка пакета это транзакционная операция. Уж точно не в использующих dpkg или rpm, это я гарантирую. Возможно в nix? Да и тут спорно. Транзакционность установки пакета начинается с транзакционности файловой системы, а с этим как-то не задалось в линуксе.

Во-первых про какие-то нарушения зависимостей ты не прав.

А что делают две буквы d в параметрах первой команды по ссылке? – это удаление с полным игнорированием зависимостей.

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

А где проходит эта граница между простотой и примитивностью? А то с такими вводными вам в Slackware, если вообще не в LFS.

Лично я предпочитаю автоматизацию тех процессов, которые можно легко автоматизировать, и тратить сэкономленное время на что-то более полезное, чем е**я с компьютером.

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

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

А что делают две буквы d в параметрах первой команды по ссылке? – это удаление с полным игнорированием зависимостей.

Я не выполнял эту команду.

А где проходит эта граница между простотой и примитивностью?

Не знаю, где. Наверное каждый сам решает, где.

А то с такими вводными вам в Slackware, если вообще не в LFS.

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

Лично я предпочитаю автоматизацию тех процессов, которые можно легко автоматизировать, и тратить сэкономленное время на что-то более полезное, чем е**я с компьютером.

А я препочитаю автоматизировать то, что надо часто делать. А что надо редко делать - предпочитаю не автоматизировать, а документировать.

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

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

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

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

Пакеты вообще не надо разбивать.

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

это лечится предварительным обновлением пакета archlinux-keyring или как его там

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

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

То есть, не всё так «радужно», как тут утверждается... «Не для простых людей» то, что тут нахваливается...