Gentoo будет по умолчанию ставить PipeWire на десктопах

Чукча не читатель, у чукчи подгорает! Я на этот счёт вполне однозначно всё сказал, но ты же не можешь молчать и не врать.

У systemd есть очень мощный механизм

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

Да и ещё не раз видел аналогичную логику.

В том и дело, что оно не отключается. Оно убирается из автозапуска, а это совсем другое действие. Могла бы быть команда noautorun например для этого. А настоящее disable это то что в системг делает mask. В данном случае претензия терминологическая, но это всего лишь один из примеров того что в системг всё не так как надо.

PR свой покажешь?

Чтобы улучшить системд надо применить к его репе патч Бармина.

Ресемплер там и так уже есть и работает вероятно лучше чем юзерспейсный

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

Про DSP эффекты я ничего не говорил.

2026 на календаре, куда без них то? Это задача, которую решает pipewire вообще-то (и еще некоторые юзерспейсные решения, но не кернел-спейсные же).

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

Этот api есть уже лет 50, называется юникс сокет. И его использует пульса и pipewire как раз.

И кстаи, а bpf-подпрограммы тоже роняют ядро?

Ну ты блина и сравнил, хомячковый звуковой сервер и систему трассировки событий в ядре! Классический фаллос с пальцем. Для отладки, да, можно что угодно. А для того чтобы послушать Руки Вверх, руки от ядра лучше держать подальше. Даже если 18 мне уже.

Да и ещё не раз видел аналогичную логику.

Покажи мне инит с аналогичной логикой.

Если при этом нагрузка на цпу высокая то и пощёлкивания вполне могут объясняться микрофризами в процессе.

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

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

Чукча не читатель, у чукчи подгорает!

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

не врать.

Ну-ка, клоун, оправдай свое вранье, почему же systemd ничего не знает о замаскированных юнитах?

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

Это ты о чем вообще? Какой именно ресемплер есть в ядре linux,

Запусти в двух окнах

aplay -r 20000 /dev/urandom
aplay -r 7000 /dev/urandom

2026 на календаре, куда без них то? Это задача, которую решает pipewire вообще-то (и еще некоторые юзерспейсные решения, но не кернел-спейсные же).

Мало ли какое ненужно в эту прокладку всунули? Эффекты в подавляющем большинстве случаев не нужны. Никакие.

Этот api есть уже лет 50, называется юникс сокет. И его использует пульса и pipewire как раз.

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

Никто из хейтеров systemd и вяленда по-настоящему не понимет, как работают systemd, вяленд, иксы и sysv. Вообще.

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

В инитах этот функционал могут реализовывать запускаемые ими демоны.

Нет. sd_notify позволяет передавать гораздо больше статусов, чем просто готов/не готов.

Встроенного в традиционном ините нету, да.

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

Нужен ли он именно встроенный - вопрос неоднозначный.

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

Нет, наврал сейчас ты. В systemd, максимум, вовсе не «изобрели механизм применительно к иниту», а «заимствовали уже известный механизм себе в инит». Впрочем, были ли они первые я не знаю - есть же и другие нетрадиционные иниты (runit, upstart, итд).

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

Нет, наврал сейчас ты.

Нет, наврал именно ты. Мы говорили про иниты. До systemd этот известный механизм в инитах не применялся. То, что ты вспомнил о чем-то похожем - совершенно не играет никакой роли.

когда надо любые запуски/остановы/монтирования/размонтирования/итд не просто делать, а ещё и подгонять под них формальное описание текущего состояния инита

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

Эффекты в подавляющем большинстве случаев не нужны. Никакие.

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

Не отдавать fg управление назад пока демон не начнёт работать.

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

Вот у тебя есть демон. Он то запустился уже, всё ок, соединения принимает. Но данные не загрузились из БД, допустим. Поэтому часть данных, например, не отрисовывается. Или отрисовывается, но кэш не прогрелся, поэтому отрисовывается медленно. Для 1 пользователя это ничего страшного. А 1000 параллельных пользователя могут поставить этот демон в ракообразное состояние. Именно для этого и сделали эти сигналы. Нет, естественно, у меня очень давно уже написаны скрипты, которые делают закат солнца вручную. Но почему у тебя это вызывает такое отторжение, когда это можно делать централизовано и через единый API? Дожил до такого возраста, что непонятное начинает пугать что ли?

Дожил до такого возраста, что непонятное начинает пугать что ли?

Или наоборот: такой молодой, а уже столяров.

Ты имеешь ввиду что этот демон будет иметь состояния «ещё совсем не готов», «готов но лагаю» и «полностью готов»? Ну, может быть.

Но почему у тебя это вызывает такое отторжение, когда это можно делать централизовано и через единый API?

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

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

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

где-то нужна, где-то нет

Естественно. Но уметь ее нужно, потому что где-то она именно нужна.

я только писал что это не какой-то огромный прорыв

Это прорыв для системы инициализации - стандартизированное API для интеграции в систему. Раньше такого не было: было угадывание статусов по косвенным признакам и индивидуальные костыли на баше под необходимые сервисы.

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

Это твоё исключительно личное мнение, а не аксиома.

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

где-то нужна, где-то нет

Уже прогресс :))

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

Да даже если это не косвенный признак, а определённая строчка в логах, всё равно парсить логи на предмет этой строчки в костыле с циклом while ... sleep 1 - удовольствие ниже среднего…

