apolgy for bad english

where were u wen yuzu emu die

i was at house eating dorito when phone ring

"Yuzu emu is kil"

"no"

>>> https://github.com/yuzu-emu/yuzu

>>> https://yuzu-emu.org

Если раньше эталоном напыщенности и самодовольности пользователей был Arch, то теперь им уверено становятся Nix и NixOS. Серьёзно, что с ним не так? Что не так было с Arch? Это дистрибутив притягивает уже маргинальных пользователей? Или у нормальных людей при использовании Nix по какой-то причине съезжает социализация?

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

Что хочу спросить. Это заразно? Я сильно рискую психическим здоровьем, если вдруг понадобится установить NixOS? Виртуальные машины хоть как-то помогают защититься от напасти?

Уважаемый ЛОР,

Я словил очередное проявление сбойных секторов на SSD. Пациент — Samsung SSD 980 PRO 2TB с прошивкой 3B2QGXA7, в эксплуатации примерно год. Что интересно, с предыдущим накопителем проблемы обнаружились тоже примерно через год после начала эксплуатации.

Думал, что это просто старый накопитель был сбойный, поэтому даже не помню, пробовал ли делать полное чтение на новом с момента переезда. Но вот недавно мне понадобилось сбросить данные с раздела с Windows, и оно опять:

critical medium error, dev nvme0n1, sector 3854183392 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 2

В этот раз плохие сектора оказались намертво плохими. Попытки чтения из них не давали ничего.

Вот текущие параметры SMART, если интересно:

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        34 Celsius
Available Spare:                    79%
Available Spare Threshold:          10%
Percentage Used:                    3%
Data Units Read:                    267 208 610 [136 TB]
Data Units Written:                 115 214 434 [58,9 TB]
Host Read Commands:                 1 770 760 875
Host Write Commands:                880 382 061
Controller Busy Time:               8 163
Power Cycles:                       452
Power On Hours:                     2 220
Unsafe Shutdowns:                   30
Media and Data Integrity Errors:    32 243
Error Information Log Entries:      32 243
Warning  Comp. Temperature Time:    21
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               34 Celsius
Temperature Sensor 2:               35 Celsius
Thermal Temp. 1 Transition Count:   37
Thermal Temp. 2 Transition Count:   17
Thermal Temp. 1 Total Time:         570
Thermal Temp. 2 Total Time:         1815

Удалось отследить, что было задето. Это был старый LVM том со swap, который ни разу со дня миграции не использовался. И это были файлы игр из Steam, которые я в последний год не запускал, судя по датам в Steam’е. То есть симптомы те же — сбоят места, которые очень давно даже не читались. И я даже не знаю, попали ли мне плохие экземпляры, или это вообще общая проблема. У текущего экземпляра ещё и «Available Spare» за пару дней упал с 92% до 79%.

Upd. Оказывается, известная проблема: https://www.tomshardware.com/news/samsung-980-pro-ssd-failures-firmware-update.

Upd. 2023-02-15. Обновил прошивку до актуальной версии, 5B2QGXA7. На всякий случай сделал trim вообще по всему объёму, хотя ещё до этого выяснил, в каких именно файлах были проблемы и потримил занимаемое ими место. Пока что весь объём читается нормально.

Upd. После обновления прошивки операция TRIM стала заметно дольше выполняться. По ощущениям раз в 10 дольше.

Перемещено hobbit из general

https://i.imgur.com/htGIPqQ.gif

Далее — краткое изложение для ленящихся пройти по ссылке.
Если быстро набрать «monospace» в текстовом поле поиска, в поле попадает что угодно, кроме слова «monospace». В заснятом случае там оказалось «moecapson».

Опубликована реализация VA-API, использующая в качестве бэкенда NVDEC — проприетарный интерфейс аппаратного декодера для видеокарт NVIDIA. Автором заявлена поддержка трансляции для кодеков: H.264, HEVC (H.265), VP8, VP9, MPEG-2 и VC-1. На данный момент отсутствует поддержка AV1, MPEG-4 и JPEG. Также отсутствует поддержка видео с 10-битным цветом.

Основная цель проекта — добиться работы аппаратного декодирования видео в браузере Mozilla Firefox, поддерживающего VA-API, но не проприетарные API от NVIDIA. Также была протестирована работа с видеоплеером mpv.

Для Firefox потребуется обновиться до Firefox 96 и изменить некоторые настройки в about:config (см. README).

>>> Репозиторий проекта на GitHub

Да, идея далеко не новая, есть много разных реализаций. Но у всех есть какие-то неудобные для меня ограничения. distcc не поддерживает отличные от Си/Си++ языки, и, похоже, потребует жонглирования версиями компиляторов, если понадобится собирать что-то разными версиями GCC. Fastbuild, кажется, умеет загружать на удалённые ноды бинарники компилятора, но требует переписать скрипты сборки на своём языке, что не всегда возможно для чужих проектов. Incredibuild обещают волшебство, но условия лицензирования и стоимость для физических лиц непонятны. Даже не вполне ясно, что именно считается у них поддержкой Linux.

