В шиндовс интересно ведут себя активные бинарники, которые перезаписал. Если в линуксе вам обычно ответят "file is busy", шиндовс позволяет файл перезаписать, а оригинальный оставляет работать, но кидает в корзину со страшным именем.
В результате думал наловил говна уже из интернета, исследовал содержимое корзины дизассемблерами, пока не понял, что это мои же растоподелки.
В любом расследовании главное не выйти на самого себя.
В результате думал наловил говна уже из интернета, исследовал содержимое корзины дизассемблерами, пока не понял, что это мои же растоподелки.
В любом расследовании главное не выйти на самого себя.
Дождались. Больше никаких PREEMPT-RT патчей на новые ядра
https://arstechnica.com/gadgets/2024/09/real-time-linux-is-officially-part-of-the-kernel-after-decades-of-debate/
https://arstechnica.com/gadgets/2024/09/real-time-linux-is-officially-part-of-the-kernel-after-decades-of-debate/
Ars Technica
Real-time Linux is officially part of the kernel after decades of debate
Now you can run your space laser or audio production without specialty patches.
Заметил, что винда отлично спасает от выгорания.
Лишний раз комп включать не хочется.
Лишний раз комп включать не хочется.
ChatGPT отупел окончательно.
Есть такой давний крейт axum-server-dual-protocol - умеет слушать сразу и http и https и если надо, редиректить первое на второе. Удобно, если у вас все равно нестандартный порт у приложения.
Так вот, появилась как раз такая задача. То что крейт существует - помню, но название забыл. GPT4 мне пол часа доказывал, что такого крейта не существует и никогда не было. И предложил 100500 имплементаций, как это сделать самому (естественно, все не рабочие). Поисковик же выдал нужную ссылку примерно с третьего запроса.
Я уже серьёзно подумываю отменить подписку. Игрушка стала бесполезной. Кто там говорил, как ИИ убьёт всех программеров - подождите ещё лет 50.
Есть такой давний крейт axum-server-dual-protocol - умеет слушать сразу и http и https и если надо, редиректить первое на второе. Удобно, если у вас все равно нестандартный порт у приложения.
Так вот, появилась как раз такая задача. То что крейт существует - помню, но название забыл. GPT4 мне пол часа доказывал, что такого крейта не существует и никогда не было. И предложил 100500 имплементаций, как это сделать самому (естественно, все не рабочие). Поисковик же выдал нужную ссылку примерно с третьего запроса.
Я уже серьёзно подумываю отменить подписку. Игрушка стала бесполезной. Кто там говорил, как ИИ убьёт всех программеров - подождите ещё лет 50.
Некоторые наблюдения современного шиндовса 11
- в WSL2 совершенно кривой wayland, если работаете с гуем, лучше его вырубите. WAYLAND_DISPLAY="" спасает ситуацию
- кто-то совершенно упоротый упростил CPU profiles до примитива, теперь шиндовс по каким-то своим правилам, в зависимости от железа, решает с какой частотой должны работать ядра (ну или вы через API). но если хотите обычный нормальный Processor performance boost mode control в Power options, то его можно и включить:
Недокументированные возможности и страшные ключи. Как я от этого отвык. Шиндовс - система не для простого юзера.
- в WSL2 совершенно кривой wayland, если работаете с гуем, лучше его вырубите. WAYLAND_DISPLAY="" спасает ситуацию
- кто-то совершенно упоротый упростил CPU profiles до примитива, теперь шиндовс по каким-то своим правилам, в зависимости от железа, решает с какой частотой должны работать ядра (ну или вы через API). но если хотите обычный нормальный Processor performance boost mode control в Power options, то его можно и включить:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00\be337238-0d82-4146-a960-4f3749d470c7" -Name "Attributes" -Value 2
Недокументированные возможности и страшные ключи. Как я от этого отвык. Шиндовс - система не для простого юзера.
В Rust есть такая функция std::env::current_exe(), которая возвращает вам имя текущего исполняемого файла. Например "/bin/my". Но если файл был удален или заменен другим, значение будет "/bin/my (deleted)".
Почему? Rust тут ни при чем. Хотя частично и при чем - один из способов выяснения полного пути к текущему файлу - это определить его абсолютный путь из args[0] при запуске, либо приклеить к нему текущую папку вручную. Но поскольку в Rust рантайм минимальный - он резолвит путь файла программы в момент запроса, используя ссылку /proc/self/exe.
Которая и меняется "волшебным" образом с "/my/file" на "/my/file (deleted)", как только инода исполняемого файла помечается как удаленная (тоесть cp -f и mv тоже считаются). Почему так? В ядре любят этот суффикс исторически, чуть позже он перекочевал без изменений в пути cgroups. Считается, что это более безопасно, ядро ОС каким-то образом хочет передать вам информацию об изменении, но много вариантов у него нет.
"Фичу" следует учитывать если вы делаете продукт, который например апдейтит сам себя. Заодно она помогает от и мамкиных хакеров, у которых самообновляющиеся руткиты начинают глючить в самый неподходящий момент.
p.s. В случае если каким-то непонятным образом в системе уже есть файл "/bin/my (deleted)" поведение линка в procfs станет непредсказуемым - указывать он будет якобы на существующий, но при open по ссылке там будет находиться ваш удаленный бинарник. Вот такие чудеса.
Почему? Rust тут ни при чем. Хотя частично и при чем - один из способов выяснения полного пути к текущему файлу - это определить его абсолютный путь из args[0] при запуске, либо приклеить к нему текущую папку вручную. Но поскольку в Rust рантайм минимальный - он резолвит путь файла программы в момент запроса, используя ссылку /proc/self/exe.
Которая и меняется "волшебным" образом с "/my/file" на "/my/file (deleted)", как только инода исполняемого файла помечается как удаленная (тоесть cp -f и mv тоже считаются). Почему так? В ядре любят этот суффикс исторически, чуть позже он перекочевал без изменений в пути cgroups. Считается, что это более безопасно, ядро ОС каким-то образом хочет передать вам информацию об изменении, но много вариантов у него нет.
"Фичу" следует учитывать если вы делаете продукт, который например апдейтит сам себя. Заодно она помогает от и мамкиных хакеров, у которых самообновляющиеся руткиты начинают глючить в самый неподходящий момент.
p.s. В случае если каким-то непонятным образом в системе уже есть файл "/bin/my (deleted)" поведение линка в procfs станет непредсказуемым - указывать он будет якобы на существующий, но при open по ссылке там будет находиться ваш удаленный бинарник. Вот такие чудеса.
Ученые: квантовые компьютеры перевернут мир!
Айтишники:
https://80.lv/articles/doom-can-now-run-on-quantum-computers/
Айтишники:
https://80.lv/articles/doom-can-now-run-on-quantum-computers/
80LV
DOOM Can Now Run On Quantum Computers
Marking yet another milestone.
use std::os::unix::net::UnixDatagram;
fn main() {
let sock = UnixDatagram::bind("./sock").unwrap();
let addr = sock.local_addr().unwrap();
sock.connect_addr(&addr).unwrap();
sock.send(b"test").unwrap();
sock.recv(&mut [0; 4]).unwrap();
}
I expected to see this happen: no crash of the operating system
Instead, this happened: macOS 15.0.1 crashed
https://github.com/rust-lang/rust/issues/131374
Ставьте шиндовс!
Некоторые опции и фичи git, которыми я пользуюсь и про которые почему-то мало знают:
rerere.enabled = true - если вы один раз решили мерж-конфликты, а потом что-то пошло не так и вы отменили мерж, при повторе операции гит порешает известное сам.
pull.rebase = true - ненавижу merge при pull. эта опция говорит гиту перенести ваши новые коммиты выше тех, что приехали и история остается красивой.
ну и конечно git push --force-with-lease - если уже делаете force push, это не даст вам затереть изменения коллег.
rerere.enabled = true - если вы один раз решили мерж-конфликты, а потом что-то пошло не так и вы отменили мерж, при повторе операции гит порешает известное сам.
pull.rebase = true - ненавижу merge при pull. эта опция говорит гиту перенести ваши новые коммиты выше тех, что приехали и история остается красивой.
ну и конечно git push --force-with-lease - если уже делаете force push, это не даст вам затереть изменения коллег.
Как-то мимо меня вышла в этом году Operation Galuga (да, лично от легендарной Konami). По сути римейк классической контры NES, но с более расширенным функционалом. И на фоне валят оригинальные треки в современных ремиксах.
Дидам играть всем, взять валокардин, чтоб не сильно ностальгировать о лихих 90х, когда еще всё мог.
Еще выпустите римейк Hard Corps и можно помирать.
Дидам играть всем, взять валокардин, чтоб не сильно ностальгировать о лихих 90х, когда еще всё мог.
Еще выпустите римейк Hard Corps и можно помирать.
При использовании асинхронного кода, необходимо всегда помнить про синхронную нагрузку и запускать такие задачи в отдельных потоках, чтобы не блокировать async runtime. Особенно это важно при разработке real-time приложений, где блокировка рантайма уже на пару миллисекунд может сломать всю вашу low-latency конструкцию.
Кроме традиционных синхронных задач (шифрование, сериализация, компрессия и т.д.) часто забывается, что malloc - тоже очень неприятная штука. Например, 10 мегабайт на вектор может выделяться до пары миллисекунд на приличном процессоре уровня AMD 5950X, ембед же уровня Cortex A-72 может на таком застрять и на 10ms. В случае невозможности использования re-use буфера (например он уже пошел отправляться клиентам, а мы читаем следующий), аллокацию памяти необходимо выносить в синхронные задачи.
В последней BUS/RT мы добавили брокеру опцию direct_alloc_limit, позволяющую вынести аллокации выше лимита (это делается, когда sender прислал большой блок данных) на отдельный вспомогательный аллокатор. Который, в зависимости от структуры проекта, может просто создавать векторы в spawn_blocking, либо общаться с отдельным, отвечающим за это потоком, который находится на отдельной группе CPU. Также, аллокатор может вообще запретить выделение блока, руководствуясь собственной логикой относительно идентификатора клиента, либо общей.
Таким образом, в нашем IPC-брокере появилась крутая возможность безопасно совмещать low-latency (<100us) клиентов с high-load, читающими гигабайты из баз. В одной системе и без ущерба друг для друга.
Кроме традиционных синхронных задач (шифрование, сериализация, компрессия и т.д.) часто забывается, что malloc - тоже очень неприятная штука. Например, 10 мегабайт на вектор может выделяться до пары миллисекунд на приличном процессоре уровня AMD 5950X, ембед же уровня Cortex A-72 может на таком застрять и на 10ms. В случае невозможности использования re-use буфера (например он уже пошел отправляться клиентам, а мы читаем следующий), аллокацию памяти необходимо выносить в синхронные задачи.
В последней BUS/RT мы добавили брокеру опцию direct_alloc_limit, позволяющую вынести аллокации выше лимита (это делается, когда sender прислал большой блок данных) на отдельный вспомогательный аллокатор. Который, в зависимости от структуры проекта, может просто создавать векторы в spawn_blocking, либо общаться с отдельным, отвечающим за это потоком, который находится на отдельной группе CPU. Также, аллокатор может вообще запретить выделение блока, руководствуясь собственной логикой относительно идентификатора клиента, либо общей.
Таким образом, в нашем IPC-брокере появилась крутая возможность безопасно совмещать low-latency (<100us) клиентов с high-load, читающими гигабайты из баз. В одной системе и без ущерба друг для друга.