Vlákno názorů k článku
uutils 0.0.16, Rust náhrada GNU Coreutils má přepracovaný tail od Pavel Píša - Zajímalo by mě porovnání celkové velikosti binárek mezi...

Zajímalo by mě porovnání celkové velikosti binárek mezi GNU, busybox a Rust implementací, případně jestli Rust verze linkuje vše na jeden binární soubor....

Tak mi to nedalo a stáhl jsem si Rust verzi z Debianu na prohlédnutí

https://packages.debian.org/sid/rust-coreutils

Obsahuje jednu binárku /usr/bin/coreutils s délkou 22MB, která je odkazovaná individuálními symlinky z /usr/lib/cargo/bin/co­reutils.

Binárka se odkazuje na standardní sadu GNU libC *.so files - libm, libc, libpthread a dokonce libpcre.

Kompletní GNU coreutils pro sida

https://packages.debian.org/sid/coreutils

mají celé po rozbalení kupodivu také 21MB. V /bin mají ale jen 2.2 MB a v /usr/bin 4.7MB. 12M je v /usr/share, tedy dokumentace. Pomocná sdílená knihovna 14kB. Většina utilit nemá závislost na pthread, to se může třeba u ramdisku na embedded systému a chrootu hodit.

Funkcionalitu, pokrytí příkazů a parametrů, asi v tuto chvíli porovnat nedokáži.

S tím, že především u koncových aplikací má smysl uvažovat o jazycích a prostředích s vyšší úrovní kontroly práce s pamětí již v době kompilace, návrhu souhlasím. Ale u těch částí, které se používají velmi v širokém spektru systémů od malých embedded až po vetší a nejsou přímo vlastn narychlo psanou koncovou aplikací mi připadá že je spíš důležitá kontrola kódu zpětně coccinelle, sparse atd... a časový overhead s kontrolou a implementací v C není až velký problém.

Smysl OSS je podle mě i v tom, že se dá rozumně studovat a modifikovat. Což u spousty různých systémových toolů, kde se to hemží #ifdefy, goto apod., z mého hlediska, moc neplatí. Ale samozřejmě nemám nic proti tomu, aby existovaly ty "prověřené" hardcore implementace - jen se jim pokusím osobně vyhýbat.