LINUX.ORG.RU

X11Libre — свободный и независимый форк X.Org Server

 , ,

X11Libre — свободный и независимый форк X.Org Server

5

5

Представлен открытый проект X11Libre. Это форк X.org Server, нацеленный на проведение чистки кодовой базы и продолжение активного развития функциональности X.org.

По информации OpenNET, проект создал Энрико Вайгельт (Enrico Weigelt), мейнтейнер драйверов AMD FCH GPIO и VIRTIO GPIO в ядре Linux, мэйнтейнер Xnest и активный разработчик Xorg (1831 коммит за последние два года).

В анонсе проекта Вайгельт пояснил, что проект freedesktop.org не является независимым и контролируется компанией Red Hat, которая, по его мнению, специально тормозит развитие X‑сервера и пытается похоронить проект X11. Примечательно, что ранее Вайгельт подвергался критике со стороны Линуса Торвальдса за склонность к теориям заговора.

После действий, связанных с созданием форка и попыток привлечь внимание к возрождению работы над X‑сервером, Карол Хербст (Karol Herbst, сотрудник Red Hat и борец за инклюзивность в сообществе) заблокировал Вайгельту доступ к GitLab‑инфраструктуре freedesktop.org, удалил его репозитории и закрыл более 140 отправленных запросов на передачу изменений (изменения были не без претензий к качеству). В ответ Вайгельт пригласил всех желающих подключиться к разработке X11Libre на GitHub. По мнению Вайгельта, у сообщества есть интерес к продолжению развития X.org и за время искусственного сдерживания разработки у проекта X.org накопилось большое число не принятых изменений и улучшений.

Первый релиз X11Libre планируется опубликовать в ближайшие дни. Проект будет полностью независим, не связан с какими‑либо корпорациями или активистами и избавлен от любых дискриминационных политик, таких как DEI (разнообразие, равенство и инклюзивность). Любой, кто доброжелательно относится к окружающим и заинтересован в продвижении X11, может участвовать в работе.

В планах свежего релиза X11Libre:

  • Поддержка X11-расширения Xnamespace, обеспечивающего изоляцию клиентов через разделение на уровне пространств имён X11;
  • Перевод Xnest на XCB и исключение Xlib из зависимостей;
  • Возможность одновременной установки разных версий ABI для бесшовного обновления в дистрибутивах;
  • Проведение работы по избавлению кодовой базы от технического долга.

По информации от сообщества, ранее от Вайгельта поступали плохо протестированные изменения, которые, например, ломали работу xrandr и приводили к зависаниям. Другие разработчики были недовольны проводимой Вайгельтом чисткой кода, из‑за которой в master‑ветке X.org постоянно менялся ABI и возникали сбои со сборкой. В итоге, было предложено прекратить принимать изменения от Энрико, так как его деятельность по чистке кодовой базы не устраняла конкретных ошибок и не решала существующие проблемы, а создавала новые проблемы.

>>> Подробности

★★★

Проверено: hobbit ()
Последнее исправление: unfo (всего исправлений: 2)
Ответ на: комментарий от LongLiveUbuntu

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

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

Во-вторых, я тебе точно скажу, что я НЕ буду разглядывать на 4К-экране: пиксели. При диагонали экрана больше 17 дюймов, лучше иметь 4К, потому что у него пикселизованность выше, сглаживание шрифтов лучше и глаза меньше устают.

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

В общем, необходимость поддержки 4К это неоспоримый факт, нравится это фанбоям иксов или нет.

liksys ★★★★
()
Ответ на: комментарий от u5er

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

liksys ★★★★
()
Ответ на: комментарий от liksys

journalctl и гуи вокруг него справятся с этим лучше всего.

grep справится лучше,но для этого надо уметь им пользоваться. Обычно кто в юниксоподобных ОС давно - более-менее умеют. А чайникам да,остается только мышкой в гуй тыкать потому что эффективными приемами работы они не владеют. Особо выдающиеся чайники способны тыкать мышкой с впечатляющей скоростью. Но скрипты всё равно быстрее работают. И скрипты обладают свойством самодокументируемости. В отличие от движений мышки - типичная ситуация «я что-то нажал и всё пропало».

watchcat382
()
Ответ на: комментарий от liksys

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

Безусловно согласен и считаю «юниты» в systemd однозначно полезной штукой.