Хочу что-нибудь открытое-бесплатное или хотя бы со внятной ценовой политикой. Хочу поддержку распространённых систем сборки типа CMake, Meson и простых Makefile. Желательно, вообще независимость от конкретных систем сборки, чтобы, к примеру, можно было собирать Firefox и Chromium. Хочу чтобы оно автоматически загружало на удалённую ноду все нужные для компиляции файлы включая бинарники компилятора, забирая обратно результаты сборки. Хочу поддержки других языков; как минимум, Rust. Хочу кеширование результатов сборки или прозрачного взаимодействия с ccache. Хочу, чтобы оно не умирало от пинга в 50-100 мс, чтобы можно было ноды поднимать на VPS.

Такое уже существует?

Хочу заполучить себе в пользование софт для управления персональными вялотекущими проектами. Чтобы можно было расписать список дел с подзадачами, в виде нескольких деревьев, отдельные пункты из которых можно вручную добавлять в горячий список. Что такое горячий список? Это перечень задач, которые нужно выполнять сейчас. В тех to-do-приложениях, что я видел, список дел на сегодня обычно привязан к дате. День проходит, дела из списка пропадают. Мне же нужно, чтобы пункты оставались там до тех пор, пока я их не выброшу вручную. Ещё хочу генераторы задач, которые добавляют задачи в горячий список по расписанию. Например, каждую пятницу. Или каждые четыре дня. И чтобы эти задачи тоже не пропадали. Если я просрочил что-то регулярное, мне нужно хотя бы видеть, сколько раз. Хочу, чтобы с десктопа можно было редактировать задачи. Хочу, чтобы на Android была возможность задачи смотреть. Если на мобилке тоже можно ими управлять, то это неплохое дополнение. Если это онлайн решение, то хочу возможность хостить его у себя на VPS.

Итак, по пунктам:

1. Древовидный todo-менеджер.
2. Горячий список ссылок на отдельные пункты из деревьев задач.
3. Ручное управление горячим списком: задачи не исчезают из списка сами по себе.
4. Генераторы повторяющихся задач.
5. Синхронизация с Android-приложением или мобильная версия сайта.

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

Объясните, пожалуйста, почему мне это не нужно.
Ну или посоветуйте какое-нибудь решение. Вдруг оно есть?

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

Upd: остановился на Orgzly (org-mode для Android) + org-mode на компьютере.

Обновил я, зачем-то, прошивку ноутбука Latitude E5570. И оказалось, что на новой версии (1.22.3) напряжения на процессоре больше менять нельзя. Советы из интернета сбросить настройки не помогают. Помогает только откат на 1.21.6. И даже Intel XTU под Windows на новой прошивке тоже не может менять напряжения. Похоже, это такой способ закрыть уязвимость CVE-2019-11157, которая так же известна как Plundervolt. Проблема проявляется из-за undervolt? Нет undervolt — нет проблемы.

У меня ноут от Dell, но в интернете есть сообщения что аналогичные обновления блокируют напряжения на ноутбуках Asus и HP. Скорее всего, обновления постепенно развернут все производители. Единственный способ разблокировать напряжения — откатить версию прошивки на предыдущую и больше никогда не обновляться.

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

Проект по добавлению VA-API/X11 в Firefox. Заброшен.
Текущее состояние на 3 июля 2020: (комментарий).

Текст от 25 марта 2020:
Атипичная простуда в очередной раз всех напугала и напомнила, что люди не вечные, причём часто внезапно. Было бы жаль совсем потерять результаты работы, поэтому выкладываю текущий вариант патча к Firefox с поддержкой VA-API под иксами.

Это ещё не готовый к мержу патч, всё держится на честном слове. Из текущих проблем:

• если не подкрутить настройки, ест больше ватт, чем полностью программное декодирование;
• с WebRender видео не видно; возможно роняет контент-процесс;
• с layers-opengl нет видео, если не включить gfx.use-glx-texture-from-pixmap;
• истерично переаллоцирует X11-пиксмапы, если под layers-opengl переключиться на другую вкладку.

Чтобы под layers-basic экономия от декодирования вообще имела смысл, нужно включить gfx.xrender.enabled. Без XRender чтение картинки обратно в память CPU ест больше энергии, чем просто декодирование сразу на CPU.

До рабочего варианта ещё далеко. Но если кто-то захочет собрать и потестить, ссылка внизу. Патчсет базируется на 74.0. Оригинальный репозиторий был в Mercurial, и файлы .gitignore там где-то игнорят нужное для сборки, поэтому не факт, что код как есть соберётся. Если так оно и есть, должно помочь использование релизных исходников от 74.0 с последующим накладыванием патча.

