A unixos "yes" parancs története

UNIX, UNIX-szerű

Egy érdekes sztori arról, hogy mire lehet használni az egyik legegyszerűbb unixos parancsot, a "yes"-t, hogy miért nem egyszerű 1-2 sornyi kódban újraírni (pedig lehetne), hogy miért 128 sornyi kódból áll a GNU verziója és hogy 30 év után még mindig miért van aktív fejlesztés alatt.

( kruska v | 2022. 07. 21., cs – 13:12 )

Az ilyesmikért szerettem bele a linuxba még a múlt évezredben.

yes | sh boring_installation.sh

( YleGreg | 2022. 07. 21., cs – 13:19 )

Szerkesztve: 2022. 07. 21., cs – 13:21

Apro de fontos resze a kedvenc csatakigyoinknak, peldaul:

date; login; strip; unzip; touch; finger; mount; fsck; more; fsck; yes; fsck; fsck; YES! - syntax error; done; umount; clean; sleep;

LOL, eddig nem is hallottam a yes és a finger parancsokról. Az is igaz, hogy a column parancsot is először csak egy hete ismertem meg. Még évek múlva is van mindig felfedezni való új parancs.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( gelei v | 2022. 07. 21., cs – 13:36 )

Turns out, that program is quite slow.

Ja, de milyen gyorsan kell jönnie ahhoz a kérdéseknek, hogy a 4 MiB/s streamelt input legyen a szűk keresztmetszet :)

A cikk maga hülyeség, ez egy olyan felhasználási kör, aminek nem kell gigákat átvinni másodpercenként. Sőt, szerintem az a jó, ha nem nyomja túl a buffert, kevesebb hardvert fog használni. Kb. fél-egy másodpercenként elég egy ismétlés erre a célra. Ha a dd, cat, ilyesmiről lenne szó, ott még rendben van, hogy sebességre optimalizálják.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nálam egy viszonylag újabb, combosabb gépen, Arch alatt 10,3 GB/sec-et ír a  yes | pv -r > /dev/null kiadása után. Overkill ez a gyorsaság a feladatra. Igazából ez a yes parancs igényelne egy -i / --interval kapcsolót, hogy le lehessen szabályozni egész vagy tört másodpercenként egy sor kimenetre. Ha csak fél-egy másodpercenként írna az stdout-re kimenetet, az is elég lenne, már az is gyorsabb, mint az emberi interakció.

Egyértelmű a cikk alapján, hogy a mac-es implementáció lassú. Ami nem meglepő, feltette a coreutils, és máris gyorsabb lett neki is, persze még mindig lassúbb, mint egy normális rendszeren. Maga a Mac hardvere nem lehet annyival lassabb, az tiszta sor, így csak szoftverben nem lett implementálva a bufferelés.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( daf182 | 2022. 07. 21., cs – 16:56 )

Rustban. Az legacy. Carbonban lenne igazán trendi.

Lásd mai HWSW cikket. 

( Czo v | 2022. 07. 22., p – 16:35 )

Itt valami tuti fura az illetonel. 2018-as Mac, Monterey 12.5 eseten 3.46 - 3.58 GiB/s sebesseget ir, a cikkben is emlegetett "yes | pv -r > /dev/null" parancs. Valszeg, gyorsabb/ujabb gepem van, mint neki, mert a Pythonos peldakodja, a rendszer beepitett Python verziojaval (3.8.9) is 6.38 - 6.45 GiB/s sebesseget ir. 

Az mindegy, az 5 évvel ezelőtti Mac-ek sem annyira gyengék, hogy csak 4-800 MB/sec-et tudjanak ilyen téren. Bár annyiból releváns lehet, hogy 5 éves cikk, azóta a homebrew-ban vagy MacOS-ben javíthatták ezt egy jobb implementációra, mi meg azért nem értjük, mert modernebb rendszeren próbáljuk, és ott meg több giga/sec-kel megy simán.

Ezért is szoktam állandóan leírni, mikor ilyen 5-10 éves támogatási idejú LTS-eket majmolnak az ember, hogy ezeknek nincs értelme, frissíteni kell, mert nem csak új feature-öket, meg kielégíthető verziófüggőségeket kap velük az ember, de pl. ilyen sebességoptimalizációk is bekerülnek, amik dinoszauruszok korabeli verziókon még nem voltak. De valahogy nem szoktak rám hallgatni ilyen téren, le vagyok hurrogva, hogy Arch-buzi, hobbista, meg frissességmániás, fősodratú, babzsákfejlesztő, mérnök úr (nem, hajbi pechjére én se vagyok mérnök), ideálkapitalista, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

2021-ben updatelte a cikket, ahol tovabbra se huzta ki/szurkitette ki az adatokat, igy felteteleztem, hogy a 2021-ben megjelent rendszerverzion is megvan ugyonaz a "problema". 

De elokerestem egy regebbi vasat, 2.6 GHz orajelu Core 2 Duo, 2008-bol, rajta a 2017 szeptembereben megjelent High Sierra. Ezen a gepen a gyari "yes", tenyleg boduletesen rossz adatokat ir, 16.4 - 16.9 MiB/sec. Ha a GNU coreutils-ban levo yes-t nezem, az valamivel jobb, 486-600 MiB/s. A sima, gyari "yes"-nel 100%-on koppan a yes a top szerint, a GNU yes eseteben 100-on koppan a yes es a masik magot pedig megeszi a pv. Tehat ez lehet a Core 2 Duo teteje ezen a vason :D