Плохо то что из systemd пытаются сделать некий универсальный комбайн. На днях узнал от приятеля что systemd оказывается может даже время на машине синхронизировать вместо привычного chrony или ntpd. Вот нафига это в systemd было пихать - не понимаю.

watchcat382
()
Ответ на: комментарий от liksys

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

Для схем нужно не столько 4К сколько большая площадь экрана. От схемы,втиснутой в физически маленький экран - толку мало. Ну только если перед экраном линзу ставить как у телевизоров КВН-49.

Пример реализации: https://www.ozon.ru/product/steklo-uvelichitelnoe-dlya-telefona-skladnoy-ekran-portativnyy-659837973/

необходимость поддержки 4К это неоспоримый факт

А что, в иксах 4K не работает что ли? Вроде как у них ограничение на количество точек 32767 х 32767.

watchcat382
()
Ответ на: комментарий от watchcat382

grep справится лучше

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

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

скрипты обладают свойством самодокументируемости

Не обладают, особенно регулярные выражения, которые еще надо прочитать и понять. При этом journalctl –since и –until сильно понятнее, чем регулярки для разбора дат, которые, кстати, могут быть разными в разных логах, ведь не все пишут логи через syslog.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от watchcat382

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

Ты неправильно понимаешь задачу systemd. Это не инит, а системный менеджер - средство для управления ресурсами ОС. И это не одна программа, а целая куча, которые написаны единообразно, реализуют определенные интерфейсы и могут, в том числе, работать независимо друг от друга.

Синхронизацией времени занимается не systemd, а systemd-timesyncd. Это отдельный бинарник, запускающийся со своими правами и разрешениями.

Настраивалка сети - systemd-networkd - вообще может работать отдельно от остального systemd.

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

Systemd дает возможность реагировать на события и запускать нужный софт правильным образом: ждать поднятия сети, требовать наличия определенного устройства в /dev или модуля ядра, требовать правильно установленного времени ДО запуска, а не как бог на душу положит. Или, скажем, запустить сервис, когда другой сервис будет готов обрабатывать запросы, а не просто запущен (у systemd есть специальный протокол общениями с сервисами, например, бд может запускаться несколько секунд, и только после этого проинформировать systemd о том, что она готова работать, и только тогда systemd запустит зависящие от бд другие сервисы).

Это всё возникло, как техническая необходимость, которую многие админы просто не замечают, потому что не лазают на низкий уровень инициализации ОС, где всю историю творился треш и угар, и все строили свои велосипеды, кто во что горазд. Если ты запускаешь максимум какой-нибудь LAMP (не в обиду, просто пример), то скорее всего тебе ничего из возможностей systemd не понадобится. Но когда ты сталкиваешься со сложным графом зависимостей и требований от сервисов, то быстро понимаешь, зачем нужен systemd.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от watchcat382

От схемы,втиснутой в физически маленький экран - толку мало.

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

А что, в иксах 4K не работает что ли?

Работает. Проблема в том, что если ты берешь два монитора с разным DPI, то иксы такое не прожуют. У меня ноут с 2K-экраном, ну вот такое железо. И при этом плохое зрение, поэтому мне нужно использовать масштабирование 1.5x. При этом я хочу подключить внешний экран с меньшей диагональю и 1080p, чтобы отнести туда отладчик, и у него не должно быть масштабирования вообще. Или другой монитор с 4K, у которого я хочу 2x. Дальше, разумеется, я захочу динамически переносить окна между ними. Так вот с вялендом окна будут масштабироваться в реальном времени под правильный скейлинг, а иксы так не могут вообще.

liksys ★★★★
()
Ответ на: комментарий от liksys

Много написал портянок то? И что будем делать с rc в других местах линупса? Надо заменить bash и vim на cmd.exe и блокнот, чтобы ты чувствовал себя как дома.

bread
()
Ответ на: комментарий от bread

Много написал портянок то?

Достаточно много, чтобы от них устать. А еще у меня есть проект из 19 микросервисов с разными требованиями и правами, суммарная длина юнитов для которых составляет всего 300 строчек INI-файлов. Для rc-скриптов это недостижимая величина с учетом необходимости выставления всяких странных капабилитисов и прав.

И что будем делать с rc в других местах линупса?

В каких?

Надо заменить bash и vim на cmd.exe и блокнот, чтобы ты чувствовал себя как дома.

