LINUX.ORG.RU

Сообщения papin-aziat

 

Встречайте новые репозитории для AlmaLinux OS: Testing и Synergy

Новости — Red Hat
Встречайте новые репозитории для AlmaLinux OS: Testing и Synergy
Группа Red Hat

Привет, Комьюнити! Поскольку AlmaLinux OS изменила направление своего развития на совместимость с ABI, теперь мы можем предоставлять дополнительный контент для нашего сообщества. По этой причине были добавлены два дополнительных репозитория - Testing и Synergy. Сегодня мы объявляем, что оба репозитория доступны для AlmaLinux OS 8 и AlmaLinux OS 9.

Репозиторий Testing

Как мы уже говорили, репозиторий Testing содержит обновления, направленные на обеспечение безопасности, которые AlmaLinux OS теперь может выпускать самостоятельно, не дожидаясь релиза этих патчей в апстриме. Поскольку эти пакеты требуют дополнительного тестирования перед релизом, мы приглашаем сообщество помочь протестировать их и предоставить обратную связь.

Примечание: Репозиторий Testing не рекомендуется использовать на производстве.

Чтобы добавить и активировать репозиторий Testing для AlmaLinux, выполните следующую команду:

dnf install -y almalinux-release-testing

Пользователи также могут отслеживать доступные обновления на repo.almalinux.org:

Берите пакет, который вы хотели бы протестировать, и расскажите, как он у вас работает, на нашем баг-трекере.

Репозиторий Synergy

Репозиторий Synergy предназначен для любого пакета, которого еще нет в RHEL или EPEL, но который был запрошен участником сообщества AlmaLinux в интересах всего сообщества. Мы действительно будем поддерживать и приветствовать любой вклад, однако, как только пакет появится в EPEL, он будет удален из репозитория Synergy.

Более того, этот репозиторий можно использовать для других дистрибутивов в экосистеме Enterprise Linux, таких как RHEL, CentOS и т.д.

Чтобы добавить и активировать репозиторий Synergy для AlmaLinux, выполните следующую команду:

dnf install -y almalinux-release-synergy

Чтобы добавить и активировать репозиторий Synergy в других RHEL-совместимых дистрибутивах, выполните следующую команду:

dnf install -y https://repo.almalinux.org/almalinux/almalinux-release-synergy-latest-$(rpm -E %rhel).noarch.rpm

Примечание: Активация репозитория Synergy также автоматически активирует репозитории EPEL и PowerTools/CRB.

Пакеты репозитория Synergy также можно найти на repo.almalinux.org:

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

В настоящее время репозиторий содержит пакеты для среды рабочего стола Pantheon и приложения Warpinator.

Участие и поддержка

Этими репозиториями управляет Core SIG, и вы можете найти более подробную информацию обо всех доступных репозиториях ОС AlmaLinux на вики-странице Repositories, включая требования, которые следует учитывать, для добавления пакетов в репозиторий Synergy.

Ответственные лица:

Присоединяйтесь к чату Packaging chat channel, чтобы делать запросы на пакеты, обсуждать что-либо или обратиться за помощью.

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

>>> Источник

 ,

papin-aziat
()

Кнопка «вниз» — такое возможно?

Форум — Linux-org-ru

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

 

papin-aziat
()

Нейронаука. Медитация. Боль

Форум — Talks

Источник: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6623400/

Неужели медитация способна уменьшить боль, используя особый нейромеханизм?

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

Несколько исследований уже продемонстрировали положительный эффект медитации для хронической и острой боли. Большинство из них подтверждают влияние медитации на эмоциональные и оценочные аспекты (McCracken и др., 2007; Morone и др., 2008; Perlman и др., 2010), а некоторые также показывают влияние на порог чувствительности (Grant и др., 2010 и 2011) и интенсивность восприятия боли (Grant и Rainville, 2009). Исследование биологических механизмов таких методов улучшает наше понимание эндогенной регуляции боли и может увеличить наши возможности в лечении болевых расстройств.

Недавнее исследование опытных практиков медитации показывает, что интенсивная тренировка определенных когнитивных способностей может приводить к утолщению кортикальных областей, связанных с обработкой болевых ощущений, включая межполушарный центральный кортекс (MCC, midcingulate cortex) и вторичный соматосенсорные кортексы (Grant и др., 2010). Изучение потенциалов, связанных с реакцией на события во время ожидания боли, показало, что долгосрочная практика медитации изменяет предварительную оценку и нейрональную обработку боли в MCC и других областях, отвечающих за болевые ощущения (Brown и Jones, 2010). Функциональная нейровизуализация показала, что во время болевых ощущений практикующие имели сниженную активацию амигдалы, гиппокампа, эмоциональных и оценочных областей передней коры головного мозга, а также увеличенную активацию в MCC, таламусе и инсуле (Grant и др., 2011). Кроме того, измененная чувствительность к боли была связана со снижением функциональной связи между MCC и dlPFC (дорсолатеральная префронтальная кора). Grant и др. (2011) истолковали эти результаты как согласующиеся с целями медитации, которые заключаются в увеличении внимания к текущему сенсорному опыту (в данном случае, боли), при одновременном снижении эмоциональных и оценочных реакций.

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

