Надо внести в оффтопик-лист вопросы про «как скачать обход блокировок» и подобное, только не знаю как точно сформулировать.

По мотивам Теория параболического зеркала для э/м излучения

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

----

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

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

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

А навёл его ток, полностью автономно и без участия магнетизма вообще, смортим внимательней уравнение: rot B = dE/dt + j или dE/dt = rot B - j (коэфициенты опущены для простоты), т.е. если куда-то течёт ток - то там сразу же наводится противодействующее току э.д.с. Не обязательно в катушке, можно и в обычной прямой проволоке. Почему в проволоке этот эффект намного слабее, чем в катушке? Потому что проволока одна, и наведённое поле стремится расползтись в стороны, где его ещё нет, и таким образом возле тока остаётся слабым, а вот в катушке рядом много проволок и все наводят поле концентрированно в маленьком пространстве. Чтобы увидеть механизм расползания, сделайте из двух уравнений один дифур второго порядка - там будет вторая производная по времени равна второй производной по пространству (по сути это радиоизлучение). Надо заметить - это э.д.с. наводится любым током, как переменным, так и постоянным, и сколь угодно долго по времени. Но есть ещё один фактор: то самое магнитное поле в сердечнике - оно начинает наводиться благодаря dB/dt = -rot E, растёт со временем и начинает наводить своё э.д.с, уже не мешающее току, а помогающее. Со временем это приводит сначала к занулению dE/dt, затем к смене его знака и началу уменьшения E (а магнитное поле всё ещё растёт), и скорее всего увеличению тока (т.к. уменьшается мешающее э.д.с).

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

Смотрю что-то почти все окна (штук 30) пропали. Сначала подумал что это wm почему-то их потерял, но нет

**
VTE:ERROR:../src/vtestream-file.h:403:void _vte_snake_reset(VteSnake*, gsize): assertion failed (offset >= snake->tail): (0 >= 4294901760)
Bail out! VTE:ERROR:../src/vtestream-file.h:403:void _vte_snake_reset(VteSnake*, gsize): assertion failed (offset >= snake->tail): (0 >= 4294901760)
Aborted

вот так вот, из-за того что авторы libvte посчитали какой-то 32-битный счётчик бесконечным и не предусмотрели врап, упавший xfce4-terminal похоронил бережно накопленное за полгода работы состояние окон, по которому я уже привык ориентироваться в текущих делах.

Судя потому, что у пакета libvte указан homepage на gnome.org, виноваты как всегда гномеры.

К счастью, одно весьма важное окно с 10 вкладками было открыто с --disable-server и его этот краш не зацепил. Возможно надо по-дефолту этот режим использовать.

Давайте продолжим тему (она в архиве 2011 год) Померяемся мониторами (и глазами)

Ссылка чуть обновилась (со старой редиректит) https://www.xrite.com/hue-test?lang=en&pageid=77

У меня 4

Монитор NEC MultiSync EA232WMi

up: увеличил яркость с минимальной до максимальной, стало 0

Это non-systemd мод к debian 11 если что. До обновления в списке установленных пакетов у меня был бардак с фиктивными статусами manual/auto и соответственно в autoremove показывало длинный список из частично нужных пакетов, в котором я предварительно разбираться не захотел и стал обновлять как есть.

В начале оказалось довольно просто - ну разумеется update/upgrade, поставить штатно 64-битное ядро. Скачать (apt install --download-only) amd64 версии dpkg, apt, apt-utils, в официальном дебиановском мануале был ещё tar непонятно зачем, тоже скачал, и perl-base - а вот с ним проблема, apt усматривал в его скачивании пачку конфликтов и ничего не делал, поэтому я на него забил. Ну и установить через dpkg -i всё скачанное (через apt не получится - он найдёт там битые зависимости).

После установки 64-битного dpkg/apt всё стало ломаться - apt стал считать 64 нативной архитектурой, а это, как оказалось, означает что все пакеты с архитектурой :all приравниваются теперь к ней, а не к :i386, и куча зависимостей, как all->i386 так и i386->all оказались сломанными, и даже apt install -f их починить не мог (но я б всё равно не стал его наобум запускать, он бы кучу всего сломал с учётом фиктивных auto/manual статусов). Да, удивительно, там такая вот костыльная реализация дерева зависимостей в применении к all, и полазив пару часов по исходникам apt я не нашёл способа это быстро пофиксить.

Было решено пойти методом грязных хаков - открыл в mcedit-е файл /var/lib/dpkg/status и прописал там всем неожиданно ставшим неподходящими i386-пакетам-чьим-то-зависимостям тег Multi-Arch: foreign (хотел составить список хакнутых пакетов чтоб потом исправить назад но запорол его и списка нет), а там где сломалась зависимость i386->all - в Depends i386-пакета дописывал сломанным зависимостям явное :all. Параллельно с этим, если дело касалось multiarch-совместимых библиотек, которые можно ставить параллельно обе архитектуры, просто честно ставил amd64 (откатившись на 32-битный dpkg/apt чтоб всё работало). Узнал неприятный факт - если в Depends прописана зависимость с архитектурой :any - она ломается без внятной диагностики если у пакета-зависимости стоит Multi-Arch: foreign или same (и не нашёл где это задокументировано), так вышло с тем самым перлом на который я забил в начале. Правда не с perl-base (его оказалось можно протащить 32-битный очень долго, обновляя остальное) а с самим perl. Скачал его и ещё 3 нужных ему пакета apt-get download (он не смотрит зависимости автоматически и не ломается от них) и поставил через dpkg -i. Потом ещё остались разные мусорные libXXX-XXX-perl, половина из которых all, половина i386, которые конфликтовали друг с другом и мешали всё делать, снёс их все через dpkg -r --force-depends чтобы потом уже ставить. Несмотря на то, что дебиановцы считают перл критически важным пакетом, на самом деле для более-менее рабочей системы он не нужен. По крайней мере шелл и пакетный менеджер точно прекрасно обходятся без него.

apt в конце концов пришёл в консистетное состояние и дальнейшее можно было делать через него. (если что, до этого никакие install -f, upgrade или dist-upgrade, указанные в мануале как штатное средство такого апгрейда, работать даже не пытались и жаловались на битые зависимости). Установил 64-битный драйвер nvidia и иксы, можно ребутнуться в наконец в гуи вместо 80х25 консолей.

Потом ещё часов 5 ручного разбора смешанной свалки 32/64 пакетов, удаления ненужного, установки нужного в amd64. Правда часть пакетов так и осталась i386, да и пофиг, всё работает, когда-нить с апдейтом версии переставятся на 64 наверно. Ну и wine разумеется нужен 32-битный со всеми его зависимостями - не трогал имеющийся, всё работает.

Итог: стартовое лагание файрфокса с лазанием по диску (не ssd) удлинилось раза в 3 (было секунд 10, стало около 30). То есть фф уже запустился, но всё делает медленно и видно что всё его время занято i/o. В остальном особых изменений не заметил.

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

описание тега Multi-Arch в .deb пакетах (для хакинга файла базы /var/lib/dpkg/status)

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

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

Пытался разобрать аккум своего ноута, там толи склеено толи сложнооткрываемые защёлки, но в итоге часть пластмассы отломалась и через дырку видно что-то похожее на батарейку 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 {

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

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