Не юродствуй, а веди техническую дискуссию.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

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

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

В случае journalctl это уже написано и стандартизировано.

Что именно написано? Откуда авторы journalctl могу знать что требуется в работе в каком-то конкретном месте?

journalctl –since и –until сильно понятнее, чем регулярки для разбора дат

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

С чем работаешь под то и пишешь скрипты для обработки логов.

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

Что именно написано?

Типовые фильтры для постоянного применения. Смотри секцию FILTERING OPTIONS: https://man7.org/linux/man-pages/man1/journalctl.1.html

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

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

В случае с systemd/journald все логи будут бинарные. Сервис конфигурируется для вывода логов в stdout/stderr или в syslog, после чего journald всё это дело перехыватывает и единым образом записывает в свой бинарный лог. Дальше ты можешь их опрашивать обычным образом.

Существуют исключения, но они единичные, и для них есть собственные средства обработки логов, куда ты грепом, скорее всего, не полезешь: например нжинксовые access/error.log и самбовые логи. Для первого созданы тысячи спецсредств, а второе просто криво написано, имеет стопицот опций настройки логов и даже если ты всё переправляешь в syslog и stderr, он все равто что-то подсирает в /var/log.

Относительно поиска командой (не мышкой) через journalctl - могу с вами согласиться,вот только такое «хитрое» условие как в случае с грепом там не задать.

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

liksys ★★★★
()
Ответ на: комментарий от liksys

низкий уровень инициализации ОС, где всю историю творился треш и угар

С этим соглашусь.

Синхронизацией времени занимается не systemd, а systemd-timesyncd. Это отдельный бинарник

Вот я и удивляюсь - зачем ЕЩЕ один бинарник который делает то же самое что chrony и ntpd (их и так уже двое,и не факт что это полный список).

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

Согласен, возможность полезная. Но если бд может так взаимодействовать с systemd то что мешает научить взаимодействовать chrony и сообщать когда оно уже выставило правильное время? Зачем было еще один велосипед изобретать?

Вот насчет идеи инициализации сети - да, там,как минимум в Дебиане 11, нагромождение скриптов. И идея поручить это какому-то специальному процессу выглядит разумной. Хотя я не очень представляю как сделать декларативное описание инициализации в случае например радиомодемов,которые бывают сильно разными и требуют всяких специфических для конкретной модели модема «шаманских действий» например если хочется получить от сотового оператора одновременно и IPv4 и IPv6 адреса.

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

watchcat382
()
Ответ на: комментарий от liksys

Толк в том, что ты можешь оглядеть трассировку.

В том-то и дело что на физически маленьком экране я ее не огляжу - слишком мелко. Ну или ставить перед экраном линзу.

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

Про разный DPI нисколько не спорю. Но в исходном сообщении было написано так как будто иксы вообще 4К не поддерживают.

И при этом плохое зрение, поэтому мне нужно использовать масштабирование 1.5x.

Это не столько про плохое зрение,сколько про увлечение разработчиков интерфейсов слишким мелкими шрифтами. Имеет место быть аж еще с конца 90х годов. Более правильно было бы использовать в софте крупные шрифты,а те кто любит очень мелкие - ну и ставили бы себе масштабирование 0.5.

Кстати интересно, отличается ли картинка при масштабировании 1.5 от просто выставленного на мониторе в 1.5 раза меньшего разрешения,которое тоже даст укрупнение интерфейса? Есть ли разница - масштабировать картинку процессором компа или тем процессором который внутри монитора? У меня тут нет 2К монитора, проверить негде.

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

зачем ЕЩЕ один бинарник который делает то же

См. ниже.

Но если бд может так взаимодействовать с systemd то что мешает научить взаимодействовать chrony и сообщать когда оно уже выставило правильное время? Зачем было еще один велосипед изобретать?

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

Обычно глубинные фанаты юниксвея и юникса оный юникс сами в глаза не видели, и поэтому думают, что отход линукса от велосипедостроения - это зло и виндузятничество. А на самом деле, классический Solaris и суровый AIX буквально так и построены, в духе «собора», а не «базара». Знаешь, как в солярке поднимается сеть? ifconfig le0 dhcp start, который запускает демона. Всё интегрировано и связано, всё взаимодействует с соответствующими подсистемами, а не криво склеено скриптами со слипами.

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

