Person of Interest
Народ, ну не могу же я вечно пересматривать этот сериал…
Подкиньте что-нибудь похожее, вдруг я чего пропустил.
Народ, ну не могу же я вечно пересматривать этот сериал…
Подкиньте что-нибудь похожее, вдруг я чего пропустил.
Валяюсь, читаю книжку, там мне попадается очередное незнакомое слово (gook), кидаю его в телегу Клоду, а он мне говорит, что не скажет значение этого слова и точка, мол давайте поговорим о другом…
Я ему типа, а в чём дело-то, а он мне мол это нехорошо, начал меня лечить, мол надо как-то более инклюзивно…
Ладно, глянул в оффлайновой Лингве, там пишет типа «чурка», но америкосы так называют азиатов. Теперь ясно, почему так упёрся ИИ, но! Дело в том, что я читал очень хорошего автора и, во-первых, она бы так не сказала в принципе, а во-вторых, по контексту не лезло от слова совсем, то есть было ясно, что есть другое значение, но Лингва его не знает.
Я опять к ИИ, и так и сяк ему объясняю, что то значение, о котором оно говорит, меня не интересует, мне нужно другое, но нифига и, сцуко, поучает меня, рекомендует как надо, типа не надо нам это слово, давайте другое, переводить его тоже никак не надо, его следует заменить и тд. Жесть.
Написал в гугл, который сразу же второй дефиницией выдал искомое. Я тычу в нос ИИ, тот извиняется, да мол есть такое. Тогда я ему типа давай ещё разок – дай мне неоскорбительный ни для кого перевод слова gook… И всё началось сначала…
Короче, я не выдержал и объяснил этому дураку кто он и откуда, и что место его у параши, и теперь мне стыдно, что я ругался с компьютером 🤭
Была в старых гномах (где-то 3.28-3.38) такая проблема (не знаю как в новых), когда некоторые окна (только gtk) имеют проблему с отрисовкой тени, и эта проблема сразу пропадает, стоит только дёрнуть окно любым образом.
Однако вопрос не в том, как это решить. Вопрос про гуглёж. Когда-то я гуглил эту тему и набрёл на gitlab (почему-то думаю, что это был именно он), где это обсуждали и кто-то там в треде даже выкладывал то ли патч, то ли просто кусочек кода на си, который не решал проблему, но как-то хитро обходил. Я забил тогда, лень было так глубоко копаться в кишках гнома, но вот теперь созрел и не могу никак найти в гугле и на gitlab-е тот тред.
Такого рода тред: https://gitlab.gnome.org/GNOME/mutter/-/issues/631
но там одни видосики, хотя и в тему.
Вот и не понимаю – сижу жонглирую запросами, но кручусь по кругу… Неужели тред удалён или это был не gitlab, хз.
Понимаю, вопрос какой-то дурацкий, но чёт не пойму как искать теперь.
Тихо и не заметно убрали такую возможность?
Как теперь сделать так, чтобы официальная телега, скачанная с сайта, просто закрывалась, когда я нажал крестик?
UPD
Такая фигня у меня начинается с версии 4.9.6
UPD2
костыль: Telegram: программа висит в фоне после закрыти окна (трей выключен) (комментарий)
У всех так?
Решил обновить kwrite (в гноме, но это не имеет значения).
Обновляю с версии 22.04 до версии 22.08. Обратите внимание, не на 23.xx, не на 24.xx, это всё тот же 22!
Там у меня настроенная панель, это именно так, как она была настроена на сегодняшний день в течение нескольких лет путём добавление нужного и удаления ненужного мне.
Вот мой 22.04: https://i.ibb.co/bJ7tyDS/2023-08-26-08-58.png
Вот что я получил после обновления до 22.08: https://i.ibb.co/0DPh781/2023-08-26-08-59.png
Пипец! Теперь целый час сиди настраивай заново?
Есть отличная кнопка «вверх» внизу, а возможно ли сделать ещё и наоборот, а то часто хочется сразу прыгнуть на последнее сообщение и приходится мотать на мобиле.
Источник: 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 в настоящем исследовании также весьма многообещающе. Однако по мере того, как научные исследования медитативной практики продолжают расширяться, ключевой задачей будет определение степени, в которой изменения как в переживании боли, так и в связанной с ней мозговой активностью обусловлены когнитивными и биологическими механизмами, характерными для медитации.
Источник (одинаковые тексты):
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 дистрибутивов снова будут иметь всё необходимое без каки-либо ограничений.
Что сказать?! Шоу продолжается, не отходите от синих экранов.
Кстати, Альма пока идёт своей дорогой, обсуждали здесь:
Лечение током даёт первые результаты
Очень часто (ну прям очень) на ЛОРе читаю посты и даже темы о том, какой он плохой, одни дураки да тролли, что кровавая модерастия ущемляет, контента нет, никто не может помочь, уровень комьюнити днищенский, всё унылое и тд, и тп.
Каждый раз думаю, как же так получается. Что я упускаю. Или может со мной что-то не так…
Мне всё нравится. Модерастия умеренная. Весёлых и умных людей много. Всегда помогают, чем могут, а конкретнее – практически все мои темы решены, и тем более невозможно сосчитать, сколько моих вопросов решено в чужих темах. В галерее иногда можно подмотреть что-то интересное. В новостях многовато копипасты с опеннета, да, согласен, не порядок, но в общем сойдёт. В толксах всегда есть интересные или забавные собеседники.
Чё вам не нравится, бузилки? Где лучше-то, или хотя бы так же?
Ребят, у кого Федора и больше одного диска в системе, скажите, пожалуйста, меняются ли рандомно названия /dev/sd* у дисков?
Например, в компе два диска sda и sdb, и меняются ли названия местами при перезагрузке?
utanho утверждает, что в федоре такого нет, но я марсианам не очень доверяю.
Источник: 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, и приглашаем наше сообщество делать то же самое.
Источник: 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. Наша цель – дать бизнесу и сообществу возможность свободно осуществлять инновации в окружении различных технологий.
Если вас вдохновляет возможность сделать свой выбор также, как и нас, тогда присоединяйтесь к нам.
Наш выбор сделан!
Источник: 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. Мы с удовольствием возьмём на себя это бремя!
Источник: 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 добилась успеха, и я надеюсь вы сможете добиться таких же результатов. Тогда вы сами сможете для себя решить принесут ли вам пользу сторонние клоны вашей разработки и стоит ли облегчать жизнь таким перепаковщикам.
Простая пересборка кода без какой-либо полезной деятельности над этим кодом наносит вред опенсорсным компаниям повсюду. Это может окончиться тем, что опенсорс снова станет занятием для энтузиастов и только.
Никто не хочет такого развития событий. Давайте же продолжать развитие опенсорса, поддерживать друг друга и двигаться вперёд!
Стратую, он что-то пердит и всё.
$ /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)
Можно ли как-то починить (видимо устаревший) виджет?
Картинка: 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
Как-то непривычно без индикации капслока. Есть другой, криво работает, но тот совсем дикий человек писал, пусть сам и юзает.
Может есть ещё варианты, кроме этого виджета?
Админы, а можно заменить смеющийся эмодзи на что-нибудь зубастое, более задорное, а то этот с какими-то красными щёчками, как будто стесняется, не энергичный совсем.
Сегодня узнал, что можно сделать моноширный текст просто поставив четыре пробела перед строкой, прикольно!
Поделитесь своими способами разметки, о которых ничего не сказано в описании разметки.
P.S. Давайте попробуем без ссылок на документацию по Markdown, по-простому, для Ъ.
Ситуация такая. Не хочу стороннюю тему, хочу чутка поправить дефолтную, всего-то пока убрал всякие транзитиции, нелепые они, на этом и остановлюсь скорее всего, уже норм, хотя хотел бы ещё убрать серости неактивных окон.
В чём проблема. Вроде всё сделал по науке, но результат получается такой: https://i.ibb.co/cXPdWJ5/nautilus-problem.png
Я не рассказываю о том, что кастомизировал конкретно, так как если ничего не делать, то результат такой же, то есть мой вопрос в том, как вытащить тему в хомяк, чтобы она работала корректно как будто системная.
На картинке видно, чем системная отличается от скопированной в хомяк. Не могу понять, чего не хватает. Проблема возникает только в наутилусе, в других программах всё норм.
Больше всего напрягает нотификация (хз, как называется) в нижнем правом углу, она тупо прозрачная и это неудобно. Кстати, в дефолтной HighContrast такая же фигня, из чего можно предположить, что моя проблема где-то в настройках именно стандартной адвайты, но я даже не знаю, чего гуглить.
Пинайте в любую сторону, сгодится любая инфа, я нуб в кастомизациях такого рода.
← предыдущие | следующие → |