LINUX.ORG.RU

NetBSD 10.0

 ,


1

4

Вышла версия операционной системы NetBSD 10.0.

Изменения новой версии:

  • Поддержка оборудования:

    • Добавлена поддержка Apple M1.
    • Добавлена поддержка Raspberry Pi 4.
    • Включен драйвер rkv1crypto на PINE64 Rock64 и NanoPi R2S.
    • Добавлена ​​поддержка spiflash на Rockchip RK3328.
    • Добавлена поддержка compat_linux для архитектуры AArch64.
  • Изменения в ядре:

    • Добавлена поддержка WireGuard.
    • Добавлена ​​реализация шифра Adiantum для эффективного шифрования диска с помощью cgd в системах без ускорения AES.
    • Шифрование подкачки теперь выполняется автоматически с использованием переменной vm.swap_encrypt=1 в sysctl.
    • Устройствам IEEE 802.11 (Wi-Fi) теперь требуется настройка SSID для связи с открытой точкой доступа.
    • По умолчанию отключена поддержка compat_linux.
    • База данных пакетов по умолчанию для новых установок была изменена на /usr/pkg/pkgdb для согласованности с другими платформами pkgsrc, заменив /var/db/pkg.
    • Модули ядра MIDI и секвенсора объединены в один модуль MIDI_seq.
  • Драйвера устройств:

    • urtwn — добавлена ​​поддержка беспроводного USB-адаптера TRENDnet TEW-648UBM.
    • Добавлен новый драйвер rge - для поддержки Ethernet-адаптера Realtek 8125 2.5
    • Добавлен новый драйвер ixl - для поддержки Ethernet-адаптеров Intel Ethernet 700 серии 10/25/40
    • Удален драйвер azaila, который был заменен в прошлых релизах на hdaudio.
    • ossaudio — добавлена ​​реализация API микшера OSSv4.
    • Обновлены драйверы DRM до версии 5.6.
  • Улучшение виртуализации:

    • В NVMM добавили поддержку suspend.
    • Добавлена ​​поддержка Xen PVH.
    • Добавлена ​​поддержка VirtIO 1.0 в драйвер virtio.
  • Улучшение производительности:

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

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



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 2)

Кстати, напоминаю, что FreeBSD выпиливает i386 начиная со следующей мажорной версии. (15.0)

Так что для тех, кому еще нужно 32-битное железо в сочетании с современной ОС, NetBSD остаётся подходящим вариантом.

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

Ну если отвлекающий - ждём новые первоарельские приколы…

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

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

FreeBSD выпиливает i386

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

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

Не-не-не! Бутылка коньяка, поставленная на тот же стол, кООрдинально исправила ситуацию!.. ;) :))

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

Словенский использует латиницу, так что тут как бы однозначно стол это table (но не TABLE). Да и на ЛОРе все бы постеснялись так явно признаваться. ☺

mord0d ★★★★★
()

Кстати, подскажите, кто знает.

Есть ли у NetBSD поддержка воспроизводимых сборок? Если я скомпилирую её из сорцов, будет ли она побайтово соответствовать релизным файлам?

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

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

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

Бот хорчет ответы....
притом, что несёт какую-то шизофазию

Если нужно без либы, то зачем нужна какая-то «обёртка»(т. е. либа)?

Подазумевается, что это дожно быть стабильное API и я эту обёртку/либу смогу как влинковать статически, не боясь, что этот интерфейс поломают, так и переписать. Потом в это целиком проходит аудит, а не загружает в проект сторонний код. sshd например имеет доступ к сети и ключам, то есть даже если процесс максимально огородить на уровне MAC белым списком сисколов - это не поможет.
Причём статическая линковка должна быть по умолчанию. Если они выносят его в shared, боясь уязвимости, то добро пожаловать, вот случай, когда shared либа подтягивает другую уязвимую либу...

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

А скриптота не может быть сервисом? Другое дело, что у скриптоты постоянно pid меняется, но всё равно отделить в отдельную сессию потомки было бы полезно.

И да, для этого интерфейса также будет либа.

4.2

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

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

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

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

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

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

Ты опять выходишь на связь?

А так оно уже кучу времени линкуется, но почему-то проблем никаких не возникало. Почему?

На это ответ. Почему линковка была, а проблем не было.

влинковать статически

Ты болтал про что?

Проблема в том, что какой-то мутный libsystemd0 может линковаться к safety-critical сервису доступному из сети

«линкуется код systemd», ни про какое «статически» ты не болтал. А сейчас стало нечего ответить и ты решил съехать на «я имел ввиду другое»? Это сильно.

А скриптота не может быть сервисом?

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

4.2