декларативное описание инициализации в случае например радиомодемов

Точно так же как и с NetworkManager, там тоже используется декларативное описание. Я как раз в прошлом году интересовался, в networkd модемы еще не занесли, но работа ведется. Пока что рекомендуется использовать рядом NetworkManager+ModemManager, который управляет только одним указанным интерфейсом.

Вполне возможно что наведения порядка в инициализации системы приведет к сокращению дистро-специфичных скриптов и конфигов которые они читают.

Так уже. Сейчас все дистрибутивы с systemd работают плюс-минус одинаково. Есть всякие особенные, типа Debian, которые не до конца искоренили некоторые свои специфичные костыли (потому что они ближе к телу), но в остальном процесс идет. Мой софт отлично запускается как на арче, так и на том же дебиане, все 19 подсистем.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от bread

Много написал портянок то?

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

И что будем делать с rc в других местах линупса?

На лично мой взгляд не надо бы пытаться башем делать то,что по уму стоило бы сделать в виде полноценной программы на компилируемом языке, использующей конфиг,написанный в декларативном стиле. Вот сделали systemd и «юниты» - что, плохо что ли? На мой взгляд стало лучше чем та монстрообразная конструкция из «портянок» и символических ссылок на них которая была до этого. Да, когда-то давно,когда инициализация системы была очень простой - скрипты на шелле были в ней нормальны. Я лично видел как это выглядело в ОС ДЕМОС(русский потомок BSD) на СМ1600 более трех десятков лет назад. Но потом инициализация разрослась и усложнилась настолько что возникла потребность ее полностью переделать. Да, я тоже был не в восторге от «нарушения традиций» но в данном случае оно было вынужденным. Получилось не всё и не сразу, но заработало же в конце концов.

watchcat382
()
Ответ на: комментарий от watchcat382

В том-то и дело что на физически маленьком экране я ее не огляжу - слишком мелко. Ну или ставить перед экраном линзу.

Ладно, ты не можешь. Я тоже не могу. А у меня товарищ может, у него зрение - идеальная единица. Все сетапы нужны, все сетапы важны.

Про разный DPI нисколько не спорю. Но в исходном сообщении было написано так как будто иксы вообще 4К не поддерживают.

Вот оно что. Просто недопонимание, а тебе я не уточнил. Я по всему треду говорил про конфигурацию 2K-ноут плюс 4K-монитор, а местные шизоиды тру-юниксоиды говорили мне, что больше одного экрана НИНУЖНО, и больше 1080p НИНУЖНО ТОЖЕ.

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

Одними шрифтами тут не отделаться - интерфейс, иконки и кнопки тоже нужно масштабировать.

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

При масштабировании на софте используются разные алгоритмы. Если используется векторная графика, то картинка будет рендериться в масштабе без артефактов. Шрифты будут подгоняться под правильный размер. А при масштабировании на мониторе ты увидишь мыло, потому что с точки зрения монитора он получает сплошной растр и ему больше ничего не остается, как просто отскейлить его без учета сущности контента. В лучшем случае обработает через ИИ со всеми вытекающими последствиями.

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