В связи с этим, Zeidan и др. (2011) сделали важный шаг вперед, опубликовав свое недавнее исследование в The Journal of Neuroscience. Zeidan и др. (2011) сканировали 15 здоровых добровольцев с использованием метода пульсирования артериальной маркировки спинов (ASL, arterial spin labeling. Последовательность импульсов МРТ, которая предоставляет количественную оценку кровотока в мозге [CBF, cerebral blood flow] с использованием воды в качестве индикатора потока). Сессии сканирования проходили до и после краткосрочного обучения медитации, состоящего из четырех сеансов по 20 минут в последовательные дни. При первом сканировании (до обучения медитации) испытуемым подавали неприятные (49°C) и нейтральные (35°C) тепловые раздражители в контрольных условиях: нейтральное состояние внимания (rest) и с концентрацией внимания на дыхании (ATB, attention-to-breath). После каждой серии подачи неприятных тепловых раздражителей оценивали интенсивность боли и неприятные ощущения. Вторая (после обучения медитации) сессия сканирования была идентична первой, однако следует отметить, что благодаря обучению медитации способность испытуемых сосредотачиваться на ощущениях своего дыхания, одновременно уменьшая влияние отвлекающих факторов, суждений и эмоциональных реакций, по-видимому, была улучшена. Итак, с точки зрения инструкций условия совпадали до начала обучения и после, но отличались с точки зрения способности индивида занимать нейтральную позицию к болевому раздражителю.

Zeidan и др. (2011) сообщают о значительных изменениях у всех испытуемых в средних оценках интенсивности и ощущении неприятности боли между ATB (до обучения) и медитацией (после обучения), как это можно видеть на Рис. 2. Вторая сессия МРТ во время медитации показала значительное снижение вызванного болью кровотока (CBF) в контралатеральной первичной соматосенсорной коре по сравнению с нейтральным состоянием (rest). Вызванное тренировкой уменьшение интенсивности боли коррелировало с активностью в правой передней извилине и MCC, которая характерна для медитации независимо от наличия болевой стимуляции. Также вызванное тренировкой уменьшение ощущения неприятности во время медитации коррелировало с активацией орбитофронтальной коры (OFC, orbitofrontal cortex) и деактивацией таламуса.

Использование ASL было значимым элементом в исследовании Zeidan и др. (2011). Несмотря на то, что ASL имеет ограниченное пространственное и временное разрешение по сравнению с BOLD fMRI (blood-oxygen-level-dependent imaging), этот метод хорошо подходит для изучения нейромеханизмов, посредством которых медитация может влиять на клинические состояния боли. Одна из причин заключается в том, что сигнал ASL чувствителен к перфузии, а не к оксигенации крови, и поэтому не подвержен медленным дрейфовым артефактам, которые возникают в экспериментах с BOLD fMRI, когда интервалы времени стимулов и задач превышают 1 минуту. Это делает ASL идеальным инструментом для изучения как хронической боли, так и медитации, которые демонстрируют продолжительную нейрональную активность. Недавнее применение ASL для мониторинга динамических изменений CBF в течение нескольких минут в модели мышечной боли (Owen и др., 2010) подтверждает пригодность ASL для изучения естественно возникающих состояний боли. Исследование Zeidan и его коллег (2011) демонстрирует преимущество применения ASL для изучения медитации, поскольку авторы смогли использовать более длительные функциональные интервалы времени (например, блоки термической стимуляции продолжительностью 5 минут и 55 секунд) для изучения устойчивого медитативного состояния. В совокупности эти исследования предполагают, что изучение влияния устойчивого медитативного состояния на естественно возникающую боль может быть перспективным и клинически значимым применением ASL в будущем.

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

Когнитивный механизм, считающийся уникальным для практики медитации, заключается в сочетании повышенного внимания и снижения негативной оценки. Поскольку передняя инсула и MCC, как известно, играют роль в обнаружении значимости и подготовке двигательных реакций (Menon и Uddin, 2010), увеличенная активация в этих областях может представлять собой нейронную структуру для усиления концентрации внимания к восприятию значимых аспектов боли. Учитывая, что концентрация внимания и сопутствующая активация в этих двух областях обычно связаны с усилением ощущения боли, вывод о том, что активация в этих областях как-то связана с уменьшением интенсивности боли кажется контринтуитивным, однако он согласуется с результатами исследования, которые получил Grant с коллегами (2011), работая с опытными практиками медитации.

Так как концентрация внимания, а также активация в MCC и инсуле, как ожидается, должны усиливать ощущение боли, то ключом к уже известному анальгетическому эффекту, который появляется благодаря обучению практике медитации, может быть снижение эмоциональных и оценочных реакций, возникающих одновременно с концентрацией внимания и активностью в MCC и инсуле. В связи с этим, следует отметить, что как Zeidan и др. (2011), так и Grant и др. (2011) обнаружили активационные паттерны в областях, связанных с подавлением негативных эмоциональных реакций (Ochsner и Gross, 2005). Grant и др. (2011) обнаружили функциональное разобщение в передней дорсолатеральной коре (dlPFC) и цингулате, которое они связывают с расхождением между вниманием к боли и оценкой боли. Zeidan с коллегами (2011) обратили внимание на обратную корреляцию между активацией OFC (орбитофронтальной коры) и оценкой ощущения неприятности, которая была связана с изменением в обработке переживаний удовольствия и вознаграждения. Степень согласованности между этими исследованиями указывает на то, что медитативные практики действительно могут снижать боль через особый нейромеханизм, который соответствует концентрации внимания и ослаблению оценочных и эмоциональных реакций.

