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

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

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

Время работы аккума не совсем нравится, 10 лет назад при покупке было что-то около 4 часов, сейчас около 2 уже, думаю исправить ситуацию.

Если я выну эти 4 элемента и вставлю вместо них серийные литиевые - всё же должно поддержаться или могут быть неожиданности?

И второй вопрос - если вместо 4 элементов сделать отдельный корпус (ноут тонкий, если станет потолще я не против) под 16 штук (параллельно 4 цепи по 4) и подключить к тем же контактам куда подключаются эти внутри корпуса оригинальной батареи - всё будет норм работать или контроллер сойдёт с ума от незапланированной ёмкости (или может зарядный алгоритм для 4 аккумов будет повышенно изнашивать 16)? И как лучше подключать - просто параллельно 4 ветки по 14.4V или после каждого элемента (по 3.6) соединять все параллельные цепи?

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

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

В любом случае, какой смысл от этого таймаута я не понимаю. Если коннект на самом деле отвалился по таймауту (в ядре и прислал ECONNRESET) браузер сам об этом скажет.

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

https://security-tracker.debian.org/tracker/CVE-2022-2961 тут написано что все ядра до сих пор vulnerable

https://bugzilla.redhat.com/show_bug.cgi?id=2120595 тут закрыто с «NOTABUG»

Что это значит? Там какая-то функция rose_bind() я не знаю что это такое вообще.

Допустим есть такой код:

flag = 0;
while(!flag) {
  /* ... тут много кода, у компилятора нет шансов его оттрассировать до конца ... */
}

Где-то в другом треде однажды ставится flag = 1 (вокруг этой операции тоже много кода). И всё это без межтредовой синхронизации (точнее, где-то в другом коде она может быть, но сама по себе и с переменной flag явно не связана).

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

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

Поскольку возникло непонимание вопроса, уточняю:

static int flag;
static void * threadfunc(void *p) {
  flag = 0;
  while(!flag) {
    /* много кода */
  }
  return NULL;
}

extern void set_flag_1(void) {
  flag = 1;
}

В инете ничего по этому поводу не нашёл, сделал фикс сам.

Сам патч https://firk.cantconnect.ru/yt-dlp/yt-dlp-fix-dzen.patch

Пропатченая версия последнего (2024.04.09) yt-dlp если кому лень: https://firk.cantconnect.ru/yt-dlp/yt-dlp-2024.04.09.patched

Как патчить вручную:

Кладём yt-dlp в текущую директорию

7z x yt-dlp # unzip ругается на шебанг, поэтому 7z
patch -p0 < yt-dlp-fix-dzen.patch
zip -r yt-dlp.patched.zip __main__.py yt_dlp
echo '#!/usr/bin/env python3' > yt-dlp.patched
cat yt-dlp.patched.zip >> yt-dlp.patched 
chmod +x yt-dlp.patched

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

А?

Вне зависимости от содержания и полезности.

Возможно ли это сделать на живой системе? Т.е. zfs смонтировано и используется, параллельно переносясь на другой zpool, и после переноса продолжая на нём работать без перебоев и более не завися от старого, т.е. его можно destroy итд.

В очередной (третий-четвёртый за несколько последних лет) раз затерев по неаккуратности файл с кодом (cp не в ту сторону), на который был потрачен предыдущий час или больше, и который ещё не был закоммичен, решил что искать его с помощью dd и grep - занятие утомительное. Слышал тут про binwalk, но, посмотрев описание, то ли не осилил найти способ её для этой цели использовать, то ли она и правда для другого.

Написал свою прогу в итоге: исходник.

Компилировать: gcc -o rawsearch rawsearch.c

Синтаксис: ./rawsearch if=/dev/sda8 str=some_string_from_file

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

static int is_binchar(char c) { return (c==127 || c>=0 && c<=6 || c>=14 && c!=27 && c<=31); }

(это символы которые по мнению проги в текстовых файлах не встречаются).

Возможно кому-то будет полезно.

Исходник максимально простой (всего 300 строк и 12кб), можно легко патчить под какие-то потребности по месту.

Перенёс систему tar-ом, и как я и подозревал getcap /usr/bin/ping выдаёт пустую строчку, а на старом диске cap_net_raw=ep. Переделывать не хочу, думаю как-то найти/угадать список таких файлов и вручную починить, либо они сами после обновлений соответствующих пакетов со временем все исправятся а вручную фиксить только по мере обнаружения проблем. Что в этом плане может пойти не так и что кроме capabilities могло не скопироваться? Сам никакие экзотические свойства файлов не использую, то есть вопрос только про файлы из дефолтных дебиановских пакетов.

Кстати вроде в прошлый раз много лет назад я так же переносил debian 7 и даже не заметил ничего.

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

В нескольких местах в инете прочитал что у этой модели проблемы с линуксом. В том числе на лоре: Ubuntu server 20.04.2 + Samsung 870 EVO 1TB

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

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

Сразу скажу: это как-то реализовано в крупных DE, но я не знаю как и знать не хочу - так что просьба туда не смотреть. Вопрос о том, как должно быть правильно (вне зависимости от того как уже где-то сделано). Возможно, тема не для desktop а для dev, не знаю.

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

Проблема разделяется на две: 1) сопоставить окно и pid, 2) найти все побочные pid-ы проги (у неё могут быть подпроцессы) которые тоже надо убить.

Что касается первого, то варианта вижу два:

1. при открывании коннекта к иксам с помощью ядра узнавать кто вызвал connect() на той стороне и запоминать (в линуксе это getsockopt(SO_PEERCRED));

2. запускать каждое приложение с отдельным $DISPLAY либо Xauthority, запоминать запущеный pid и где-то хранить таблицу соответствия.

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

Теперь о втором, варианты такие:

