Ребят, у кого Федора и больше одного диска в системе, скажите, пожалуйста, меняются ли рандомно названия /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 такая же фигня, из чего можно предположить, что моя проблема где-то в настройках именно стандартной адвайты, но я даже не знаю, чего гуглить.

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

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

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

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

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

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

Dimez, что не так?

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

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

/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

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

Итак, решил глянуть как в гноме 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

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

Очередной раз тут листал федоровский фак (кстати, категорически рекомендую независимо от дистрибутива) и наткнулся на вот это, и вспомнил как же плохо живётся в 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 отменяются. Грустные дебияньшики и арчеводы расходятся несолоно хлебавши.

Меня и будучи на шапке эта проблема напрягала, что переход между скажем 8.2 и 8.3 делается простым dnf upgrade, но там есть механизм блокировки версии дистрибутива, например subscription-manager release --set=8.2, и пока не выключишь блокировку или не переключишь на 8.3, то он не обновляет репы и соответственно дистрибутив.

Ясное дело, что у клонов (у всех?) нет поддержки минорных версий, поэтому и не за чем на них останавливаться, однако предыдущие версии пакетов репозитории альмы не хранят, то есть в RHEL после обновления дистирубтива можно было хотя бы откатить ядро простым dnf downgrade kernel (меня это здорово выручило как раз между 8.2 и 8.3), а в альме такая команда бесполезна после обновления дистрибутива, ибо ядро из предыдущей версии уже исчезло из репозитория.

В общем ситуация с ядром не проблемная, как я понимаю, так как большие изменения происходят между релизами, а по ходу релиза только фиксят баги. Говорю не от знания, а по опыту, ибо сижу на EL с 8.2 (сегодня 8.7), поправьте, если не прав. Так же ясно — кто умеет пользоваться DNF и читает выхлоп перед апгрейдом в просак не попадёт, но хотелось бы не задумываясь дёргать dnf upgrade, а дистрибутив обновлять по своему желанию, ибо в этом и прелесть стейбла.

Как знатоки решают проблему?

Я вот затупил и поймал нежданчик в этот раз, переезжая с 8.6 на 8.7, расслабился, а там в месе поменяли драйвер с i965 на crocus и я получил слайдшоу в гноме (хорошо это произошло, когда не надо было работать…), а заодно и кдеешные проги улетели, так как epel завис с обновлением кед ещё на неделю или две.

Что касается epel & fusion, то отсутствие минорных версий репозиториев в общем не проблема, так как заявлено, что программа собранная для 8.0 будет работать без перекомпиляции и в какой-нибудь 8.10, но как всегда ИРЛ всё чутка иначе. Из недавнего, okular, который работал в 8.6 уже не работает в 8.7 — получите новый и распишитесь. Но вы скажете мол ясное дело — это же кеды, они даже в федоре обновляются внутри релиза. Да, но счастливее от этого мы не становимся.

Ладно, что имеем и что с этим делать?!

Дело в том, что файл /etc/yum.repos.d/almalinux.repo по умолчанию настроен на репозиторий под номером дистрибутива, например 8 или 9 (см.: https://mirror.yandex.ru/almalinux/), и именно в нём и происходит эта внезапная замена одного минорного релиза на другой, вот такой вот роллинг-перекати-поле.

По ссылке видно, что там есть ещё текущая версия и предыдущая, а более старые улетают в репозитории Vault. Остаётся перенастроить свои репы на текущий (или предыдущий, если ещё не обновился и тебе некогда) и тогда можно спокойно дёргать dnf upgrade, не опасаясь обновиться на следующий релиз по невнимательности.

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

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

Картинка: https://i.ibb.co/hCjFz9d/221120215118.png

Как-то можно от этого избавиться?

Самозабанился целый модератор a1batross

Матёрый же был, интересно, чё так?

Да и слово это что-то больше не слыхать.

Мы переросли vi vs emacs, linux vs freebsd, gnome vs kde, rpm vs deb, gpl vs bsd и т.д? Что стало с воинственным и бескомпромиссным линуксоидом?

Программисты там ещё что-то бодаются, но то уже не про линукс.

На ЛОРе популярна компьютерная метафора работы сознания, поэтому стоит познакомиться с альтернативной точкой зрения. Далее цитаты из книжки Полякова «Феноменология психических репрезентаций», из одноимённой с заглавием треда главы.

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

Основная идея когнитивной науки состоит в том, чтобы представить когнитивную систему в виде гигантского компьютера, выполняющего сложные вычисления. Подобно тому как компьютерные вычисления можно разбить на ряд более простых — сохранение, извлечение и сравнение символов или репрезентаций, человеческое действие можно разложить на элементарные психические компоненты. …Работу компьютера можно анализировать на различных уровнях: как на уровне технических устройств, где главная роль принадлежит микросхемам, так и на уровне репрезентаций и алгоритмов, где главное — это процессы и структуры данных; сходным образом когнитивную деятельность человека можно анализировать на уровне «устройств», то есть нейронов, и на уровне мысленных репрезентаций и процессов. Таким образом, представления об умственных действиях и уровне анализа являются краеугольными камнями когнитивной науки. <…>

Это по своей сути глубоко ошибочный, непродуктивный и тупиковый подход. Дело в том, что «работу компьютера» нельзя «анализировать как на уровне технических устройств, так и на уровне репрезентаций и алгоритмов», так как уровень «репрезентаций и алгоритмов» привносится в результаты работы компьютера не компьютерными механизмами, а внешним по отношению к компьютеру и не являющимся его частью человеческим сознанием. Компьютер не более чем физический инструмент, который сам является набором более простых физических объектов. Его функционирование заключается во взаимосвязанном изменении новых физических объектов — изображений на экране или иных носителях.

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

Считать, что «работу компьютера» можно «анализировать на уровне репрезентаций и алгоритмов», — примерно то же самое, что полагать возможным анализировать работу пишущей машинки на уровне технического устройства и на уровне репрезентаций, содержащихся потенциально в напечатанном ею авторском тексте. <…>

Следовательно, утверждение, что когнитивную деятельность человека можно анализировать на уровне «устройств», то есть нейронов, и на уровне мысленных репрезентаций и процессов так же, как работу компьютеров, — не просто спорное, но и весьма вредное, как и компьютерная метафора мозга и сознания в целом. <…>

<…> Пока что, как мне кажется, исследователям, придерживающимся этих взглядов, удается лишь неудачно подменять психические явления нейрофизиологическими понятиями и терминологией из смежных дисциплин: математики, информатики и т.д., что создает иллюзию большей «объективности», но не добавляет ни грамма ясности. Напротив, такая подмена окончательно запутывает даже изначально относительно понятные вопросы.

Такие дела, товарищи, ИИ отменяется :-)