За исключением отсутствия единичных протоколов про курсор и положение окон (они, кстати, в прцоессе реализации), всё отлично работает. У меня кеды и софт на Qt и GTK работают идеально. История с Kicad, кстати, показательна: окей, можно много спорить о том, профессиональный это инструмент, или нет, то то, что он плохо работает, течет и падает под вялендом - проблема Kicad wxWidgets, на котором он сделан, а не вяленда. в wxWidgets поддержка вяленного экспериментальная, а сами Kicad`овцы просто перекладывают свои проблемы на других.

liksys ★★★★
()
Ответ на: комментарий от watchcat382

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

Я тебе больше скажу, если посмотреть на man inittab из классического SysV, то становится ясно, что инит уже тогда начал превращатсья в некое подобие systemd, на что ясно указывают ключевые слова powerfail и powerwait, являющиеся спецтриггерами для обработки событий питания, ну и остальное тоже. Просто инит - это такая часть, которую всегда можно было закостылить башем, и это худо-бедно работало, пока гора технического долга не заставила, наконец, кого-то пошевелиться.

Разные дистрибутивы пытались по-всякому наводить порядок: там и start-stop-daemon для стандартизации запусков, и openrc, и runit, и upstart. Много чего было, но в конечном итоге только у шапки нашлись деньги на разгребание эти авгиевых конюшен, чтобы сделать systemd.

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Типовые фильтры для постоянного применения.После оных типовых фильтров ты можешь подставить греп

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

journalctl, он ускоряет работу многократно

Что ускоряет - готов поверить. Что многократно - очень сильно сомневаюсь. И какого размера должны быть логи чтобы это ускорение стало реально существенно? Особенно учитывая что те сервисы которые действительно могут много понаписать (как вышеупомянутый access.log от веб-сервера) - пишут всё равно в свой отдельный лог который типично анализируется специальными тулзами.

исключает создание своих велосипедов.

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

Существуют исключения, но они единичные, и для них есть собственные средства обработки логов, куда ты грепом, скорее всего, не полезешь: например нжинксовые access/error.log и самбовые логи.

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

В случае с systemd/journald все логи будут бинарные. Сервис конфигурируется для вывода логов в stdout/stderr или в syslog, после чего journald всё это дело перехыватывает

За другие линуксы не скажу,но вот у меня тут в Дебиане 11 несмотря на наличие journald с его бинарными логами - пишется туда совсем не всё. Часть того что я устанавливал - пишет обычные текстовые логи. То есть это дистростроители так сконфигурировали.

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

акого размера должны быть логи чтобы это ускорение стало реально существенно?

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

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

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

Так в том-то и дело что не исключает.

Вот том-то и дело, что исключает. Просто с оговоркой: для большинства задач. А значит его уже стоит использовать. Я тебе больше скажу: есть типовые запросы, которые ты можешь выполить с journalctl, но для syslog тебе придется костылять велосипед: запрос логов юнитов по регекспу. Например, «дай мне логи сервисов foo* за сегодняшний день», который покажет тебе сплошной вывод оных сервисов, сообщения которых будут идти рядом друг с другом, чтобы ты увидел корелляцию их взаимодействия.

В том-то и дело что не «единичные»,а как раз любой крупный сервис,который пишет свои логи примерно всегда.

Нет, это буквально единичные исключения. У тебя на системе запущена (или ожидает запуска) херова гора разных подсистем, и все они пишут свои логи. Ядро, udev, logind какой-нибудь, kwin, что угодно. Для логов больших сервисов же существуют специальные инструменты, которые удобны именно для анализа, а не для рядового администрирования. И их тоже можно собирать через journald, кстати.

То есть это дистростроители так сконфигурировали.

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Затем, что миллион велосипедов, и с каждым нужно взаимодействовать.

Ну так взаимодействуют же с какими-то БД,которых тоже больше чем одна. А вот chrony почему-то не повезло - с ним взаимодействовать не хочут и изобретают свой велосипед. Я именно об этом «неравноправии» говорил.

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

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

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

в networkd модемы еще не занесли, но работа ведется. Пока что рекомендуется использовать рядом NetworkManager+ModemManager

Я,имеющий последние полтора десятка лет основное подключение через радиомодемы, пока предпочитаю не использовать ни то ни другое. Нужные команды пишутся в текстовые конфиги pppd и chat которого он используется для передачи AT-команд модему, и всё отлично работает. Демон pppd запускается из самописного юнита. Сам pppd запускает определенные скрипты когда соединение будет установлено. В них делается то что должно быть сделано после установления соединения. (да, костыль). Вот если когда-то доделают networkd - можно будет попробовать как он будет с pppd взаимодействовать и можно ли будет вместо вышеупомянутых скриптов написать ему декларативные конфиги.

watchcat382
()
Ответ на: комментарий от watchcat382

Ну так взаимодействуют же с какими-то БД,которых тоже больше чем одна. А вот chrony почему-то не повезло

Ты сравнил, конечно, базу данных и сервис подстройки часов. Конечно, в systemd им было проще переписать его с нуля, чтобы он использовал их разделяемые библиотеки, API и был встроен в экосистему.

но не думаю что это реально для всего что может использоваться.

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

Что до системных задач - их на самом деле не так много, потому что это ограничено физическими ресурсами, предоставляемыми машиной: часы, сеть, tmpfs в памяти, и так далее. Вот для всех них и понаписаны соответствующие сервисы, помогающие получить к ним доступ.

поспешили с внедрением systemd,у которого первые версии были весьма глючные

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

Вот если когда-то доделают networkd

Если мне не изменяет память, его интегрируют с ModemManager, потому что он скрывает кучу вот этой chat-херни. Вот у меня есть пример, как я настраивал у себя тут модем: https://docs.pikvm.org/modem

liksys ★★★★
()
Ответ на: комментарий от liksys

А у меня товарищ может, у него зрение - идеальная единица.

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

Все сетапы нужны, все сетапы важны.

Безусловно согласен. Но я говорил немного о другом,о том что сделать «по умолчанию». Так вот лучше бы по умолчанию шрифты были крупными,а кому надо мелкие - ставили бы x0.5 или сколько им там надо.

При масштабировании на софте используются разные алгоритмы. Если используется векторная графика, то картинка будет рендериться в масштабе без артефактов. Шрифты будут подгоняться под правильный размер.

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

Но вы упоминали некий «общесистемный» коэффициент 1.5, и я так понял что вы бы хотели поручить масштабирование графическому серверу.

А при масштабировании на мониторе ты увидишь мыло

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

У меня кеды и софт на Qt и GTK работают идеально.

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

проблема Kicad wxWidgets, на котором он сделан,

сами Kicad`овцы просто перекладывают свои проблемы на других.