1. запоминать только один pid и с ним и работать

2. считать единым приложением то у чего одинаковый pgid (и обеспечить и его отделение при лаунче)

3. считать единым приложением то у чего одинаковый sid (и обеспечить и его отделение при лаунче)

4. про лаунче засовывать новый процесс в контейнер и определять по контейнеру

Минусы очевидные: первый вариант не учитывает подпроцессы (а надо?), последний - наоборот испортит возможность запустить демон (демона убьют вместе с контейнером), ну а 2-3 плохи тем что их два без чёткой разницы, и есть опасения что их некоторые могут использовать не по назначению.

Чего по-моему делать точно не нужно:

1. искать список с помощью дерева процессов по pid+ppid (стоит кому-то в середине заверщиться как вся ветка его потомков прячется в ppid=1)

2. трассировать всех, ловить fork() и запоминать то же дерево но без потерь (слишком накладно и вызовет конфликты с отладчиками).

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

Что думаете по поводу всех поднятых вопросов?

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

(исходники от 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 но не вижу там указания на 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 (комментарий)

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

Опубликована 83-я версия кэширующего и антиспамного прокси-сервера для персонального использования c гибкими настройками.

Основные функции (всё настраивается):

1. фильтрация нежелательного контента (белые/чёрные списки на урлы, запрет кук);
2. принудительное и бессрочное кеширование полученных данных (в основном удобно для картинок и скриптов);
3. исправление содержимого веб-страниц на лету (правкой исходника на Си, есть пример для замены содержания страниц-клонов stackoverflow ссылкой на оригинал);
4. чёрные/белые списки сертификатов и certificate pinning по списку;
5. подмена айпи-адреса/домена/пути/протокола http-запроса по конфигу (такой расширенный вариант /etc/hosts);
6. http/https-сниффер.

Прекрасно подходит для просмотра сайтов через медленный интернет или с медленного устройства (благодаря п.1 и 2, ради которых изначально всё и затевалось), но вообще полезно в любом случае.

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

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

Пример списка блокировки:

deny    nosub   all     share.yandex.ru browser-updater.yandex.net
deny    nosub   all     a.ria.ru # ?
deny    nosub   spec    vk.com
                query   /share.php
deny    nosub   spec    yastatic.net
                query   /pcode/adfox/loader.js
                query   /share2/share.js
deny    nosub   spec    www.youtube.com
                query   /subscribe_widget
deny    nosub   spec    pano.img.ria.ru
                query   /adriver/flashplagin/movie.swf
deny    nosub   spec    a.ria.ru
                query   /ping
deny    nosub   spec    n-ssl.ria.ru
                query   /polling
deny    nosub   spec    apis.google.com
                query   /js/plusone.js
deny    nosub   spec    yandex.ru
                pref    /clck/safeclick/
                pref    /clck/click/
                pref    /clck/jclck/
deny    all     spec
                query   /tnc    # index.ru proxied counter
                exact   /tnc.js # index.ru proxied counter
                query   /pixel.gif # some spammers use this

Пример списка роутинга:

https://my.local.site
        set proxy none
        set target http://127.0.0.1:1234/localsite
        set http_host new.host:1234
.intel.com
        resolve off
        set proxy socks5://127.0.0.1:3333

В случае обновления с версии более старой чем 78 следует сконвертировать кеш: зайти в рабочую директорию прокси-сервера от юзера (uid/gid) прокси-сервера и выполнить fproxy-cacheconv-78 (по умолчанию эта программа не компилируется).

Изменения с прошлой опублированной версии (80):

1. fproxy-dashboard теперь имеет опцию для показа размеров контента в байтах а не кбайтах;
2. поддержка багнутых серверов, игнорирующих заголовок «Connection: close»;
3. поддержка багнутых серверов, отдающих некорректный заголовок «Content-Encoding: identity»;
4. отправка TLS-опции ALPN;
5. улучшение работы TLS-терминатора внешней стороны (клиента): он теперь поддерживает не только TLS, но и обычные соединения, поддерживает работу в виде независимого демона с приёмом запросов от основного прокси по сети, а также может пробрасывать свои исходящие соединения через другое прокси, таким образом позволяя гибко разделять задачи между узлами в условиях плохого интернет-соединения и/или необходимости организовать «выход» трафика где-то на удалённом сервере разной степени доверенности; так же новая версия более удобна для использования вручную из командной строки в качестве консольного TLS-клиента с поддержкой проксирования;
6. упрощена сборка, теперь есть Makefile вместо шелл-скриптов
7. организованы предсобранные .deb-пакеты в репозитории (для версий Debian 8-12)
8. изменения файла конфигурации, обратно-несовместимые
9. новый конфиг для управления роутингом запросов, объединивший ранее бывшие отдельными конфиги resolv и включения проброса исходящих соединений на удалённый сервер, а так же получивший ряд новых опций: теперь можно для каждого url-а (протокол, домен, порт, путь) выбирать через какой клиент, какое прокси он будет отправлен, через чей днс-сервер будет проводиться определение его айпи-адреса (включая опциональное делегирование этой задачи внешнему прокси-серверу http или socks5), либо прописать адрес вручную, а так же заменить протокол, порт или префикс пути url-а
10. добавлена поддержка SAN-сертификатов для ip-адресов и в клиенте и в сервере (браузеры с некоторых пор перестали принимать ip-адреса в CommonName)

В планах на будущее:

1. поддержка CGI/FastCGI/.so хуков для mitm-обработки полученного от сайтов контента
2. менеджер профилей и конфигураций прокси
3. интерактивное управление проверкой сертификатов удалёных сайтов и списками блокировок

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

Время от времени хотелось чтоб был некий дамп схемы использования физических накопителей разными файловыми системами, чтобы не лазить отдельно по 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