Есть у меня Thinkpad W510, который не хочет умирать, и вполне юзабелен даже по меркам 2022 года. Ну так вот, я накатил на него Fedora 35, минимальный вариант. А он взял и не смог загрузиться.

При этом netinstall-образ запустился и установил систему вполне себе нормально.

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

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

Ну и вопрос недели: как это зарепортить, чтобы не закрыли с NOTABUG WONTFIX FUCKYOU?

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

Этот рак даже здесь есть, вот в соседней теме кто-то пишет LINUX большими. Как это расшифровывается? LINUX Involves Nasty User eXperience? Что, серьезно?

Или вот например, даже некоторые программисты на Perl пишут его название как PERL.

Зато, кажется, писать UNIX стало такой традицией, что даже отрубанием рук не переучишь писать Unix. Вот потому что пару раз так в журнале «Радио» за 1980-е годы написали, так и повелось.

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

Мне всегда кажется, что те, кто пишут PERL, JAVA, UNIX, LINUX, сидят и стилусами эти буквы выводят, старательно так, языки высунув, как старикашка Эдельвейс латинские названия в свою эвристическую машину.

Купил на барахолке старый Thinkpad x230. Так, чтобы поковыряться, ничего серьезного. А в нем кнопка питания не работает, и кнопки от клитора тоже.

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

А так еще на карантине неделю гнить, вот досада.

Обьясните, мне, пожалуйста, за такие вещи:

1. у меня экран HiDPI (3840x2400). Все внешние экраны тоже. Как сделать, чтобы приложения в XWayland тоже были HiDPI, а не масштабированное LoDPI? Запуск сервера XWayland во всех современных средах почему-то прописан глубоко в кишках, и даже неизвестно, существует ли такой параметр вообще. А мне всего-то надо, чтобы приложения XWayland запускались с логическим разрешением таким же, как и физическое.

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

2. Почему-то курсор мыши вдвое больше, чем надо (96 вместо 48), и я без руля, где это прописано и где это изменить.

3. pam_kwallet5 или как там его прописан в pam.d и открывает kdewallet, судя по логам, успешно, но приложения почему-то хотят его открыть еще раз. Бесит жутко.

4. а как убить все-все-все настройки плазмы и ее приложений, чтобы начать с чистого листа? Вот чтобы не убивать весь .config. А то у меня не получается. Хотел посмотреть, может, гигантский курсор связан с какой-то настройкой полетевшей, а ее искать стремновато в толпе файликов.

KDE/Plasma последнейшие, Fedora 35.

На машине запущена плазма 5.22. С какого-то перепугу запущен также демон xfconfd, как сервис DBus org.xfce.Xfconf. Я вижу его только в /usr/share/dbus-1/services, при этом ни один из рядом лежащих сервисов не запущен. В моем .config и .local отсылки к сервису отсутствуют.

systemctl --user status говорит такое:

● dbus-:1.2-org.xfce.Xfconf@0.service
     Loaded: loaded (/run/user/1000/systemd/transient/dbus-:1.2-org.xfce.Xfconf@0.service; transient)
  Transient: yes
     Active: active (running) since Wed 2021-07-14 12:46:47 CEST; 3h 28min ago
   Main PID: 4397 (xfconfd)
      Tasks: 3 (limit: 38257)
     Memory: 1.0M
        CPU: 8ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus\x2d:1.2\x2dorg.xfce.Xfconf.slice/dbus-:1.2-org.xfce.Xfconf@0.service
             └─4397 /usr/lib64/xfce4/xfconf/xfconfd

Как найти, почему система считает нужным запускать это на плазме, и как это вырубить? Или берется первый попавшийся провайдер dconf/xsettings для настройки программ на GTK+?

И тут начинается плач, чтобы авторы поудаляли из CPAN старые релизы.

http://neilb.org/2021/05/10/delete-your-old-releases.html

Воспроизводимые сборки? Ха! В более новой версии модуля регрессии? Трижды ха! Админы CPAN’а не ожидали, что мертвый перл еще не перестал шевелиться и что у модулей, внезапно, будут новые релизы? Ну, лолкек.

Неужто скрипт, мониторящий место на диске, отвалился из-за нехватки места на диске? Или звоночек о том, что надо искать машину помощнее и диск побольше, не зазвонил, когда места было еще 30% с трендом на уменьшение?

Или драма вокруг Perl 7 и вся вот эта свистопляска вокруг обиженок и королев драмы поглотила умы админов с сивыми тестикулами?

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

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

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

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

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

Кто-нибудь пробовал такие?

Столлман вернулся в совет директоров FSF:

https://linuxreviews.org/images/f/f4/Unjust_computing_clamps_down.x264.lq.mp4