Хотя эти паттерны активации согласуются с предполагаемыми когнитивными механизмами, которые характерны для практики медитации, подтвердить эти механизмы эмпирически предстоит будущим исследованиям. Было показано, что медитация приносит когнитивные преимущества (Lutz и др., 2008), но не следует предполагать, что эти эффекты возникают у всех людей или что они являются механизмом, посредством которого медитативная тренировка влияет на восприятие боли. Например, важно отметить, что Zeidan и его коллеги (2011) обнаружили, что после медитативной тренировки неприятные ощущения уменьшились примерно на 57%, но самооценка погружения в медитацию повысилась только на 14%. Хотя психометрические факторы могут объяснить это несоответствие, нельзя просто так считать, что изменения в восприятии боли могут быть полностью отнесены к медитации. Необходимо сочетать восприятие боли с хорошо зарекомендовавшими себя когнитивными задачами, которые манипулируют вниманием и измеряют его концентрацию, а также аффективные реакции на боль, чтобы установить связь изменений в самоотчете и нейрональной активностью с предполагаемыми когнитивными механизмами, которые возникают при обучении медитации.

Недостатком исследования Zeidan и др. (2011) с точки зрения проверки специфической для медитации механики является отсутствие контрольной группы с активным лечением. Существует много споров о том являются ли преимущества конкретных психотерапевтических вмешательств результатом когнитивных факторов, специфичных для этих видов терапии, или факторов, таких как ожидание эффективности, которые характерны для всех эффективных методов лечения (Wampold и др., 1997). Как показано в исследованиях эффекта плацебо относительно анальгезии, сильная вера в заявленные преимущества лечения, такого как медитация, может оказывать прямое влияние на восприятие и обработку сигналов боли (Wiech и др., 2008). Кроме того, такие убеждения могут привести к неосознанным предубеждениям в отношении самоотчета, которые будут соответствовать заявленным преимуществам (например, снижению оценок неприятных ощущений). Сравнение медитации с психотерапевтическими вмешательствами, которые не содержат специфичных для медитации компонентов, но в остальном совпадают по общим факторам, таким как степень вовлеченности пациента в процесс и убежденности в эффективности метода, позволит получить более точное понимание степени, в которой механизмы медитации отличаются от других форм когнитивной модуляции боли.

В заключение, Zeidan и др. (2011) предоставили важные сведения о нейронных механизмах, с помощью которых медитация изменяет восприятие боли. Исследование особенно многообещающее с точки зрения клинической нейронауки, поскольку наблюдаемые эффекты вызваны клинически обоснованным краткосрочным обучением медитации. Так как медитация и хроническая боль представляют собой трудности для традиционной функциональной нейровизуализации, использование ASL в настоящем исследовании также весьма многообещающе. Однако по мере того, как научные исследования медитативной практики продолжают расширяться, ключевой задачей будет определение степени, в которой изменения как в переживании боли, так и в связанной с ней мозговой активностью обусловлены когнитивными и биологическими механизмами, характерными для медитации.

 

papin-aziat
()

Взять всё, да и поделить...

Форум — Talks

Источник (одинаковые тексты):
https://openela.org/news/hello_world/
https://www.oracle.com/news/announcement/ciq-oracle-and-suse-create-open-enterprise-linux-association-for-a-collaborative-and-open-future-2023-08-10/
https://www.suse.com/news/OpenELA-for-a-Collaborative-and-Open-Future/

Oracle и SUSE объявили о намерении создать Open Enterprise Linux Association (OpenELA).

Короче, эта контора будет создана в ответ на известные события. Если кто пропустил, то здесь обсуждали:
Mike McGrath -- реакция на восстание клонов

Эти двое начали крошить батон на Шапку, вот здесь обсуждали:
Oracle встаёт на сторону бобра!
Хамелеон разевает беззубую пасть

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

Обещают уже в этом году начать выкладывать исходный код для версий 8 и 9, а может быть даже и 7. В каком виде это будет пока не ясно. Насколько это будет совместимо с RHEL тоже не понятно.

Они обещают, что создатели совместимых с RHEL дистрибутивов снова будут иметь всё необходимое без каки-либо ограничений.

Что сказать?! Шоу продолжается, не отходите от синих экранов.

Кстати, Альма пока идёт своей дорогой, обсуждали здесь:
Лечение током даёт первые результаты

 , ,

papin-aziat
()

Почему такой разный икспириенс?

Форум — Talks

Очень часто (ну прям очень) на ЛОРе читаю посты и даже темы о том, какой он плохой, одни дураки да тролли, что кровавая модерастия ущемляет, контента нет, никто не может помочь, уровень комьюнити днищенский, всё унылое и тд, и тп.

Каждый раз думаю, как же так получается. Что я упускаю. Или может со мной что-то не так…

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

Чё вам не нравится, бузилки? Где лучше-то, или хотя бы так же?

 

papin-aziat
()

Очень интересно!

Форум — Desktop

Ребят, у кого Федора и больше одного диска в системе, скажите, пожалуйста, меняются ли рандомно названия /dev/sd* у дисков?

