Ползает внутри - картинку загораживает собой, но он именно внутри, внешняя матовая поверхность экрана над ним. Если её прижать он перестаёт ползать, наверно можно его там и раздавить внутри но он испортит вид экрана. Я вообще не знал что там полость есть. Как его оттуда убрать?
По-моему его надо убрать. Если запрос висит - пусть висит, вдруг он через 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-ы проги (у неё могут быть подпроцессы) которые тоже надо убить.
Что касается первого, то варианта вижу два:
при открывании коннекта к иксам с помощью ядра узнавать кто вызвал connect() на той стороне и запоминать (в линуксе это getsockopt(SO_PEERCRED));
запускать каждое приложение с отдельным $DISPLAY либо Xauthority, запоминать запущеный pid и где-то хранить таблицу соответствия.
У обоих вариантов есть минус: открыть коннект может один процесс а потом так или иначе отдать сокет другому, иногда совсем другому. В случае первого варианта будет ещё чуть сложнее распознать мультипроцесс приложения. Во втором - схема слишком муторная.
Теперь о втором, варианты такие:
запоминать только один pid и с ним и работать
считать единым приложением то у чего одинаковый pgid (и обеспечить и его отделение при лаунче)
считать единым приложением то у чего одинаковый sid (и обеспечить и его отделение при лаунче)
про лаунче засовывать новый процесс в контейнер и определять по контейнеру
Минусы очевидные: первый вариант не учитывает подпроцессы (а надо?), последний - наоборот испортит возможность запустить демон (демона убьют вместе с контейнером), ну а 2-3 плохи тем что их два без чёткой разницы, и есть опасения что их некоторые могут использовать не по назначению.
Чего по-моему делать точно не нужно:
искать список с помощью дерева процессов по pid+ppid (стоит кому-то в середине заверщиться как вся ветка его потомков прячется в ppid=1)
трассировать всех, ловить 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 (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 на своих установках.
На всякий случай уточню: всё сделано исключительно для тестов и в прод пущено не будет.
| ← назад | следующие → |