Нет, не «4.2». В задаче уведомления между локальным сокетом и файлом разницы нет. Для сокета имеем либу. Значит для файла либа также будет. Успокойся, эникей.

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

Боже, откуда такие гении лезут. Ты там прочитал мой пост в теме и решил выдать за свой?

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

Позорище.

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

На это ответ. Почему линковка была, а проблем не было.

проблемы были. причём постоянно. Конечно, инжектить код никто не пытался, а вот зависимость от libsystemd в каком-нибудь собранном бинаре - постоянно

«линкуется код systemd», ни про какое «статически» ты не болтал. А сейчас стало нечего ответить и ты решил съехать на «я имел ввиду другое»? Это сильно.

Если libsystemd линкуется динамически - наверно есть на это причины, например этот сокетовый интерфейс поломать, или причина в том, что он слишком сложный. Уведомление должно делаться в одну-две строки кода, а не библиотекой

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

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

Нет, не «4.2». В задаче уведомления между локальным сокетом и файлом разницы нет. Для сокета имеем либу. Значит для файла либа также будет.

ну давай, уведоми мн сервис простым shell скриптом

Успокойся, эникей.

Оскорбление участников дискуссии

Боже, откуда такие гении лезут. Ты там прочитал мой пост в теме и решил выдать за свой?

Я другие твои посты не считал. Ок, ты всё-таки понимаешь, что пихать какую-то левую либу в sshd нехорошо.
Я правда так и не понял, уязвимость в том, что libsystemd подтянуло lzma или сам systemd его инжектил? В любом случае троянец в pid1 это уже game over и что делает там liblzma, если не специально добавлено для понижения надёжности - мне неясно.

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

проблемы были. причём постоянно. Конечно, инжектить код никто не пытался, а вот зависимость от libsystemd в каком-нибудь собранном бинаре - постоянно

Неверно. Речь о конкретной проблеме. Её не было. Всё, уязвимость не в системд.

Если libsystemd линкуется динамически - наверно есть на это причины, например этот сокетовый интерфейс поломать, или причина в том, что он слишком сложный. Уведомление должно делаться в одну-две строки кода, а не библиотекой

Отмазки мимо. Изначально проблемой заявлялось наличие кода системд в ccxд, а далее произошла подмена тезиса на «проблема в динамической линковке» - это просто попытка забалтывать.

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

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

ну давай, уведоми мн сервис простым shell скриптом

Зачем мне какой-то «shell скриптом»? Я не эникей. И да, зачем ты повторяешь сказанное мной ранее? Шелл скрипт - как раз случай когда лучшие средства не доступны/не удобны. Поэтому ты попытался съехать на шелл.

Ок, ты всё-таки понимаешь, что пихать какую-то левую либу в sshd нехорошо.

Она не левая. Какая ситуация - нужны уведомления, есть готовая либа. Варианты: написать руками или бахнуть либу. Вот выбрали последнее, чего-то нелогичного здесь нет. А то что в либе ещё куча всего - то не проблема именно libsystemd, все либы +/- такие. Либу на одну функцию(из пары строк) никто не делает.

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

Неверно. Речь о конкретной проблеме. Её не было. Всё, уязвимость не в системд.

systemd не было? Ну тогда действительго не было проблемы, пока его не было. А как появился - заставили грузить/линковать какие-то либы.

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

Одного без другого бы не было. Я говорил об обёртке чисто для механизма уведомления. То что сейчас предлагают - линковать весь libsystemd. Ну допустим, можно влинковать статическую версию, которая не подтянет lzma т.к не будут использоваться функции, использующие lzma. Это как такой poor solution. Статическая линковка хотя бы пощволяет не линковать лишнее.

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

Все они хуже, потому что требуют большего объёма кода для работы с ними. Ну кроме разве что сокета. И даже тут во всех случаях header-only либо можно было бы сделать.

Зачем мне какой-то «shell скриптом»? Я не эникей

Но ты постоянно говоришь это слово. Я уже в этом сильно начинаю сомневаться

Она не левая. Какая ситуация - нужны уведомления, есть готовая либа.

Не нужны, а навязаны. Весь этот механизм с уведомлениями и прибиванием сессии при разлогине - навязанный поттерингом с его systemd буллщит. И т.к он уверен, что его поделие подойдёт везде и все им должны пользоваться, реализован механизм уведомления самым навязчивым способом - динамической линковкой. Почему? А потому что эго - «я пропихнул свой код везде, я молодец! 3 billion devices!»

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

Есть ли у NetBSD поддержка воспроизводимых сборок? Если я скомпилирую её из сорцов, будет ли она побайтово соответствовать релизным файлам?