Например, в компе два диска sda и sdb, и меняются ли названия местами при перезагрузке?

@utanho утверждает, что в федоре такого нет, но я марсианам не очень доверяю.

 ,

papin-aziat
()

Лечение током даёт первые результаты

Форум — Talks

Источник: https://almalinux.org/blog/future-of-almalinux/

Блестящее будущее AlmaLinux

benny Vasquez

Тут у нас последние недели творилась полная жесть, но я наконец-то рада поделиться с вами хорошими новостями.

Каким станет AlmaLinux

Если вы не в курсе последних событий, то Red Hat объявила, что больше никаким образом не будет содействовать созданию клонов RHEL. Мы с Джеком быстренько поделились своими предварительными соображениями (читай блог), но потом взяли паузу, чтобы хорошенько обдумать наши дальнейшие действия по развитию AlmaLinux OS. Итак, совет директоров AlmaLinux OS Foundation приняло решение, что операционная система AlmaLinux больше не будет клоном RHEL, но бинарная совместимость (ABI compatibility) с ним останется приоритетной задачей.

Бинарная совместимость (в нашем случае) означает, что программы, предназначенные работать на RHEL, будут без проблем работать на AlmaLinux

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

Что же всё это означает для пользователей

Для обычных пользователей практически ничего не изменится. Совместимые с Red Hat программы будут работать, а операционная система будет получать обновления безопасности своевременно. Потенциально заметное изменение в том, что мы отказались от строгого клонирования (bug-for-bug compatibility) и теперь можем принимать багфиксы без необходимости ждать релизы Red Hat. Хотя прекращение строгого клонирования и означает, что пользователи могут столкнуться с ошибками, которых нет в Red Hat, зато теперь мы можем принимать патчи самостоятельно.

Что поменяется в процессе разработки дистрибутива

Теперь наши патчи будут содержать комментарии, в которых будет ссылка на источник патча. Это добавит прозрачности в разработке дистрибутива.

Ещё, чтобы не распылять наши силы, мы будем просить всех, кто сообщает о проблемах в AlmaLinux, тестировать и воспроизводить это всё в CentOS Stream.

Что дальше?

Так как мы больше не привязаны к необходимости воспроизводить строгий клон, нам потребуется некоторое время, чтобы понять, какие перед нами открываются возможности теперь. Мы подключим к дискуссии по этому вопросу всех участников AlmaLinux OS Foundation и будем держать в курсе этого процесса всех, кому это интересно.

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

Приверженность идеям опенсорса

Мы хотим чётко обозначить свою позицию. Хотя текущие изменения открывают перед нами широкие возможности, мы как и прежде будем соблюдать все правила игры. Мы продолжим делать свой вклад в развитие Fedora, CentOS Stream и общую экосистему Enterprise Linux, и приглашаем наше сообщество делать то же самое.

 

papin-aziat
()

Хамелеон разевает беззубую пасть

Форум — Talks

Источник: https://www.suse.com/c/at-suse-we-make-choice-happen/

Dirk-Peter van Leeuwen

Корпорация SUSE сделала выбор

Более 25 лет опенсорс меняет наш мир. От большого взрыва роста популярности Linux мы дошли до виртуализации, затем наступили облачные технологии и многое другое, так какая же сила лежит в основе большинства этих достижений? Опенсорс! Для меня всё предельно ясно. Мы хотим, чтобы как можно больше людей было вовлечено в разработку, ведь от этого выигрывают все. Чем больше людей этим занято, тем быстрее проблемы всплывают на поверхность и становятся очевидными. Суть идеи в том, что софт должен быть свободно доступным для использования, изменения и распространения любым человеком, а запрещение пользователям делиться исходниками, которые они получили от вендоров, ограничивает возможность обращаться к широкому сообществу Linux, чтобы оценить качество программного обеспечения, от которого эти пользователи зависят.

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

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

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

У клиентов по-прежнему должен быть выбор! Такова наша приоритетная задача. Мы объявляем о создании форка (hard fork) кодовой базы RHEL, который будем поддерживать и развивать совместно с сообществом Linux. Это именно то, что мы умеем делать хорошо, и таким образом у наших клиентов по-прежнему будет выбор и долгосрочная совместимость.

Чтобы проще было понять, о чём идёт речь, приведём такое сравнение.

Когда вы меняете сотового оператора, для вас важно, чтобы номер остался прежним. Точно так же вы, как пользователь Enterprise Linux, сможете спокойно перейти на SUSE сохранив привычный вам Linux без изменений, так как мы – эксперты в предоставлении софта для серьёзного бизнеса в условиях высокой конкуренции.

SUSE обладает уникальными возможностями для решения такой задачи. У нас более чем тридцатилетний опыт в разработке Linux и предоставлении надёжной платформы для критически важных нагрузок в промышленных масштабах. Наша команда обладает огромным опытом в поддержке программных окружений, где объединяются различные технологии. В прошлом году, мы успешно внедрили SUSE Liberty Linux для наших клиентов, которым требуется поддержка CentOS и RHEL. Кроме того, SUSE Manager уже давно известен своими возможностями по эффективному управлению широким спектром дистрибутивов Linux, демонстрируя наше желание давать пользователям гибкость и выбор. SUSE непоколебима в стремлении делиться результатами своей работы. Мы гарантируем, что все будут иметь свободный и открытый доступ к исходному коду и что данный проект никогда не будет ограничен каким-либо образом.

