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

(исходники от 102.15.1 но думаю в 115 всё так же)

Собственно начинаем с C++

Файл gfx/webrender_bindings/RenderThreadOGL.cpp функция RendererOGL::UpateAndRender() - в середине есть вызов

  if (!wr_renderer_render(mRenderer, size.width, size.height, bufferAge, aOutStats, &dirtyRects)) {

mRenderer - это поле в классе RendererOGL, определено так:

  wr::Renderer* mRenderer;

wr это namespace в котором много всего разного есть.

Функция wr_renderer_render находится в файле gfx/webrender_bindings/src/bindings.rs

pub extern "C" fn wr_renderer_render(
    renderer: &mut Renderer,
    width: i32,
    height: i32,
    buffer_age: usize,
    out_stats: &mut RendererStats,
    out_dirty_rects: &mut ThinVec<DeviceIntRect>,
) -> bool {
    match renderer.render(DeviceIntSize::new(width, height), buffer_age) {
        Ok(results) => {
            *out_stats = results.stats;
            out_dirty_rects.extend(results.dirty_rects);
            true
        },
        Err(errors) => {
            for e in errors {
                warn!(" Failed to render: {:?}", e);
                let msg = CString::new(format!("wr_renderer_render: {:?}", e)).unwrap();
                unsafe {
                    gfx_critical_note(msg.as_ptr());
                }
            }
            false
        },
    }
}

Как я понимаю match это аналог switch и она вызывает метод render из той штуки которую ей дали первым аргументом. Касательно типа этого аргумента (напомню, это поле wr::Renderer* mRenderer из класса RendererOGL) в С++ файлах нашлось только упоминание struct Renderer; (без тела) в файле gfx/webrender_bindings/RendererScreenshotGrabber.h. Я думаю, эта «структура» - opaque для c++-кода и используется только из rust-а (может, не прав). В файле gfx/wr/webrender/src/renderer/mod.rs нашлось некое pub struct Renderer url (searchfox.org) но не вижу там указания на namespace wr:: и не вижу в ней метода render, который вроде бы вызывается из вышеприведённой wr_renderer_render.

Ещё есть struct/class Renderer упоминается тут:

third_party/rust/codespan-reporting/src/term/renderer.rs:pub struct Renderer<'writer, 'config> {
third_party/rust/profiling/examples/puffin/renderer.rs:pub struct Renderer {
third_party/libwebrtc/video/end_to_end_tests/call_operation_tests.cc:  class Renderer : public rtc::VideoSinkInterface<VideoFrame> {
third_party/libwebrtc/video/end_to_end_tests/call_operation_tests.cc:  class Renderer : public rtc::VideoSinkInterface<VideoFrame> {
third_party/libwebrtc/modules/audio_device/include/test_audio_device.h:  class Renderer {

но мне кажется это что-то другое вообще.

Где я напутал?

Что это за бред? Фф при компиляции создаёт директорию obj-x86_64-pc-linux-gnux32/ и компилирует всё в неё (вроде). Откуда вообще такое название могло взяться? Файл a.out, который я там внутри нашёл - вроде бы нормальный 32-битный i686 или как там его назвать. Но gnux32 это же другое должно быть.

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

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

Собственно фпс сравнивал в игре https://orteil.dashnet.org/cookieclicker/ - в мозилловском пакете там всё плавно и хорошо, в дебановском дёрганая картинка уже на стадии загрузки (когда крутятся шарики посередине экрана, эту стадию можно искуcственно удлинить если залагать себе инет - зафайрволить что-нить нужное ему в DROP).

А вы что-нить такое замечали? С чем это связано?

Оба фф запускал в новом чистом профиле (одном и том же).

Из заметной разницы (кроме фпс) - в мозилловском пакете нет звука т.к. он только пульсу ищет которой нет.

------------------

Профайлер deb: https://ibb.co/jHqYXxB

Профайлер moz: https://ibb.co/5c4mt5X

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

Зелёное в Render это в основном RenderThread::UpdateAndRender (во вкладке Marker Table эти пики называются «Composite #1»)

Синее в работе вкладки это «CanvasRenderingContext2D.drawImage»

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

upd: кажется не связано, ввёл в консоли CanvasRenderingContext2D.prototype.clip = function() { }; и ничего не поменялось в плане скорости

Ввёл CanvasRenderingContext2D.prototype.drawImage = function() {};, после этого затраты на эту функцию в проце вкладки исчезли (как и соответствующие картинки на странице), а вот процесс render всё так же продолжает лагать и тратит по 100мс на одну итерацию (даже увеличилось - до этого тратила около 95мс). В мозилловском пакете же 10-20мс.

------------------

Компактный пример для воспроизведения проблемы: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

Как оказалось, js ни при чём, в примере его вообще нет. Но проблема как-то побочно задевает js тоже (а конкретно функцию CanvasRenderingContext2D.prototype.drawImage - она начинает в этих условиях работать в разы медленнее). В приведённом же примере js нет и лаги видны только в RenderThread::UpdateAndRender (это внутренняя функция в исходниках фф как я понял).

--------------------

Сравнение about:buildconfig firefox-esr с mozilla.org и из debian - разный fps (комментарий)

--------------------

Обновление: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

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

Время от времени хотелось чтоб был некий дамп схемы использования физических накопителей разными файловыми системами, чтобы не лазить отдельно по camcontrol devlist, gmirror/gmultipath/gpart, спискам монтирования и иногда sysctl. И чтобы этот дамп был пригоден для обычного diff между «было» и «теперь». Написал в итоге такую прогу, может кому пригодится или кто даст совет как поудобнее сделать её вывод чтобы было нагляднее кто за что отвечает. (только не так как geom -t который дублирует на каждого члена mirror/multipath всю вышележащую топологию)

исходник

Компилировать с -lgeom -lfcl

update 2023-12-05

как скомпилировать с нуля с черновой поддержкой zfs:

cd /tmp/
fetch https://dev.m1089.ru/fcl/files/fcl-20231205.tar.gz
tar xf fcl-20231205.tar.gz
cd fcl-20231205/DEV/src
./build.sh fcl
fetch https://dev.m1089.ru/freebsd-misc/files/storage-summary/storage-summary.c
cc storage-summary.c -DWITH_LIBZFS -DLIBZFS_HACK -I../include -L../lib -lgeom -lfcl -lzfs -lnvpair -o storage-summary

Обновил freebsd 12.3 -> 12.4, стал ставить порты, а у диалогов с опциями поехала псевдографика, по виду похоже что оно начало её в юникоде рисовать а консоль с однобайтной кодировкой. Как исправить?

LANG= и LANG=C не помогают.

Запуск со старым ядром от 12.3 не помогает.

----------

Всё, разобрался, они из-за GPL-фобии заменили утилиту для этих диалогов, только она не в 12.3 или 12.4 а в дереве портов прописана.

https://alfonsosiciliano.gitlab.io/posts/2021-11-20-portconfig.html

Дописал в make.conf

DIALOG4PORTS=/usr/local/bin/dialog4ports

и всё починилось.

-------------

Мда https://cgit.freebsd.org/ports/commit/Mk/Scripts/dialog4ports.sh?id=9fee35128...

из-за виндузятников с putty испортили нормальное определение наличия юникода. Дело не в утилите, с ней всё норм, просто старая utf-8 вообще не поддерживала, а этой фейковое описание локали подсовывают из скрипта.

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

Условие очень простое: выражение is_contained(h0, hlen, q0, qlen) должно возвращать 1, если диапазон под вопросом (question - q), начинающийся включительно с q0 и занимающий всего qlen индексов, полностью содержится в диапазоне (have - то что имеется), начинающимся включительно с h0 и имеющим длину в hlen индексов, и должно возвращать 0 во всех других случаях. Оба диапазона относятся к индексам некоего массива или смещениям байт в файле, при том что файл целиком влез в аллоцированный блок памяти процесса в виде того же массива.

Вопрос: написать синтаксически корректную (допустим C89) реализацию функции is_contained(), такую чтобы всегда отдавала правильный результат, при этом не содержала лишнего кода и не требовала линковки с чем-то ещё, включая libc, для работы (но содержимым C89-стандартных (только их) .h файлов пользоваться можно, если оно не приводит к импорту символов извне).

Условие именно такое как я написал, никакие уточнения не предполагаются. Если считаете что условие где-то двусмысленное - дополняйте его как хотите (не противореча исходным утверждениям).

Хочу поделиться. В течение некоторого количества часов с диска с XFS файловой системой снималась копия методом dd if=/dev/sdX of=/dev/sdY на работающем сервере с нагрузкой (т.е. в этом время там перезаписывались какие-то файлы итд). Затем sdY был использован как загрузочный диск для другой системы. Итоги: первый запуск выбросил в recovery shell из-за того что в fstab было прописано лишнее которого на второй системе нет, закомментировал и заодно исправил конфиг сети которая очевидно тоже другая, ребут - завис на надписи i/o error при чтении systemd-readahead. Ещё один ребут - зависло где-то ещё раньше без внятной диагностики. Ещё один ребут и прописал init=/bin/sh в grub-е. Оказалось что mount отказывается монтировать раздел из-за каких-то ошибок, запустил xfs_repair -L, который выдал кучу надписей но в итоге завершился успехом. Заодно на всякий случай удалил файл .readahead из корня. Итог - система грузится и работает, и даже данные вроде на месте.

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

Но я всё равно буду предпочитать ext4 на своих установках.

На всякий случай уточню: всё сделано исключительно для тестов и в прод пущено не будет.

У всех?

С плохого инета иногда не доходят ответы на post отправки сообщения. В итоге, после повторного нажатия кнопки, их получаются два, и из-за того же плохого инета может не получиться увидеть этот итог и вовремя удалить дубль. Почему бы не пропускать добавление коммента, если он 100% совпадает с последним добавленным этим юзером в эту тему? Даже ошибку никакую не писать, просто раз коммент уже есть - пропускать этот инсерт а всё остальное как обычно.

Почему авторы всяких libc могут объявлять функции типа vprintf в stdio.h не инклюдя побочно stdarg.h (вдруг юзеру не нужно), а все остальные не могут? Ну, я конечно посмотрел как там сделано и там вместо va_list внутренний __синоним к нему, но это же не то что некроссплатформенно, а даже при переходе на другое libc может сломаться (у libc-шных хедеров такой проблемы понятное дело нет). И даже нормального способа выяснить инклюдил ли юзер stdarg тоже нет (можно было бы эти функции вырещать препроцессором если знать что stdarg не заинклюден - всё равно без него их вызвать не получится ведь va_list).

Что вы об этом думаете?

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

int vprintf(char const *fmt, va_list arg);

Перемещено leave из talks

http2.github.io - что это за бред? Серьёзно, они своей домашней страницей решили сделать аккаунт на гитхабе? Или это кто-то левый мимикрирует?

Последнее время стала раздражать тормознутость rdp-сеансов через remmina (на том конце xrdp, если что). Сначала думал что виноваты новые версии xrdp, но догадался запустить старую версию реммины которую не удалил. Так вот, там где 1.1.2 (+freerdp 1.1.0-beta1) работает нормально и укладывается в 5кбайт/с входящего трафика, 1.4.11 (+freerdp 2.3.0) хочет 100кбайт/с и больше и тормозит. Если поставить на паузу коннект (на уровне tcp) и вернуться через несколько часов - то приходится долго смотреть как на удалённом десктопе часы пересчитывают все минуты от начала до конца паузы. Причём - если все удалённые окна были спрятаны, то часы идут ещё относительно быстро, а если там был открыт браузер (даже без меняющихся картинок) - то это очень надолго. С 1.1.2 такого никогда не было - казалось что оно после долгих задержек просто перерисовывает экран целиком в новое состояние, не проходя все промежуточные. А может быть просто очень быстро проходит и незаметно. В настройках коннекта ничего интересного не нашёл.

В чём может быть дело?

А да ещё вспомнил уточнения. В debian jessie было 1.1.1 и работало нормально. Потом в buster было 1.3.3 и работало вообще неудовлетворительно - не помню в чём было дело, но пользоваться было вообще невозможно, откатил на 1.1.1 через полчаса попыток наладить её работу, а спустя какое-то время пересобрал 1.1.2 из исходников чтобы не зависеть от библиотек из debian 8. Затем вышел bullseye с этим 1.4.11, который поначалу понравился но затем выяснилась эта подстава.

По мотивам комментария LINUX-ORG-RU: Мир поменялся (комментарий)

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

Собственно что вы думаете о реализации и целесообразности такого?

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

Ещё стоит отметить ситуацию с GPL. Производная от GPL лицензия с запретом на обучение кодом ИИ будет с оригинальным GPL несовместима, обойти эту проблему, насколько я понимаю, невозможно, даже если того захочет сам RMS, поскольку внести задним числом какие-то уточнения в лицензии уже опубликованного GPL-софта без согласия его авторов нельзя.

Насколько, по вашему мнению, целесообразно добавление подобных пунктов в лицензии:

1) свободные пермиссивные, не имея побочных эффектов;

2) свободные с копилефтом, теряя лицензионную совместимость с много чем

? И как подобные пункты могут выглядеть, чтобы было грамотно и без бекдоров?

А может, всё не так страшно и пусть воруют код? Или же, может быть, подобные вещи должны регулироваться законами, а не лицензиями?

Имеется ввиду чтобы вместо координатных событий приходили «сдвинулось на столько-то пикселей вверх/вниз/вправо/влево» на неограниченное расстояние. В некоторых 3д-играх например такое используют для поворота камеры.

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

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

По идее надо сделать XCreateImage:

XImage *img;
img = XCreateImage(display, NULL, depth, ZPixmap, 0, (char*)data, width, height, bitmap_pad, bytes_per_line);

И тут же сразу проблема: величина bytes_per_line, да и размер памяти, который надо выделить под data, зависят от количества бит на пиксель. Ну и чтобы в data что-то записывать, их тоже надо знать. Понятное дело, что для 32-битного depth оно будет тоже 32, но в общем случае, как видно из исходников, XCreateImage для узнавания этого значения использует функцию _XGetBitsPerPixel() и затем записывает её ответ в img->bits_per_pixel (вообще можно было бы оттуда это значение и прочитать, но его надо знать уже заранее).

Несмотря на то, что она есть в /usr/include/X11/Xlib.h, смущает тут подчёркивание в начале названия этой функции, отсутствие мана к ней и то, что поиск по её названию в инете выдаёт только всякую ерунду и отсылки к исходникам Xlib. Насколько она официально публичная?

Тут вот пишут что она неофициальная, но поскольку без неё всё это сделать нормально невозможно то надо вызывать: https://bugs.launchpad.net/hf-lab/ bug/716239

С другой стороны, странно: не могу придумать, как вообще можно нормально использовать XCreateImage с немонохромным типом без знания этой величины (можно ненормально: вызываем с data=NULL, затем читаем img->bits_per_pixel и вручную ставим img->data). Вряд ли они сделали заведомо нерабочую (в рамках официальных спек) функцию в интерфейсе и за 30 лет это заметили только несколько раз.

Я естественно понимаю, что вряд ли _XGetBitsPerPixel() уберут, но интересует скорее идеально-теоретическая сторона дела с поддержкой всех вариаций X11 с начала времён.

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

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

При поднятии/выключении интерфейса ppp0 (через pppd) файрфокс явно что-то замечает, в частности шлёт запросы на свой «detectportal» и, что намного хуже, иногда (не всегда) молча обрывает текущие зависшие (из-за лагов сети) запросы без показывания страницы с ошибкой (оставляет предыдущую). Как это поведение отключить? Фф у меня всё равно через локальный прокси и разбираться с вопросами доставки запросов в инет - исключительно задача прокси, показывание ошибок включая таймауты коннектов - тоже.

Возможно ли такое? Хочу себе сделать, но лень разбираться, т.к. не уверен что это вообще штатно возможно. Может кто видел аддоны которые таким занимаются? (чтоб точно знать что можно, ну и смотреть их код как пример)

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