Что за бред я только что прочитал? А откуда, ты думаешь, берутся бинарики в релизе?

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

меня смущает js в нике, но да ладно, на первое апреля можно и по холиварить

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

Хаха. Не знал. Идиотизм каких мало. То есть ты спрашиваешь, используется ли в процессе компиляции /dev/random или что?

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

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

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

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

Статус воспроизводимости сборок в Арче, например: https://reproducible.archlinux.org/

wandrien ★★
()

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

Поставил XFCE и некоторый базовый набор софта. Ну про саму XFCE сказать нечего – GTK3 её уродует. Хоть бери и собирай версию с GTK2.

Firefox артефачит. А именно – корректно не рендерится всё, что имеет полупрозрачности. Это касается как текста страницы, так и элементов интерфейса. Например, Ютуб выглядит так: https://ibb.co/m5dP4mX . ЛОР тоже не особо хорошо.

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

Из того, что я попутно выяснил:

  • В теории, NetBSD возможно запустить с раздела ext2. Однако чисто из-под линукса её не получится распаковать на раздел и запустить, потому что еще нужно выполнить скрипт, который файлы-устройства создаст в /dev, а линуксовый mknod вроде ему не подходит. Если бы файлы-устройства из установочного tar-архива распаковывались, было бы возможно.
  • Ядро само не умеет монтировать корень с LVM раздела. Но вроде как есть поддержка аналога initramfs. Так что можно сделать запуск с образа ramdisk, который смонтирует LVM и чрутнется туда. Но это всё надо городить вручную. Планирую заняться этим как-нибудь позже.
wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от spbzip

То есть ты спрашиваешь, используется ли в процессе компиляции /dev/random или что?

Что за бред я только что прочитал?

Не знал.

Но лезешь с умным рылом…

Идиотизм каких мало.

Я рад что ты признаёшь свои недостатки. Жаль что ты над их устранением не работаешь.

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

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

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

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

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

Или, возможно, он просто боится, что его даже чятжпт унизит. (=

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

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

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

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

mord0d ★★★★★
()

Я так понимаю, реальный объем доступной для выделения ОЗУ никак не посмотреть?

Память из страничного кэша учитывается как в Inactive, так и в Active. Эти два счётчика не говорят по существу.

Достаточно сделать:

find /usr/ -type f | xargs cat > /dev/null

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

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

Сначала делаем tail /dev/zero, потребление памяти падает до 22 МБ. Потом делаем find /usr/ -type f | xargs cat > /dev/null, и потребление памяти якобы уходит за 1 ГБ.

Увы, для практической оценки состояния памяти эти счётчики бесполезны. Получается, что в системе нет реального мониторинга потребления ОЗУ.

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

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

Всё очень интересно, но в практическом отношении очень мутно.

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

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

luke ★★★★★
()
  1. Я настолько преисполнился, что херачу в терминале с ненастроенным bash-ем, который даже путь текущего каталога не показывает.
  2. Дряная девчонка NetBSD так и не научилась понимать расширенные разделы MBR, а у меня есть возможность только расширенный раздел ей выделить на реальной системе. Под GPT диск не разбит, извините. А с LVM она грузиться не умеет.
  3. Моя последняя надежда — это пересобрать ядро с опцией DKWEDGE_METHOD_MBR. Возможно, после этого она увидит расширенные разделы. (Но вообще никаких гарантий.) Так что я щас буду пересобирать ядро прямо внутри Виртуальной Коробки.
  4. ???
  5. Я в своём познании настолько преисполнился, что я как будто бы уже сто триллионов миллиардов лет проживаю на триллионах и триллионах таких же планет, понимаешь, как эта Земля. Мне уже этот мир абсолютно понятен, и я здесь ищу только одного: покоя, умиротворения и вот этой гармонии от слияния с бесконечно вечным.
wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

А, еще забыл рассказать.

У меня какой-то глюк, связанный с Виртуальной Коробкой.

Иногда она захватывает мышь, но не отдаёт её в гостевую ОС. И мышь остаётся в подвешенном состоянии: не работает ни в хосте, ни в госте. И снять такой захват нельзя.

Остаётся работать только клава.

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

Иначе никак.

Такая вот шляпа.

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

Скомпилировалось, что ли. Быстро.

Всего 3373 объектных файла.

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

Возможно, после этого она увидит расширенные разделы.

Нихрена.

Теперь как wedges появились разделы с MBR, но только базовые. Расширенные она не видит.

Сабака серая.

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

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

spbzip
()

Таки нашел место и поставил на реальный раздел.

Ну что я могу сказать.

  1. Wi-Fi не работает.

Модуль: Intel Corporation Centrino Wireless-N 130 (rev 34)

Вот такая ошибка по этому поводу:

[     7.100458] iwn0: autoconfiguration error: fatal firmware error
[     7.100458] autoconfiguration error: firmware error log:
[     7.100458] autoconfiguration error:   error type      = "UNKNOWN" (0x00001999)
[     7.100458] autoconfiguration error:   program counter = 0x00014130
[     7.100458] autoconfiguration error:   source line     = 0x00000136
[     7.100458] autoconfiguration error:   error data      = 0x00000001000000A4
[     7.100458] autoconfiguration error:   branch link     = 0x0001410200014102
[     7.100458] autoconfiguration error:   interrupt link  = 0x0000C71E00000000
[     7.100458] autoconfiguration error:   time            = 26817
[     7.100458] autoconfiguration error: driver status:
[     7.100458] autoconfiguration error:   tx ring  0: qid=0  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  1: qid=1  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  2: qid=2  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  3: qid=3  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  4: qid=4  cur=2   queued=0  
[     7.100458] autoconfiguration error:   tx ring  5: qid=5  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  6: qid=6  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  7: qid=7  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  8: qid=8  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring  9: qid=9  cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 10: qid=10 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 11: qid=11 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 12: qid=12 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 13: qid=13 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 14: qid=14 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 15: qid=15 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 16: qid=16 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 17: qid=17 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 18: qid=18 cur=0   queued=0  
[     7.100458] autoconfiguration error:   tx ring 19: qid=19 cur=0   queued=0  
[     7.100458] autoconfiguration error:   rx ring: cur=2
[     7.100458] autoconfiguration error:   802.11 state 0
[     8.090453] iwn0: autoconfiguration error: crystal calibration failed
[     8.090453] iwn0: autoconfiguration error: could not initialize hardware
[     8.190451] iwn0: cannot assign link-local address

Ошибка гуглится. Решений не гуглится.

Фирмварь из пакета iwn-firmware подкидывал в /libdata/firmware/if_iwn. Разницы нет.

Пришлось расшарить подключение по Ethernet с другого ноута.

  1. Звук работает частично.

Железка: Realtek ALC269.

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

Это тот же баг, что я встречал в FreeBSD несколько лет назад. Починили ли в FreeBSD, не знаю, так как после этого не проверял.

  1. Самое главное. Артефакты в Firefox никуда не исчезли на реальном железе. Буду разбираться.
wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 3)
Ответ на: комментарий от wandrien