Хочу ещё добавить. Разумеется, SUSE по-прежнему полностью привержена решениям SUSE Linux Enterprise (SLE) и Adaptable Linux Platform (ALP), а также дистрибутивам openSUSE Linux. Наша цель – дать бизнесу и сообществу возможность свободно осуществлять инновации в окружении различных технологий.

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

Наш выбор сделан!

 ,

papin-aziat
()

Oracle встаёт на сторону бобра!

Форум — Talks

Источник: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/

Пресс Релиз

Edward Screven & Wim Coekaerts

Берегите открытость и свободу Linux, не соглашайтесь ни на что другое!

Уже долгих 25 лет Oracle является частью сообщества Linux. Все эти годы наша цель оставалась неизменной – сделать Linux лучшей в мире серверной ОС, которая доступна всем и каждому совершенно бесплатно, а также предоставлять высококвалифицированную поддержку по доступной цене.

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

Известный всем Oracle Linux и платная техподдержка к нему стартовали в 2006 году, и с тех пор используются повсюду, в том числе Oracle Linux обеспечивает работу наших фирменных специализированных систем и функционирование нашей облачной инфраструктуры. Мы не хотели раздроблять сообщество Linux, и именно поэтому выбрали совместимость с RHEL. Наши усилия по сохранению совместимости были чрезвычайно успешными, ведь за все эти годы у нас почти не было зафиксировано ошибок по этому вопросу. Независимые поставщики софта, интернет провайдеры, а также наши клиенты, ничего не делая со своим программным обеспечением, спокойно могут поменять RHEL на Oracle Linux. Мы, со своей стороны, сертифицируем для RHEL наш фирменный софт, хотя собираем и тестируем его только на Oracle Linux.

Хотя Oracle и IBM имеют совместимые дистрибутивы Linux, у нас сильно разные представления о наших обязательствах как представителей опенсорса, а также по поводу работы в рамках GPLv2. Мы всегда выкладываем пакеты Oracle Linux и исходники к ним в свободный доступ. У нас нет никаких условий, которые ограничивали бы права пользователей по распространению Oracle Linux. А вот в документах IBM указано, что вы нарушаете условия соглашения, если используете их сервисы для реализации своих прав (по распространению), основанных на GPLv2. И наконец, по состоянию на 21 июня, IBM больше не публикует исходный код RHEL.

Почему же IBM пошли на такой шаг? (Читай здесь) Всё сводится к следующему:

В Red Hat тысячи людей тратят свое время на написание кода, исправление ошибок, интеграцию различных пакетов, а затем поддержку этой работы в течение длительного времени… Нам приходится (have to) платить людям за эту работу.

Интересное дело получается. IBM не хочет больше выкладывать исходники RHEL, потому что им приходится (have to) платить инженерам? Всё это выглядит странным, ведь до того момента в 2019 году, когда IBM купили Red Hat за 39 миллиардов, Red Hat – успешная независимая компания – публиковали исходники RHEL и в течение многих лет платили своим инженерам за работу.

Далее там разговор идёт о CentOS. Нас не удивляет, что ситуация вокруг CentOS используется автором, чтобы обосновать прекращение публикации исходников. CentOS был очень популярным бесплатным дистрибутивом, совместимым с RHEL. В декабре 2020 года IBM фактически уничтожила его как бесплатную альтернативу RHEL. Вместо CentOS появились две новые альтернативы: AlmaLinux и Rocky Linux. Теперь же, прекратив публикацию исходников, IBM наносит удар конкретно по этим дистрибутивам.

Устранение конкурентов, видимо, и есть единственная причина такого поведения. Конкуренты сокращают вероятный доход IBM.

Как бы там ни было, корпорация Oracle продолжит преследовать свою цель. Мы по-прежнему будем работать прозрачно и открыто, чтобы минимизировать дробление сообщества Linux. Мы продолжим разрабатывать и тестировать наш софт на Oracle Linux. Не смотря на то, что в прошлом доступ к исходному коду RHEL был важен для поддержания совместимости с RHEL, Oracle Linux и далее будет оставаться совместимым настолько, насколько это будет возможным. Мы полагаем, что на практике Oracle Linux будет совместимым с RHEL как и прежде, но после всех этих событий проблемы могут возникать чаще. Однако, если у наших клиентов возникнут подобные проблемы, то Oracle будет работать над их устранением.

Мы хотим, чтобы разработчики и пользователи Linux знали, Oracle придерживается принципов свободы, которая свойственна сообществу Linux. Oracle ответственно берёт на себя следующее обязательство – до тех пор, пока Oracle поддерживает свой дистрибутив Linux, мы будем выкладывать пакеты (нашего дистрибутива) и исходные тексты к ним в открытый доступ без каких-либо ограничений! Более того, Oracle категорически приветствует создание новых дистрибутивов на основе нашего, как сообществом, так и коммерческими организациями. Мы будем только рады сотрудничать с разработчиками дистрибутивов, чтобы облегчить этот процесс. Мы готовы сотрудничать по любым вопросам, чтобы обеспечить сертификацию наших фирменных продуктов на вашем дистрибутиве (который основан на Oracle Linux).