Для тех, кто не любит видео, есть текст: http://techrights.org/2021/03/21/richard-stallman-is-coming-back-to-the-board-of-the-free-software-foundation-founded-by-himself-35-years-ago/

Извините, я опять с «все не как у людей сделано».

У меня в системе есть два-три варианта загрузки ядра, каждый со своим набором параметров ядра. И вот оказывается, что в федоровской системе сделать так, чтобы каждое ядро содержало в GRUB подменю с этими вариантами, один из которых грузится по умолчанию — есть неподъемная задача. То есть, она подъемная с большим трудом, если разобраться в вермишели скриптов на shell (ну епт, идет же в каждой системе по умолчанию невыдираемый perl или python), но при этом решения не выдерживают обновлений ни GRUB’а, ни ядра.

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

А есть какой-нибудь другой загрузчик, в котором это реализовано? Мне в принципе EFI-only хватит. Хорошо, если с обновлениями ядер меню тоже будет обновлено.

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

Во-первых, время постройки. Делаешь малейшие изменения, пересобирается весь модуль целиком. Первых 60 пакетов собралось без проблем, проблема в 61-м — не гребет, пересобираем весь модуль. Что-то не понравилось в файле yaml? Пересобираем все. Я тут хотел как бы чуть сэкономить на таких циклах.

Во-вторых, метаданные для модульности. То ли только mbs-manager может их добавить таким способом, что это будет работать, то ли что, но createrepo_c тоже добавляет эти метаданные, правда, так, что потом ничто не ставится.

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

Вот вам сказочка.

«Это ж домашняя файлопомойка», говорили.

«JBOD на домашней файлопомойке хватит за глаза», говорили.

«Зачем мучаться с RAID», думал топикстартер, да и сделал JBOD на LVM2.

А потом диск, на котором были почти все на тот момент данные, взял да и посыпался. Его никто не просил, просто это был диск Seagate.

Хорошо, что наиболее ценные данные, которые есть только у топикстартера, были скопированы кое-куда еще. Не самый надежный бекап, но он есть.

Теперь у топикстартера LVM2 поверх RAID1, сделано за пару минут.

«Почему я тогда думал, что с RAID надо мучаться?», думал он.

Морали у сказочки нет.

Баю-бай, лорчик.

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

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

Ну и все это с минимальным участием с моей стороны, разумеется.

Причина — в COPR qt5-qtwebengine, например, собирается 12 часов, а у меня локально — полчаса. И он там не один такой.

Есть на это готовые решения или надо самому городить костыли?

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

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

А потом на десктоп оно переносится через облакохранилище, тоже не самое удобное решение.

С другой стороны, сканеров, нормально работающих с линуксом, раз-два и обчелся. У меня есть МФУ от Xerox (на самом деле Samsung), который при работе с SANE с их закрытым старым драйвером виснет и перезагружается, если параметры сканирования отличаются от «300 dpi ч/б».

Потом я читаю о ручных сканерах, которые работают от батарейки и пишут PDF либо JPG на карту microSD, что вообще зашибись, ибо совместимее некуда, но судя по отзывам, практически все, что на рынке есть, работает как кал.

Ну и наконец, в 2020 просто не хочется брать flatbed. Есть что-то нормальное, что блин берешь, включаешь, и оно нормально работает без танцев с бубном? С принтерами раньше были проблемы, а наконец изобрели driverless. Почему бы так со сканерами не это самое?

Ну в принципе, мне все в packaging guidelines понятно, да и спек на пакет написан до меня. Но когда я пробую натравить на него rpmbuild, он ругается на меня, что у меня нет множества пакетов типа

(crate(some-library/default) >= 1.0.0 with crate(some-library/default) < 2.0.0)

dnf таких выражений не понимает (ни полностью, ни crate(some-library/default)). Пакеты типа rust-some-library-devel+default.noarch.fc32.rpm существуют, даже в репозитории есть, но только если знаешь точный URL. dnf их не устанавливает. Более того, dnf build-dep бодро рапортует, что все зависимости установлены (на самом деле нет).

Федоровцы, ау, как вы собираете растопакеты?

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

А тут теперь развелось относительно доступных устройств, уже даже не слишком новых, типа Logitech Brio, но оказывается, хрен ты под линуксом застримишь 4к. Хрен ты используешь аппаратный H.264 в камере. Потому что это USB Video Class 1.5, а в линуксах только 1.1.

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

Тут такая вот статья.

https://nibblestew.blogspot.com/2020/05/you-have-to-kill-your-perlings.html

