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-кратное ускорение.

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

https://hurl.wtf
Hurl, the Exceptional language

Hurl is a language created for one purpose: to explore a language based around exception handling as the only control flow. It was sparked from conversations between Nicole Tietz-Sokolskaya and friends from Recurse Center whose identities will be withheld for their dignity.

This site contains documentation around how to use Hurl. It also provides some examples and guidance for debugging and answers questions

https://github.com/lsyncd/lsyncd

Lsyncd watches a local directory trees event monitor interface (inotify or fsevents). It aggregates and combines events for a few seconds and then spawns one (or more) process(es) to synchronize the changes. By default this is rsync

Lsyncd is designed to synchronize a local directory tree with low profile of expected changes to a remote mirror

GitHub

GitHub - lsyncd/lsyncd: Lsyncd (Live Syncing Daemon) synchronizes local directories with remote targets

Lsyncd (Live Syncing Daemon) synchronizes local directories with remote targets - lsyncd/lsyncd