Кстати, если вы разработчик Linux и не согласны с действиями IBM, если вы такой же убеждённый сторонник опенсорса как и мы, то мы приглашаем вас на работу к нам.

Ещё пару слов для независимых разработчиков софта и интернет провайдеров. IBM действует не в ваших интересах! После уничтожения CentOS как альтернативы для RHEL, а теперь нападая на AlmaLinux и Rocky Linux, IBM лишает ваших клиентов свободы выбора и возможности сократить свои расходы, следовательно их бюджеты, выделенные на программное обеспечение, вам придётся разделить с IBM. Если же вы пока ещё не предоставляете поддержку своего продукта на Oracle Linux, то мы с большим удовольствием вам продемонстрируем, насколько это легко и просто на самом деле. Дайте вашим клиентам возможность выбирать!

А для IBM у нас есть хорошее предложение. Вы не хотите (судя по всему) платить разработчикам RHEL? Вот как вы можете сэкономить деньги: просто возьмите наш продукт за основу и используйте – клонируйте, разрабатывайте и распространяйте Oracle Linux. Мы с удовольствием возьмём на себя это бремя!

 , , ,

papin-aziat
()

Mike McGrath — реакция на восстание клонов

Форум — Talks

Источник: https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes

В эти выходные я много думал о реакции сообщества на мой последний пост в блоге. Какими только словами Red Hat не обзывают, а я типа засланный казачок из IBM, чтобы сделать наконец Шапку проприетарной (и это ещё не самый бредовый бред). Давайте проясним, что же на самом деле происходит.

Зовут меня Mike McGrath, я вице-президент целого отдела в Red Hat. Работаю здесь уже 16 лет, а до этого волонтёрил в Федоре. Opensource для меня не пустой звук, уж поверьте. Так вот, целую неделю я наблюдал как многие люди говорят неприятные и просто лживые вещи о трудолюбивых шляпниках, которые любят и ценят Opensource (как и я) до самой глубокой глубины души.

Болтать можно всякое, но мы трудимся в поте лица не только ради наших клиентов. Уясните уже себе – Red Hat всегда будет использовать опенсорсную модель разработки! Когда мы находим баг или добавляем новую фичу, это всегда попадает в апстрим и приносит пользу каждому в нашем опенсорс-сообществе, а не только нашей корпорации или нашим клиентам.

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

Днями и ночами мы работаем, чтобы бэкпортировать патчи в код, которому пять, десять и более лет. Мы делаем всё это, поддерживая актуальность трёх-четырёх мажорных релизов одновременно. Кроме того, когда мы находим проблемы в RHEL, мы не просто чиним их в нашем дистрибутиве, нет! Сначала мы отправляем наши удачные решения в апстрим – в проекты типа Федоры, CentOS Stream или kernel, и только потом бэкпортируем в нашу систему. Поверьте, разработка и поддержка системы в течение десяти лет – это титанический труд, и трудно переоценить ту пользу, которую эта работа приносит всему сообществу.

Мы всегда будем отправлять наш код в апстрим и всегда будем соблюдать опенсорсные лицензии, в том числе и GPL. Я реально был потрясён и разочарован, как же много людей неправильно понимают открытое программное обеспечение и конкретно GPL, а особенно удивили знатоки и ветераны нашей индустрии, ведь они-то должны вроде бы понимать, но нет. Все – абсолютно все – детали, содержащиеся в лицензиях и правах открытого исходного кода, имеют значение! Red Hat не только помогал создавать вот это вот всё, но он же всё это бережно хранит и развивает.

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

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

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

Какое-то время мы считали, что в пересборщиках типа CentOS был какой-то смысл. Мы выкладывали наши SRPM-ы на git.centos.org в удобном для пересборки формате. Более того, мы сами удаляли брендирование! Но теперь пришли к выводу, что в этом нет никакого смысла.

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

В здоровой экосистеме открытого исходного кода должна быть конкуренция. Red Hat, SUSE, Canonical, AWS, Microsoft – все создают и поддерживают свои собственные дистрибутивы. Такое разнообразие делает важный вклад в развитие Linux и никто не настаивает на полной совместимости с чем-то другим.

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

Это приводит нас к разговору о CentOS Stream, вокруг которого возникла куча непоняток. Да, мы многое изменили в этой многолетней «традиции», это сбивает с толку, но мы это всё делали просто по доброй воле, не более. Однако нас начали обвинять в том, что мы собираемся закрыть исходный код и якобы нарушаем GPL. CentOS Stream поставляется открыто и бесплатно в виде репозиториев готовых пакетов и исходного кода на GitLab, где мы и создаём открыто и доступно для всех релизы RHEL. Так что называть RHEL проприетарным совершенно некорректно, это враньё. Да, Stream движется быстрее RHEL, поэтому код может ещё не быть в основной ветке, но он доступен на GitLab. Если вы не сможете что-то найти, значит произошла ошибка, сообщите нам об этом.

Далее, мы предоставляем бесплатные подписки для разработчиков Red Hat. Бесплатная подписка разработчика позволяет использовать до 16 систем совершенно бесплатно. Такие подписки могут использовать физические лица для своей работы, а также сотрудники наших клиентов. Также мы запустили Red Hat Enterprise Linux for Open Source Infrastructure. Это позволяет опенсорсным проектам тоже получать бесплатный доступ к RHEL.

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

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

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

 , , , ,