вяленд работает через юникс-сокет, как и иксы

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

Если я напишу адову лапшу с багами в каждой строчке, но там будут юникс-сокеты и прочая дрисня, по которой фанатеют луноходы, то я буду молодец?

Будешь. Потому что это будет достижение персонально для тебя, и сейчас лучше ты не напишешь при всем желании.

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

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

Знаешь, никогда не задавался этим вопросом подробно потому что при использовании голой альсы с этим никогда не возникало проблем. Загуглил по-быстрому и нашёл: https://habr.com/ru/sandbox/30478/ упоминается что а альсе он таки есть, Теоретический вопрос по ALSA и ресемплингу. упоминается что он часть альса-либ, т.е. подключается к приложению и работает юзерспейсно. Почему бы не продолжить пользоваться этой схемой, если она 20 лет как работает без накладок?

2026 на календаре, куда без них то?

Всем... а собственно чего? Без каких таких эффектов нельзя жить в 2026 году?

Это задача, которую решает pipewire вообще-то

Ну ОК, если ядерная альса и юзерспейсный альса-либ может согласовать между собой ресемплинг и даже где то там прочитать его настройки из конфига, то что мешает в тот же api добавить ещё 1-2 вызова для подключения туда же нужных DSP-плагинов?

систему трассировки событий в ядре!

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

А для того чтобы послушать Руки Вверх, руки от ядра лучше держать подальше. Даже если 18 мне уже.

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

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

Примерно это и значит. Хреновые алгоритмы которые где то чего то не успевают.

Лечится переключением на другой способ шедулинга, на системах где проявляется, эта проблема.

До сих пор было проще снести чем разбираться. Особенно на фоне нулевой нужности.

Но по умолчанию этого не бывает включено,

Я про многое в Арче думал «ну так просто не бывает по умолчанию»...

Gentoo будет по умолчанию ставить PipeWire на десктопах (комментарий)

А вот тут будет сложно для контуженных танкистов, но если добавить в контекст 2 предыдущих сообщения в цепочке, то я указываю на то, что «просто включить чтобы заработало» не удалось Gentoo будет по умолчанию ставить PipeWire на десктопах (комментарий)

и работает юзерспейсно

Ресемплер в ядре, но работает юзерспейсно? Ты что, больной?

Дальше беседовать, и даже читать смысла не вижу.

По твоей ссылке не содержится ответа на мой простой прямой вопрос: почему ты думал, что systemd ничего не знает о замаскированном сервисе? Ты уже две страницы юлишь и вертишь жопой, клоун.

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

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

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

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

По твоей ссылке не содержится ответа на мой простой прямой вопрос:

Ты спросил про 3 вопроса, я дал ответ на один из них.

почему ты думал, что systemd ничего не знает о замаскированном сервисе?

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

между отключением и отключением автоматического запуска.

Одно из двух, либо ты тупой и не можешь понять разницу между максировкой и отключением, или ты тупой и по детсадовски пытаешься соскочить с темы которую мы обсуждали - а именно ОТКЛЮЧЕНИЕ а не отключение автоматического запуска.

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

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

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

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

Ты спросил про 3 вопроса, я дал ответ на один из них.

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

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

Что еще придумаешь, фантазёр? Ты же просто выдумываешь херню за хернёй на ходу вместо того, чтобы 1) прочитать документацию, 2) проверить самому, как и что работает.

$ sudo systemctl disable --now smb
Removed '/etc/systemd/system/multi-user.target.wants/smb.service'.
$ sudo systemctl mask smb
Created symlink '/etc/systemd/system/smb.service' → '/dev/null'.
$ sudo systemctl status smb
○ smb.service
     Loaded: masked (Reason: Unit smb.service is masked.)
     Active: inactive (dead)

Jan 23 23:13:36 nas systemd[1]: Starting Samba SMB Daemon...
Jan 23 23:13:36 nas systemd[1]: Started Samba SMB Daemon.
Jan 27 21:32:07 nas systemd[1]: Stopping Samba SMB Daemon...
Jan 27 21:32:07 nas systemd[1]: smb.service: Deactivated successfully.
Jan 27 21:32:07 nas systemd[1]: Stopped Samba SMB Daemon.
Jan 27 21:32:07 nas systemd[1]: smb.service: Consumed 12.722s CPU time over 3d 22h 18min 31.324s wall clock time, 38.5M memory peak.
$ sudo systemctl unmask smb
Removed '/etc/systemd/system/smb.service'.

Одно из двух, либо ты тупой

Тупой тут именно ты, как уже выяснилось. Еще раз: отключение сервиса не предотвращает его запуск при необходимости, если есть таковая зависимость. Эта задача не решается другими способами. Так работают пакетные менеджеры, так работают все резольверы зависимостей на планете. Запрет запуска называется mask. Что в этом непонятного?

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

…а также не умеющему маскировать сервисы

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

и решать поставленные задачи…

Какие? Я ответил на абсолютно все твои вопросы.

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

Нет, клоун. Это ты выдумыл себе картину мира, в которой не работает mask, и придумываешь бред, чтобы ее обоосновать. И я раз за разом показываю, что твои выдумки не соответствуют действительности. Копипаст из консоли выше.

В твоём манямирке я должен прочитать некую документацию

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

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