В репах есть следующие версии firefox: 120, 115, 102, 52.

Глючат все, кроме 52.

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

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

А наушники проводные? У меня bluetooth-наушники без проблем на нетке работают.

И какие записи показывает audiocfg list?

UnixAwesome
() автор топика
Ответ на: комментарий от UnixAwesome
$ audiocfg list
0: [*] audio0 @ hdafg0: Realtek ALC269
       playback: 2ch, 48000Hz
       record:   2ch, 48000Hz
       (PR) slinear_le 16/16, 2ch, { 44100, 48000, 96000, 192000 }
       (PR) slinear_le 20/32, 2ch, { 44100, 48000, 96000, 192000 }
       (PR) slinear_le 24/32, 2ch, { 44100, 48000, 96000, 192000 }
       (  ) ac3 16/16, 2ch, { 44100, 48000, 96000, 192000 }
1: [ ] audio1 @ hdafg1: Intel product 2805
       playback: 2ch, 48000Hz
       record:   2ch, 48000Hz
       (P-) slinear_le 16/16, 2ch, { 48000 }
       (P-) slinear_le 16/16, 4ch, { 48000 }
       (P-) slinear_le 16/16, 6ch, { 48000 }
       (P-) slinear_le 16/16, 8ch, { 48000 }
       (PR) slinear_le 16/16, 2ch, 48000-48000Hz

А наушники проводные?

Да, в обычный джек.

Итого, звук на этой железке: не полностью работает в NetBSD, FreeBSD; иногда (очень редко) есть проблемы с переключением на Windows; и только на Linux работает как часы.

Видимо, где-то в драйвере какого-то частного случая или выставленной настройки не хватает…

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

Видимо в нетке jack наушники нормально не подключить, для bluetooth-наушников у меня отдельная запись в audiocfg list. А во фряхе для проводных я раньше дергал в sysctl параметр hw.snd.default_unit.

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

Блин, я ваще не представляю, в какую сторону копать, потому что перекомпилировать firefox для отладки и последовательно искать причину на уровне сорцов – это можно долбануться.

В виртуалке он писал ошибки про DRI2, но сейчас на интеловском драйвере эта ошибка ушла, и в он stderr вообще не пишет ничего, что имело бы отношение к рендеру. При этом рендер косячный.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.