papin-aziat
()

KDE Connect (Segmentation fault)

Форум — Desktop

Стратую, он что-то пердит и всё.

$ /usr/libexec/kdeconnectd
kf.i18n: Loading the "qt_" catalog failed for locale QLocale(English, Latin, United States)
kf.i18n: Loading the "qt_" catalog failed for locale QLocale(English, Latin, United States)
kf.i18n: Loading the "qtbase_" catalog failed for locale QLocale(English, Latin, United States)
kf.i18n: Loading the "qtscript_" catalog failed for locale QLocale(English, Latin, United States)
kf.i18n: Loading the "qtmultimedia_" catalog failed for locale QLocale(English, Latin, United States)
kf.i18n: Loading the "qtxmlpatterns_" catalog failed for locale QLocale(English, Latin, United States)
kf.crash: Could not find drkonqi in search paths: ("/usr/libexec", "/usr/lib64/qt5/libexec", "/usr/libexec")
kdeconnect.core: Daemon starting
kdeconnect.core: Certificate from "/home/me/.config/kdeconnect/certificate.pem" is not valid
kdeconnect.core: Generating certificate
kdeconnect.core: My id: "_9363d394_931e_4ac2_8704_2ba92b0ebbf7_"
Unknown signature value:  0
kdeconnect.daemon: "KDE Connect" : "Could not store certificate file: /home/me/.config/kdeconnect/certificate.pem"
kdeconnect.core: LanLinkProvider started
kdeconnect.core: Daemon started
kf.notifications: Calling notify on "Popup"
kf.notifications: Calling notify on "Sound"
kdeconnect.core: Broadcasting identity packet
Segmentation fault (core dumped)

Попинайте в какую-нибудь сторону, застрял.

UPD ================================

После чистки кеша в хомяке только Segmentation fault

$ /usr/libexec/kdeconnectd
Segmentation fault (core dumped)

 , ,

papin-aziat
()

KDE — Keyboard Indicator

Форум — Desktop

Можно ли как-то починить (видимо устаревший) виджет?

Картинка: https://i.ibb.co/6ZvnQmq/Screenshot-20230622-200656.png

Текст

file:///home/me/.local/share/plasma/plasmoids/org.kde.plasma.keyboardindicator/contents/ui/main.qml:75:30: Invalid property assignment: unknown enumeration

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

Может есть ещё варианты, кроме этого виджета?

 , ,

papin-aziat
()

Смеющийся смайлик какой-то дурацкий!

Форум — Linux-org-ru

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

 

papin-aziat
()

Поделитесь фишками разметки Markdown на ЛОРе

Форум — Linux-org-ru

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

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

P.S. Давайте попробуем без ссылок на документацию по Markdown, по-простому, для Ъ.

 ,

papin-aziat
()

Кастомизация Адвайты. Куда копать?

Форум — Desktop

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

В чём проблема. Вроде всё сделал по науке, но результат получается такой: https://i.ibb.co/cXPdWJ5/nautilus-problem.png

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

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

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

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

 , , ,

papin-aziat
()

DejaVu Sans, что за магия?

Форум — Desktop

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

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

Вот так выглядит проблема, если удалить дежавю: https://i.ibb.co/7JJsnqC/230116152531.png
Вот так выглядит (то есть нормально), если поставить назад: https://i.ibb.co/0Dhz2vX/230116152620.png

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

Попинайте в нужную сторону.

 ,

papin-aziat
()

Зачем удалили тему «С Рождеством»?

Форум — Linux-org-ru

Dimez, что не так?

 

papin-aziat
()

Пробуждение компьютера мышкой (не всё получилось)

Форум — Desktop

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

Настроил так. Мышка висит на

/sys/bus/usb/devices/2-3/

это я знаю благодаря методу тыка :-)

По умолчанию в линуксах комп пробуждает клавиатура (кстати, очень интересно, где и как это настроено). Мне надо выключить клаву и включить мышку. В /opt кладу скрипт mouse_wakeup.bash

#!/bin/bash

echo disabled > /sys/bus/usb/devices/2-4/power/wakeup
echo enabled > /sys/bus/usb/devices/2-3/power/wakeup

Создаю сервис mouse_wakeup.service, чтобы не дёргать каждый раз руками

[Unit]
Description=Wakeup only by mouse

[Service]
Type=simple
ExecStart=/opt/mouse_wakeup.bash

[Install]
WantedBy=default.target

Вот сейчас выключил-включил комп и оно не работает (после перезагрузки будет работать 100%). Однако с виду всё OK