Странная логика - глюки в Kicad из-за wxWidgets,но проблемы почему-то перекладывают разработчики Kicad. Логичнее было бы ругать разработчиков wxWidgets. Но что с этим делать - не очень понятно. Если переписать Kicad на что-то другое то скорее всего пострадает его мультиплатформенность. Хотя вот например Gimp использует GTK (но вроде какой-то свой вариант) и работает как под линуксом так и под виндами. Да и переписывание такого крупного продукта под другой тулкит - это задача титаническая,на годы.

watchcat382
()
Ответ на: комментарий от liksys

инит уже тогда начал превращатсья в некое подобие systemd, на что ясно указывают ключевые слова powerfail и powerwait

Согласен. И еще запуск getty оттуда же из конфига.

watchcat382
()
Ответ на: комментарий от liksys

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

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

Вот если когда-то доделают networkd

Если мне не изменяет память, его интегрируют с ModemManager, потому что он скрывает кучу вот этой chat-херни.

А скрывать как раз и не надо. Надо иметь возможность отдавать модему произвольные AT-команды. Например как часто востребованная - выбор диапазона. Потому что 1800 МГц как обычно забит телефонами,а на 2100 МГц сигнал чуть слабее и модем сам туда не идет,хотя диапазон более свободен, важное для LTE отношение сигнал/шум лучше и скорость выше. А команда выбора диапазона для разных модемов разная. Будем надеяться что эти особенности учтут и не «скроют» их так что это будет невозможно настроить.

Вот у меня есть пример, как я настраивал у себя тут модем

Спасибо, с интересом ознакомился. Но насколько я понял вы настраивали модем в режиме имитации сетевой карточки. Это хуже чем обычный вариант работы с pppd так как не все модемы хорошо обрабатывают разные сложные ситуации в эфире. К примеру многие usb-модемы при помехах могут впадать в состояние «соединение есть но трафик не идет». И pppd сам обнаруживает и разруливает такую ситуацию, отправляя модему нужные для перезапуска и/или перерегистрации в сети команды. Нет, не ATZ как многие могут подумать,она из этого состояния радиомодем не выводит,в отличие от модемов телефонных. А вот промышленный модем от Quectel умеет выходить из такого состояния сам,через некоторое время,около минуты.

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

вы бы хотели поручить масштабирование графическому серверу

Из-за разницы в терминологии не все понимают, чем именно является вяленд. Если раньше у нас были иксы, с которыми тулкиты коммуницировали по протоколу X11, и которые дальше условно общались с железом через ядро, то теперь у нас есть kwin (или другой композитор, играющий роль иксов), с которым тулкиты коммуницируют по протоколу Wayland. Роль иксов в итоге сводилась к простому рисованию растра и менеджменту окон, а поскольку KDE и все остальные и так уже содержали кучу оконной логики, то было логично выкинуть иксы совсем. То есть, роль графического сервера теперь выполняет kwin. В других DE аналогично. А для устройств ввода теперь есть libinput.

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

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

надобность в существовании более простых тулкитов

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

Ибо сложность GTK и особенно Qt слишком велика.

