Блог*

#prog #article Лежало в закладках с аж 2023 года, при том, что давно прочитал. A fork() in the road (pdf)

The received wisdom suggests that Unix’s unusual combination of fork() and exec() for process creation was an inspired design. In this paper, we argue that fork was a clever hack for machines and programs of the 1970s that has long outlived its usefulness and is now a liability. We catalog the ways in which fork is a terrible abstraction for the modern programmer to use, describe how it compromises OS implementations, and propose alternatives. As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.

Один из главных аргументов — само существование fork() постоянно сказывается и на дизайне OS, и на дизайне программ, причём не в лучшую сторону.

#prog #gamedev #article Bevy's Fifth Birthday Да, уже пять лет существует. И да, скоро наконец-то будет редактор, по всей видимости.

Вот и всё у них так, по заветам господина Потёмкина 🤓

За сммщиком VIZIT уже выехали

You're a busy professional so the TLDR is we built an OOM monitoring system called OOMProf in eBPF that profiles Go programs at the point they are OOM kill'd capturing allocations up to the bitter end to give developers a better idea of exactly what went wrong. Запилили профайлер на eBPF для того что бы лучше понимать откуда в Go-шных программах память течёт. В статье расписана проблематика OOM и к какому решению в итоге пришли. Я расписывать не буду, потому что это всё сложно уместить в пост в Телеге. Оставлю тут ещё только куда ещё хотят развиваться Future Plans Rome wasn't built in a day! We'd like to add support for these features: - Add support for jemalloc,tcmalloc,mimalloc profiling for Rust/native programs - Add support for stack/goroutine dumps, if we fail or can't gather a memory profile it would nice to have something! OOMProf - Profiling on the Brink https://www.polarsignals.com/blog/posts/2025/08/13/oomprof GitHub проекта OOMProf is an eBPF-based process monitor that automatically captures heap profiles from Go programs just before they are killed by the Linux Out-of-Memory (OOM) killer, or on-demand for specific processes. This enables post-mortem analysis of memory usage patterns that led to OOM conditions. eBPF OOM Memory Profiler https://github.com/parca-dev/oomprof

В итоге поменяли на SUBJOY

#prog #article Fixing the Next 10,000 Aliasing Bugs Относительно старая (март 2023 года) статья, которую стоило бы опубликовать куда раньше. Статья, которая сначала демонстрирует, к каким багам может приводить алиасинг, а затем пошагово вводит отслеживание алиасинга в систему типов и в итоге приходит к... Rust. Главный аргумент статьи — почему отслеживание алиасинга в принципе может быть полезно — говорит о связи между алиасингом и инвариантами:

What do all three of these bugs have in common? In every case, an invariant was violated thanks to multiple aliased references to the same value. Invariants are essential to large scale programming, because it is impossible to hold the entire state of a system in your head at once. <...> However, code inevitably needs to temporarily violate an invariant while performing updates. The problem comes when there are multiple references to the relevant data, and another reference observes this temporarily violated invariant.

getenv в glibc по итогу всё же сделали более потокобезопасной. Причём совсем недавно, патч только в июле слили.

#prog #rust #suckassstory std::process::exit is not thread-safe in combination with C code calling exit Древний дизайн из времён, когда многопоточности не существует, вновь наносит удар! И да, проблемы те же, что и с env::{set_var, remove_var}.

#prog #rust #article Fully Automated Releases for Rust Projects Статья с очень конкретными инструкциями

На самом деле есть только два жанра видеоигр: ритм-игры и поиск предметов

Надеть платье горничной и обслужить красивую японскую девушку можно в попап-кафе Maid ni Nareru («Стать горничной») в Токио. Так-то в Японии популярны мэйд-кафе, где девочки в образе разносят гостям красивую еду и называют вас «господином» (или госпожой), а тут обратный принцип: клиент платит 4000 иен за то, чтобы полтора часа поработать горничной и приносить чай японской леди. И да, юноша тоже может стать горничной. Уверен, эта новость быстро превратится в очередной миф (зашел не в то кафе, и все - на тебя нацепили платье и отправили разносить рамен мужикам), поэтому подчеркну: это просто серия временных ивентов в одном котокафе Yorimichi Cafe Nyan & Peace. Ближайшие сессии пройдут 16 августа, билеты продаются здесь. Да, и обслуживать других клиентов не попросят - роль японской леди исполняет актриса. Так что это никакая не работа, а просто полуторачасовая косплей-фотосессия в образе горничной, за время которой вас даже накормят.

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

Исследователи из Пекина предложили алгоритм поиска кратчайших путей, который обходит Дейкстру Почти 70 лет ученые пытались сломать барьер сортировки для этой задачи. В данной работе это получилось впервые. Разбираемся ⬇️ Классический Дейкстра устроен так: мы храним вершины в приоритетной очереди и итеративно выбираем ближайшую, проверяя рёбра и обновляя расстояния, если путь через текущее ребро короче. Узкое место тут как раз в необходимости постоянно поддерживать упорядоченность большой очереди вершин. Из-за этой упорядоченности и возник так называемый «барьер сортировки». Считалось, что перебить его невозможно. Но вот, что сделали авторы тут:

1. Делим задачу на подзадачи с ограничением по максимальному расстоянию, до которого считаем пути. 2. Сжимаем «фронтир»: из вершин на границе уже найденных путей оставляем только небольшое число ключевых (пивотов). 3. Рекурсивно обрабатываем только пивоты и их ближайшие вершины, избегая полной сортировки. 4. Для остальных вершин добиваем расстояния несколькими шагами по всем рёбрам (метод в духе Беллмана–Форда). 5. Повторяем процесс, постепенно уточняя расстояния до всех вершин.

Итого, сложность Дейкстры – O(m + n log n), а BMSSP – O(m log^(2/3) n). Во втором случае логарифм растет заметно медленнее. Что это все значит для ML? Может показаться, что ничего. Но на самом деле алгоритм Дейкстры вездесущий. Например: – В графовых нейросетях на основе расстояний между вершинами часто вычисляются самые важные фичи. – Для всяких ML-алгоритмов для логистики просто незаменимо. – И даже в RL есть применение. Например, при обучении роботов среда может быть представлена как граф состояний, в котором оптимальная политика – это кратчайший путь. Вот так как-то. Исторический день, получается. Статья полностью тут, почитайте обязательно

Хотеть!