$ systemctl status mouse_wakeup.service 
● mouse_wakeup.service - Wakeup only by mouse
   Loaded: loaded (/etc/systemd/system/mouse_wakeup.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Fri 2022-12-09 16:39:57 MSK; 35min ago
  Process: 588 ExecStart=/opt/mouse_wakeup.bash (code=exited, status=0/SUCCESS)
 Main PID: 588 (code=exited, status=0/SUCCESS)

Dec 09 16:39:57 my systemd[1]: Started Wakeup only by mouse.
Dec 09 16:39:57 my systemd[1]: mouse_wakeup.service: Succeeded.
$ cat /sys/bus/usb/devices/2-3/power/wakeup
enabled

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

 

papin-aziat
()

Fedora 37: как тебе такое Илон Маск?

Форум — Desktop

Итак, решил глянуть как в гноме 43 идут дела с оптимизацией анимации. Дела идут плохо, ну и фиг с ним, тут дела поинтереснее.

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

Invalid image 
Failed to read header: Unsupported 
Failed to load image: Unsupported 
start_image() returned Unsupported

Я добавил тег AlmaLinux и Rocky, потому что быстрый гуглёж проблемы показал, что на Rocky 8.5 точно такая же проблема как и на Fedora 37, а Almalinux 9.1 я только что сам не смог загрузить.

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

Проблема звучит так:

A problem was identified and fixed in shim, an initial UEFI bootloader. Unfortunately, the fix isn’t present on Fedora 37 install media (but should be included in Fedora 38).

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

Что делать?!

Допустим твоей флешке с Fedora назначено имя /dev/sdc (уточни, бро, и замени на свой вариант), а монтируешь её в каталог /mnt/fedora.

# Монтируем раздел 2 флешки
sudo mkdir /mnt/fedora
sudo mount /dev/sdc2 /mnt/fedora

# Удаляем лажовый файл с флешки
sudo rm /mnt/fedora/EFI/BOOT/BOOTX64.EFI

# Качаем rpm-пакет с правильным файлом 
wget https://dl.fedoraproject.org/pub/fedora/linux/releases/36/Everything/x86_64/os/Packages/s/shim-x64-15.4-5.x86_64.rpm

# Распаковываем
rpm2cpio shim-x64-15.4-5.x86_64.rpm | cpio -idmv

# Копируем правильный файл в нужное место
sudo cp boot/efi/EFI/BOOT/BOOTX64.EFI /mnt/fedora/EFI/BOOT/
sudo umount /mnt/fedora

# Всё, дело сделано, дальше по желанию.
rm -r boot etc shim-x64-15.4-5.x86_64.rpm
sudo rmdir /mnt/fedora

Перезагружайся в флешку без проблем, работает, я проверял!

Источник: https://ask.fedoraproject.org/t/f37-install-media-dont-boot-in-uefi-mode-on-certain-motherboards/28364

Мда… ну ладно федора, у неё бывают неудачи в релизах нередко, но как в эту тему попали клоны энтерпрайзов вообще уму не постижимо! Интересно как в самой шапке с этим дела, кто знает?

 , ,

papin-aziat
()

DNF: джва года ждал!

Форум — Desktop

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

Дебиянщики ща будут пальцы гнуть и будут правы. Кстати, интересно, как с этим в раче?

Для Ъ выложу здесь.

sudo dnf install gcc libsolv-devel

Кстати, мне этих не хватило, ещё потребовалось поставить redhat-rpm-config.

touch rpm-unneeded.c

В этот файлик положите

#include <solv/pool.h>
#include <solv/poolarch.h>
#include <solv/repo_rpmdb.h>
#include <solv/solver.h>

int main(void)
{
    Pool *pool;
    Repo *rpmdb;
    Solver *solver;
    Queue q;

    pool = pool_create();
    pool_setarch(pool, NULL);
    pool_set_flag(pool, POOL_FLAG_IMPLICITOBSOLETEUSESCOLORS, 1);

    rpmdb = repo_create(pool, "@system");
    repo_add_rpmdb(rpmdb, NULL, 0);
    pool->installed = rpmdb;

    solver = solver_create(pool);
    solver_set_flag(solver, SOLVER_FLAG_KEEP_EXPLICIT_OBSOLETES, 1);
    solver_set_flag(solver, SOLVER_FLAG_BEST_OBEY_POLICY, 1);
    solver_set_flag(solver, SOLVER_FLAG_YUM_OBSOLETES, 1);

    queue_init(&q);
    solver_solve(solver, &q);
    solver_get_unneeded(solver, &q, 1);

    for (int i = 0; i < q.count; i++)
    {
        printf("%s\n", pool_solvid2str(pool, q.elements[i]));
    }

    queue_free(&q);
    pool_free(pool);

    return 0;
}

Собираем

gcc $(rpm -E %{optflags}) -fPIC rpm-unneeded.c -o rpm-unneeded $(rpm -E %{build_ldflags}) -lsolv -lsolvext

Положим подальше, хорошая программа!

mkdir ~/.local/bin
mv rpm-unneeded ~/.local/bin

Всё! Теперь любители чистоты и всяких там оптимизаций могут приступать к очищению своей системы от всякой бесполезной фигни.

Пару слов новичку. Среди пакетов, которые можно спокойно удалить окажутся и пакеты связанные с загрузкой системы такие как grub2-* или shim-x64, следи за тем, чтобы они не улетели в приступе пуризма, иначе система не загрузится.

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


UPD.

Спасибо @t184256, теперь я знаю, что в федоре уже прикрутили плагин к DNF, но у меня федоры нет, поэтому не могу посмотреть и сравнить.

Так что господа дебиянщики — всё, больше вам нечем похвастать.

–––––––

UPD 2

Прикрутили в федору аж в 2017 году, назывался python2-dnf-plugin-leaves. Посыпаю голову пеплом, век живи, век учись…

пруф: https://koji.fedoraproject.org/koji/buildinfo?buildID=885703

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

 , , , , rocky linux

papin-aziat
()

RSS подписка на новые темы