Для VP9 Firefox предпочитает ffvpx, особую сборку ffmpeg, которую таскает с собой. Чтобы VP9 декодировать через системный ffmpeg с поддержкой VA-API, нужно выключить media.ffvpx.enabled.

https://github.com/i-rinat/firefox/compare/master...vaapi

Дорогой Уважаемый ЛОР,

Я словил первое в своей жизни проявление сбойных секторов на SSD. Пациент — Samsung SSD 970 EVO 2TB с прошивкой 2B2QEXE7, в эксплуатации примерно год. Пару-тройку дней назад мне почему-то захотелось сделать копию вообще всех данных из домашней директории, включая файлы, которые легко скачать из сети при надобности. Некоторые из этих файлов лежали там с момента миграции на накопитель, без обращений. И при копировании одного из таких файлов программа сказала: «А я, кажись, чот не могу». После того, как потихоньку пришло осознание произошедшего, я глянул в лог и увидел там:

blk_update_request: critical medium error, dev nvme0n1, sector 313199872 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 0

Что интересно, во второй раз файл успешно скопировался. Не знаю, прочитались там настоящие данные или мусор. К сожалению, вот этот конкретный файл повторно скачать оказалось неоткуда. Чтение данных с nvme0n1 по тому адресу выдало какие-то данные, не нули. Тут я решил, что SSD умный, что он понял, что страница не читается стабильно, и увёл её в чулан, на её место подставил новую, а данные всё-таки скопировал. Но на всякий случай решил запустить холостое чтение с блочного устройства. Сбойных блоков оказалось больше. Пробовал читать конкретные места. Зачастую чтение было успешным, но через много чтений всё же происходили ошибки. Попробовал перезаписать место с ошибками чтения теми же данными. Ошибки там прекратились.

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

За время тестов в логи свалилось 546 строк с «blk_update_request: critical medium error», но ошибки иногда сыпались так часто, что в сумме набралось 888 «callbacks suppressed». В статусе накопителя написано, что ошибок доступа к носителю было 1484. Так как в логи основной системы не попало происходившее на LiveUSB, можно считать, что числа сходятся. К сожалению, не помню, были ли там ошибки до недавних событий. Всего различных сбойных секторов было 167 штук.

В данных из плохих секторов нашлись обрывки Packages из Debian. Судя по версиям пакетов, эти куски из очень старых Packages, возможно ещё из 2016. Если это так, они приехали во время миграции на накопитель, и с тех пор не перезаписывались и не читались. Один кусок оказался очень похож на файл переводов и нашёлся в /usr/share/locale/gl/LC_MESSAGES/coreutils.mo, который конечно же ни разу не читался с момента последней переустановки пакета coreutils в начале августа 2019.

smartctl:

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    1%
Data Units Read:                    162 937 114 [83,4 TB]
Data Units Written:                 65 584 401 [33,5 TB]
Host Read Commands:                 691 234 670
Host Write Commands:                544 796 594
Controller Busy Time:               3 278
Power Cycles:                       719
Power On Hours:                     2 249
Unsafe Shutdowns:                   82
Media and Data Integrity Errors:    1 484
Error Information Log Entries:      1 783
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               41 Celsius
Temperature Sensor 2:               42 Celsius

Error Information (NVMe Log 0x01, max 64 entries)
No Errors Logged

Терабайт тридцать-сорок я добавил чтением накопителя во время тестов.

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

• полгода без чтения страницы на SSD достаточно для последующих ошибок чтения;
• чтение такой страницы не заставляет SSD подменять страницу на новую, он с радостью выдаёт ошибку чтения на одном и том же месте много раз подряд;
• trim не означает очистку всех неиспользуемых блоков ФС, они же меньше страницы. Некоторые данные могут жить в закоулках годами;
• SSD желательно периодически прочёсывать чтением, чтобы словить сюрпризы пораньше;
• если такое происходит на TLC 3D V-NAND, страшно подумать, что будет на QLC.

Upd.
Узнал, что в NVMe есть фича 0x10, которая управляет температурами, при которых SSD должен начать тормозить для снижения нагрева. Правда для 970 EVO эти температуры дожны быть в диапазоне 80–82 °C, а попытка установить любые значения кроме 0 для фичи 0x10 завершаются неудачай.

Upd. 11 мая 2021, то есть примерно через год и два месяца после первого раза, появились новые ошибки чтения. При повторном чтении тех же мест ошибки повторялись, но через некоторое время пропали.

Upd. 5 июня 2021. Аккумулятор оказался вздут в той секции, что прилегает к SSD. Видимо, предупреждение о температурном лимите в 65°C на аккумуляторе написано не просто так.

