Кассовый чек на 502 ₽ от ООО Эй Кей Раша
https://gcc.gnu.org/pipermail/gcc-rust/2024-May/001735.html

https://github.com/meithecatte/cursedfs

So, you want to use Windows 2000 in 2024? Well, you've come to the right place...
https://w2k.phreaknet.org/guide

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

Winamp Legacy player source code - https://github.com/WinampDesktop/winamp

https://www.nand2tetris.org/
This website contains all the lectures, project materials and tools necessary for building a general-purpose computer system and a modern software hierarchy from the ground up.

The materials are aimed at students, instructors, and self-learners.

https://github.com/lvkv/whenfs/

Сидел я сегодня такой, развлекался с Nix'ом и внезапно обнаружил, что конструкции вида nix shell nixpkgs\#hello \-c bash в шебанге и Linux и MacOS отрабатывают совершенно по-разному.

Краткая справка: Шебанг (shebang) - это конструкция вида \#!interpreter [args] (\#! обязателен), расположенная строго в начале файла, и говорящая операционной системе запустить interpreter [args] [original file] [original args].
Была придумана, чтобы не писать руками python script.py, а сделать ./script.py, условный.

Когда функциональность уровня ядра ведет себя как-то неправильно, первое и логичное решение... пойти копаться в сорцах этого самого ядра.

Спасибо эплу, некоторым лицензиям, и неизвестному самаритянину (насколько я знаю, это неофициальное зеркало) - у нас есть код XNU (ядро MacOS) на гитхабе.

Непродолжительные поиски действительно привели меня к строке, в которой определяется условие конец шебанга, где концом строки считается либо \#, либо \n.
Окей, теперь я знаю, что у меня нет шизофрении ~~(на самом деле есть)~~, и это действительно ядро ведет себя так странно.
Встает следующий вопрос: а почему оно так себя ведет?

Если посмотреть на путь к файлу kern_exec.c, можно увидеть, что он начинается с папки bsd.
Так возможно это не у apple что-то с головой, а они просто бэкпортировали какое-то странное изменение из ядра *BSD? (Да, XNU основан во многом на BSD)

Быстро пробежавшись по старым BSD ядрам (4.3BSD, FreeBSD версий 2-3) я ничего полезного не нашел, там этой особенности* не было.

Дальше я решил вернуться обратно к blame'у сорцов XNU. К сожалению, текстов коммитов нет (разве что где-то в недрах Apple), поэтому остается довольствовать описаниями версий, в которых что-то меняли.
Таким образом я узнал, что это добавили в XNU-517.

Быстрый гуглеж по XNU-517 shebang наконец-то привел меня к цели всего поста: шедевральной страничке https://www.in-ulm.de/~mascheck/various/shebang/, содержащей огромный и очень информативный текст (я не шучу, сходите сами почитайте!) про историю шебангов.

Конкретно про обработку второй \# - тут.
Как оказалось, я смотрел слишком ранние версии FreeBSD - это действительно внесли именно в ней, в 4.0 ветке, а потом убрали в 6.0.
XNU бэкпортировали это к себе, но так и не убрали, только рефакторя код год за годом (стало кстати объективно лучше, тоже забавное наблюдение).

Итак. Изначальной причиной появления такого способа обработки \# в шебангах была...
Рекомендация в документации к perl'у писать шебанг следующим образом:

```

#!/bin/sh -- # -- perl -- -p
```

чтобы избегать каких-то странных кроссплатформенных проблем (да, утилиту env тогда ещё не придумали).

Зайдите ещё в комменты, там есть парочка мемов, которые не влезли в пост =)

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

И согласно нему, мы практически в заднице: даже у программы, содержащей всего 1% последовательных вычислений (т.е. операций, зависящих от результата других операций) предел ускорения - 100 раз. Сколько бы ядер мы ни добавляли в систему. Быстрее, чем в 100 раз программа работать не станет.

В реальности же, программ с 1% последовательных вычислений не существует. И даже программ с 10% (для которых предел - 10-кратное укорение) исчезающе мало.

А для программ в которых последовательных вычислений половина - предел ускорения - 2 раза.

Как вы догадываетесь, в тех же игрушках, например, последовательных вычислений даже больше половины.

Вот и думайте теперь...

Однако, не всё так печально: в нашем мире существует так же и Закон Густавсона-Барриса, у которого шанс, что вы о нём слышали стремится к нулю, но который, тем не менее, переосмысливает закон Амдала, смотря на "производительность" под другим углом и вселяет надежду.

Закон Амдала предполагает что фиксированным является объём задачи (грубо говоря - количество действий).
И это вполне справедливо применительно к текущим компьютерам, программам и ОС.

Однако же закон Г-Б рассматривает ситуацию с точки зрения ОС реального времени (типа тех, которые используются на космических аппаратах):
у каждой задачи есть лимит времени, в течение которого она может выполняться, вне зависимости от того, успела ли она, или нет.
Иначе аппарату может настать капут (особенно актуально для солнечных зондов, которые тусуются намного ближе к солнцу, чем даже Меркурий).

Так вот, в случае закона Г-Б (и ОС РВ) ситуация с распараллеливанием НАМНОГО более благоприятная.

Посмотрим рассчёты (на консльном калькуляторе bc, если что. Надеюсь, ни для кого не будет проблемой разобрать синтаксис):

```
$ bc -l <<< 'n=10; s=0.01; print "Amdall: ",1/(s+((1-s)/n)),"\n","Gust-Bars: ",n+(1-n)*s,"\n"'
Amdall: 9.17431192660550458715
Gust-Bars: 9.91

$ bc -l <<< 'n=100; s=0.01; print "Amdall: ",1/(s+((1-s)/n)),"\n","Gust-Bars: ",n+(1-n)*s,"\n"'
Amdall: 50.25125628140703517587
Gust-Bars: 99.01

$ bc -l <<< 'n=1000; s=0.01; print "Amdall: ",1/(s+((1-s)/n)),"\n","Gust-Bars: ",n+(1-n)*s,"\n"'
Amdall: 90.99181073703366696997
Gust-Bars: 990.01

$ bc -l <<< 'n=100000; s=0.01; print "Amdall: ",1/(s+((1-s)/n)),"\n","Gust-Bars: ",n+(1-n)*s,"\n"'
Amdall: 99.90109791306606459604
Gust-Bars: 99000.01
```

где:
n = к-во вычислительных ядер (процессоров),
s = коэффициент (% от 1) последовательных вычислений,
а остальное вам и не нужно (там формулы и print) ?

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

Мораль, думаю, понятна ?