Nenašel by se tu ostřílený programátor C, který by měl po večerech čas se přidat k hodně slibnému cybersecurity startupu? Kdyžtak pls pošta.

Jestli neco do Jupyter Notebooku stoji za to, tak je to jupyter c kernel
Programming in C with Jupyter Notebook - Xuedong Shang
https://xuedong.github.io/programming/2017/12/27/jupyter-c-kernel.html

Konkrétně, skrz sys_clone:
linux kernel - What are parameters of sys_clone() system call and how to hook it in Ubuntu? - Stack Overflow
https://stackoverflow.com/...at-are-parameters-of-sys-clone-system-call-and-how-to-hook-it-in-ubuntu
Druhý parametr tohohle volání jádra je pointer na vlastní stack vlákna, bez kterého by spuštění vlákna bylo nebezpečné a skoro nepoužitelné.

(Bylo by to Linux specifické, ne POSIXové... a samozřejmě, když by se rozhodli to API mezi verzemi kernelu nějak změnit, tak se mi to celé sesype... ale mě se POSIXové thready nezamlouvají jako vhodný způsob myšlení o paralelizaci kódu)

(Uvažuju totiž o nějakém multithread frameworku, ale spíš než nastartovat si na začátku pool threadů a nějak ho úkolovat bych chtěl využít linux-specifickou vlastnost startu nového threadu ve stylu forku, konkrétně je to nějaký ARCH_FORK() a systémové volání clone(), pozor nikoliv ten clone() o level nad tím.. v zásadě jediné, co nové vlákno doopravdy nutně potřebuje, je vlastní stack, tak uvažuju místo poolu vláken na začátku alokovat pool stacků odpovídající max. počtu vláken které chci používat, a v místě startu nového vlákna si jen hlídat, zda jsem ten na začátku odhadnutý počet vláken nepřekročil... další mechanismy které mi napadají v místě, kde si můžu vybrat jestli paralelizace ano či ne, by např. kromě počtu aktivních vláken byl i počet mikrosekund od poslední paralelizace, aby se třeba zbytečně neparalelizovali velmi rychle probíhající cykly apod)

How to get the number of CPUs in Linux using C? - Stack Overflow
https://stackoverflow.com/questions/4586405/how-to-get-the-number-of-cpus-in-linux-using-c

XCHAOS: Děláme ve špatném odvětví...

2019's Fastest Growing Programming Language Was C, Says TIOBE - Slashdot
https://developers.slashdot.org/...32230/2019s-fastest-growing-programming-language-was-c-says-tiobe

(jo ten člověk byl pak známější jako autor Scramble, co jsem pochopil.. no pro mě byly 8bit hry v assembleru nedostižný mýtus, já matlal věci jen v Basicu... )

JANFROG: jsem tam ještě doklikal rozhovor s původním autorem toho bludiště a ten zní úplně normálně :-) prý měl proste bludiště, které nemělo žádný herní námět a předal jim ho a oni ho brutálně osekali, aby se k tomu vešla ještě hra.

stejně je to síla, psát programy u kterých se zapisje jen do pár bajtů. dnes jsou lidi šíleně zmlsaný...

K předchozímu: Regardless of which version of events is followed, it seems fair to say that some level
of intoxication was involved in the development of the maze algorithm.

No, aspoň tahle archeologie ukazuje, že Céčko bylo ve své době fakt high-level :))

Trocha opravdového assembleru z historie (i pro mě je tohle historie, já se poprvé setkal až se Z80 :-). link via Slashdot...
https://arxiv.org/ftp/arxiv/papers/1811/1811.02035.pdf