Upd. 20 февраля 2022. Накопитель отправился на пенсию.

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

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

В правилах сейчас никаких сроков не указано. Давайте всё же какие-то сроки выберем.

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

В лучших традициях ЛОРовских споров мы тут решили с HIS посоревноваться — кто за полгода большую общественную полезность нанесёт.

Срок — до 1 декабря 2019 года. Объективных критериев нет, вместо этого пусть посетители форума оценят полезность по своему пониманию. Это ближе к реальной жизни.

Цель — лулзы. Побочная цель — нанесение пользы людям.

Оригинальное сообщение и ветка обсуждения — тут: https://www.linux.org.ru/forum/development/15016840?cid=15026192.

Ждём в треде явное подтверждение от HIS об участии.
Подтверждение получено: Нанесение общественной полезности (комментарий).

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

Есть такое?

Краем глаза смотрел на GnuCash и KMyMoney. Но мне показалось, что они ориентированы на стратегическое планирование. А мне нужно масштабом поменьше, больше ориентированное на конкретные продукты.

Есть какой-нибудь способ организовать просмотр картинок в панели быстрого просмотра в Midnight Commander? Чтобы например, в панели слева сразу было видно, что за картинка под курсором в правой панели.

Иногда нет надобности заворачивать вообще весь трафик в VPN, и достаточно бывает просто сделать HTTP- или SOCKS-прокси, чтобы управлять трафиком каждого приложения в отдельности. Иногда VPN'ов несколько, и чтобы они ужились и работали, без плясок с бубном и чтения документации просто не обойтись. Поэтому приходится либо прятать клиент OpenVPN в виртуалки или контейнеры, либо мудрить с настройками маршрутизации, чтобы направить трафик в нужных направлениях.

Если так подумать, использование tun/tap — явный оверкил. Пользовательский процесс клиента OpenVPN принимает данные по сети, потом их режет-комбинирует, пихает в ядро. Оттуда пакеты выпрыгивают в локальный прокси-сервер, который потом снова... В общем, лишнее. К тому же, необходимость использования /dev/net/tun вынуждает выдавать контейнеру CAP_NET_ADMIN.

Теоретически, должно быть возможно эдакое скрещивание OpenVPN, юзерспейсной реализации TCP/UDP и какого-нибудь прокси-сервера. Без использования tun/tap.

Такое уже есть?

Удивительно, но сенсорный экран как средство ввода не такой уж и интуитивно понятный. Особенно, людям постарше. Концепция непривычна, и обучение проходит тяжело. К примеру, вот это видео с дедом и телефоном смешное только до того момента, как видишь подобное поведение вживую: https://www.youtube.com/watch?v=E-dfxE4cAKc. Это не единичный случай, таких много. Проблема распространённая.

Есть ли какие-нибудь игры для телефонов для тренировки работы с сенсорными экраном? Желательно не скоростные, а ориентированные на плавность и уверенность в движениях.

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

Я долго собирался с силами, и вот недавно всё-таки осилил этот десяток строк на Javascript.

// SPDX-License-Identifier: MIT-0

// ==UserScript==
// @name     Highlight older messages on linux.org.ru
// @version  2
// @grant    none
// @include  https://www.linux.org.ru/*
// @run-at   document-end
// ==/UserScript==

(function () {
  
  // Configurables.
  const old_message_age = 30; // Days.
  const old_message_background = '#000000';
  // -------------

  document.querySelectorAll('div.sign time').forEach(function (element) {
    const element_datetime = Date.parse(element.attributes.datetime.value);
    const age_in_seconds = (Date.now() - element_datetime) / 1000;
    const age_in_days = age_in_seconds / 3600 / 24;
    
    if (age_in_days > old_message_age) {
      element.closest('article').style.background = old_message_background;
    }
  });
})();

Только я собрался чинить это выбешивающее мерцание чёрным фоном у GTK+3 окошек, как какой-то Бенжамин вероломно воспользовался машиной времени и реализовал мою идею аж три недели назад: https://gitlab.gnome.org/GNOME/gtk/commit/2ce63a86ba689aa41eb47409c889c469497....

Что ж, это не придерживание XMapWindow до момента первой осмысленной картинки, как я бы хотел, а просто прозрачный фон. Но прозрачный фон — это текущее изображение. А значит, больше нет мерцания.

Фикс не попал в 3.22.30, но, скорее всего, попадёт в 3.22.31.

Всем радоваться полчаса!

Как известно, вызовы бывают блокирующими и не блокирующими. По умолчанию read() для сокета отправляет процесс в сон, пока в сокет не придёт сколько-то данных. Он блокирует исполнение. Если включить неблокирующий режим, read() вернётся сразу, и по errno можно будет понять, произошла ли ошибка или просто данных пока нет. Возможно, такой read() понадобится вызвать несколько раз.

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

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

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