TL;DR — количество программистов, знающих и хорошо понимающих Perl, неуклонно уменьшается. Новых сколь-нибудь значимых проектов на Perl, создаваемых людьми моложе 35 лет, нет вообще. Поэтому авторам даже очень живых проектов, у которых в обвязке есть скрипты на перле, стоит сильно задуматься, а не переписать ли их к чертям на более популярные/поддерживаемые языки.

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

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

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

Это — перл через 20 лет, когда все, кому он был интересен, помрут либо состарятся настолько, что им будет все равно.

Еще один проект, который приподнял веки в 2020 году и обнаружил себя на задворках — GNU Emacs. Вот замечательнейший тред: https://lwn.net/ml/emacs-devel/8wXYP4GY9hwW-9mYv6_LGMETZ8Vz3Ob1Bec6yh6kPT7yxjTkxA3V6dXY4ELra9tYiJUxJmgXKSIEX4w8HFiPRoeGVSQHDSoBVy1voj1e3Qo=@protonmail.com/

Там много дискача, вот более-менее интересное: https://lwn.net/ml/emacs-devel/CAH=MJ4Yu0_ZLzm-W1-+i4JNh0PLSdNUGOxrzCkPjwtZ55EDEyg@mail.gmail.com/

«[…] нет пользователей Microsoft Word, которые бы говорили, что открывают «буферы». Они открывают «файлы». Они перемещают «окна», а не «рамки». Они вырезают и вставляют, а не kill и yank и т.д.

По сути, [пользуясь Emacs,] вы берете на себя обязательство быть или стать опытным пользователем. Я бы, конечно, не смирился с этим, если бы не думал, что это сэкономит мне много времени как разработчику программного обеспечения (а это так, каждый день). Я сомневаюсь, что кто-нибудь вложит ментальные усилия, чтобы справиться с изучением Emacs в наши дни, если только это не является его целью. Если вы просто хотите заниматься «случайным» редактированием текста Emacs - это очень странный выбор в 2020 году.»

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

У меня любовь всей жизни — WindowMaker, всегда к нему возвращаюсь. Он прекрасен своей простотой, а также тем, что примитивы использования у него взяли то лучшее, что есть в macOS (корни-то одни, если не в реализации, то в идее).

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

Но потом я обзавелся Retina-дисплеями, и WindowMaker оказался к этому неготов.

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

Но теперь и гномьи сервисы (мне нужно от них управление клавиатурой, интерфейсом GTK-приложений, звуком, и кой-чего по-мелочи) изменились, и теперь более приспособлены к работе с systemd.

Я долго смотрел в конфиги, как это сделал гном, и мне вот непонятно ничегошеньки. Раньше мне казалось, что вот есть user.target, и он запускается в сессии. Оказалось, не все так просто, каким-то образом гномьи юниты запускаются только при старте гнома. Переключаюсь в другую сессию, и их там нет. Как система различает, какие таргеты включить вот прям щас? Как объяснить gdm, что вот сейчас я хочу другой набор, специально для WindowMaker?

Кастую intelfx. Ненужнаторы могут идти в топку.

Последних 8 лет использую исключительно ноутбуки. Самый мощный имеет внутри i7-7820QM.

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

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

Я не понимаю, кто может хотеть читать такое говно. Но читают же, коль скоро они ещё существуют.

Спасибо, что пришли на мой TED talk.

Потому что с опенсорсным amdgpu жизнь — это боль. Например, есть Dell Precision 7520 с Radeon WX4150 внутри. По некоторым причинам у меня выставлен прямой вывод из карты AMD на все внешние порты: ну там DisplayPort, HDMI, какие порты еще есть на доке Thunderbolt.

И вот я хочу подключить два 4K-монитора. Плевое вроде дело, это прекрасно работает на интегрированной Intel UHD620. Но нет.

Если я подключаю оба монитора через порты DisplayPort на доке (WD19TB), не работает ни один. Если один монитор подключить по DisplayPort в самом ноуте, а второй через док, то второй монитор получит частоту 30 Гц, и вся картинка будет рисоваться оооооччччеееенннннььььь ммммееедддллленннноооо (как при тормозах на Windows 95, если вы помните, о чем я). В логах ядра сплошные таймауты на различных функциях из драйвера.

Если пробовать отключать power management и т. п., все еще хуже, так как ядро паникует еще при загрузке.

В спецификации на ноут декларируется, что он способен спокойно держать один свой дисплей (тоже 4К) и даже монитор 8К, подключенный к порту mDP. Охотно верю, что под вендой это будет работать, хотя венды, чтобы это проверять, у меня нет.

В багтрекере на https://gitlab.freedesktop.org/drm/amd/issues 745 открытых багов, добрая половина о зависаниях, ни одно из них не происходит в том же месте, что на моей системе.

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