Это вообще не так. Я не пишу на плюсах, только на сях, но при этом я осилил Qt, потому что он использует собственные велосипеды и ограниченные подмножества плюсов, и имеет отличный туториал. А еще есть PyQt. Вот там вообще всё тривиально, даже на Tkinter сложнее что-то вменяемое написать.

Когда что-то им подобное появится под вейланд - неизвестно.

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

Странная логика - глюки в Kicad из-за wxWidgets,но проблемы почему-то перекладывают разработчики Kicad. Логичнее было бы ругать разработчиков wxWidgets.

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

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

Почему-то приложения Qt отлично работают и на иксах, и на вяленде. Что мешало почесаться и сделать так же в wx/kikad - непонятно.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 3)
Ответ на: комментарий от watchcat382

А скрывать как раз и не надо. Надо иметь возможность отдавать модему произвольные AT-команды

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

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

liksys ★★★★
()
Ответ на: комментарий от ptah_alexs

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

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

UPD: Ты же уже приходил с этой чушью в этот тред, и я уже говорил тебе, что масштаб != DPI. Зачем продолжать тиражировать небылицы?

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 3)
Ответ на: комментарий от liksys

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

Только тут дело не в маргинальных тулкитах, а в отсутствии единого API настроек UI. И вяленый эту проблему тоже не решает.

u-235
()
Ответ на: комментарий от u-235

Строго говоря, это и не его проблема. Но побочным эффектом от внедрения будет вымирание велосипедов.

liksys ★★★★
()
Ответ на: комментарий от u-235

И ещё нюанс - есть разделение C и C++/любая объектная хрень. В первой группе, простите, xlib, motif и gtk; во второй - всё остальное. Переезд с gtk на qt - это написать почти всё с нуля. Ну и я не знаю, насколько сейчас легко говнокодить под g++ - 30 лет назад было легко мешать в кашу .c и .cc и конпелять и всё конпелялось. И падало (но не сразу). (по опыту GMOME 0.xxx)

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от u-235

в отсутствии единого API настроек UI

xresources же!

Shadow ★★★★★
()
Ответ на: комментарий от liksys

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

u5er ★★
()
Ответ на: комментарий от u5er

перезапуск упавших сервисов есть не только в системд

Да, и про один из них я писал выше - monit. Не нужно выдавать мои тезисы за свои, пожалуйста.

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

Ага, «лор» - один из них.

liksys ★★★★
()
Ответ на: комментарий от liksys

Да, и про один из них я писал выше - monit. Не нужно выдавать мои тезисы за свои, пожалуйста.

Ты написал про monit, а я про runit. В каком месте я свои тезисы за твои выдаю? Если ты клоуна хочешь получить, то просто прямо напиши об этом xD

Ага, «лор» - один из них.

Не уверен. Тут была тема, которая называлась «Коллекция критики systemd». В ней в шапке был дан список ссылок на аргументы против системд. Теперь её нет.

u5er ★★
()
Ответ на: комментарий от u5er

В каком месте я свои тезисы за твои выдаю?

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

Если ты клоуна хочешь получить

Не юродствуй.

Тут была тема, которая называлась «Коллекция критики systemd».

Вот вторая часть, и в ней ссылка на первую от автора. Вероятно, у тебя фантомные воспоминания: Коллекция критики systemd 2

Теперь её нет.

Происки красношапки, не иначе.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

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

И?

Вот вторая часть, и в ней ссылка на первую от автора. Вероятно, у тебя фантомные воспоминания: Коллекция критики systemd 2

Это не та тема. Та была оформлена как эпические треды - был список ссылок.

u5er ★★
()
Последнее исправление: u5er (всего исправлений: 1)
Ответ на: комментарий от liksys

теория заговора.

Так я этого и не утверждал.

u5er ★★
()
Ответ на: комментарий от liksys

Зачем продолжать тиражировать небылицы?

Потому что могу? И вообще какая разница если задача будет решена через dpi, а не через масштаб.

ptah_alexs ★★★★★
()
Ответ на: комментарий от liksys

Я не хочу пердолиться с модемом

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

вставил симку - и оно само работает.

Работает,пока антенна базовой станции в пределах видимости. Уже в десятке километров от БС - всё не так просто.

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

Ну, будем надеяться что сделают нормально. Только подозреваю что в случае модемов это очень не скоро будет.

watchcat382
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)