Názory k článku Softwarová sklizeň (23. 7. 2025): ovládněte prezentaci po síti
-
No mfetch ma jediny zdrojovy soubor o 150 lajnach v rustu, a v reelase zadna bianrka neni, takze t u vkladam duveru do auditu skrze opensource komunity. Rchle cteni rika ze to neni nic vic nez byse sescriptilo v bashi za par minut, ale hezky to je, o tom zadna :)
Na prvotinu v rustu tak akorat: https://github.com/xdearboy/mfetch/blob/main/src/main.rs
-
44 sec s Gemini.. :D
https://github.com/martyd420/mfetch-bash/blob/master/mfetch.sh -
Dal jsem tomu ještě hodinku promptování..
https://github.com/martyd420/mfetch-bash -
A není lepší používat standardní programy, pokud si člověk není jistý ? Např. pro informace o HW je zde lshw, pro informace o využití paměti procesy potom [h]top, případně pro základní náhled standardní unixová utilita free, apod. Podle mě je tohle pro uživatele jednodušší, než se patlat s nějakými novonedodělky.
-
Na článek jsem kliknul hlavně kvůli mfetch a překvalipo mě, že tady v tu chvíli byly 2 komentáře a oba k mfetch. Za mě to dává smysl, občas přesně tohle potřebuju - rychle a přehledně zobrazené základní info o RAM a jednotlivých modulech, aniž bych to musel detektivně grepovat z lshw, dmidecode, apod.
Zkusil jsem teda tu první bash verzi udělat pomocí AI (Gemini 2.5 pro přes aistudio) a vlastně se mi to dost líbí a mám v plánu to příští víkend rozšířit (přidat ramdisky, zfs cache, zram, výstup do jsonu, ...) -
Je to jednodusi. Ale....
Mam kolegu, ktery zasadne pouziva `find | grep | grep ....` misto `find -a -nejaky -divny -swithce` odpoved je ze se munechce hrabat, ani se ucit, tech milion switchu ve findu...
Tohel je skoro to stejny - z dmidecode, lshw a spol, se grepuje o sto6. Nektere klice clovek zapomene a musi je dohledat, jiny si casem zapamatuje. Udelat rozumny udelatko co grepuje susbet je dobre.
-
Jj, taky vždycky chvilku přemýším nad tím příkazem a pak si vzpomenu na https://www.vtipkar.cz/vtip/kdyby-byl-operacni-system-jako-cesta-autem-na-nakupms-dos-nastoupite a už vím, že GREP je to, co hledám :-)
-
-
Tohle frikulin devel nikdy nepochopi. Proc pouzivat standartni tooly ktere jsou auditovatelne, otestovane alespon komunitou a s definovanym chovanim.
Ja vzdycky bojuju s tim ktery exkrement si zas develove do systemu pritahli. Po nekolika mandayich stouchani do kodu prijdu na to ze devel si neoveril funkcionalitu knihovny.
A za tuhle zbytecnou praci i nekoho plati... -
Reaguji na uzivatele "binárně-transfóbní dezolát". Jako prestarlemu unixakovi mi to tezko muze vadit. V mnoha systemech se bez sloziteho prezvykovani udaju neobejdete. Obcas vas omezuji i standartni POSIX omezeni kdy nemuzete pouzit GNU nastroje ale musite pipovat ruzne skopiciny pres x toolu.
Co je jednodussi? Napsat script a nebo si ho auditovat? Kde ho nasazuji? U mne doma a nebo ve firme? V jakem prostredi s jak prisnymi bezpecnostnimi pozadavky? Jak budu resit kdyz to nebude fungovat? Kdo je kontaktni osoba?
Jinak to muze skoncit tak ze devel si pritahne tool, ale stravime 3 tydny na review. Misto toho aby si to nascriptil sam nebo s AI (ktere ma dovoleno a je provozovano na vlastni infrastrukture - rozumej na nasem zeleze ).
Jako nevadi at si ho pritahne, ale at se nedivi ze jsem extremne toxicka osoba ktera patchovala nebo musela stravit 2 hodiny na meatingu jen za ten ten jeho prasismus co on vlastne sam netusi jak funguje. -
Pravda je nekde mezi. Nebranim se novym nastrojum pokud jejich nefunkcionalitu nehazou na mne ktery je neimplementoval. Takove ty neurcite narky ve smyslu je rozbity OS, sit ci infrastruktura a nebo osoba XY ktera delala do kernelu vlastne nevi jak kernel funguje :-P Pokud si programator uvedomuje ze nastroj nemusi pracovat podle jeho predstav a vi odkud nastroj pritahl tak je to vetsinou v poradku. Ale to je nejak posledni leta je velmi zridkavy jev. Spise to pripomina male deti patlajici na sebe lego a dortik od maminky s vizi toho ze stavi hrad v oblacich.
Mam velky problem. Tim ze mne kdysi zivilo neco jako programovani tak na mne tahle prace vetsinou spadne neb clovek mezi jednookymi kralem jest Problem je kdyz se clovek osvedci.
To ze na mne spadne znamena ze zanedbavam dlouhodobe projekty jinde. Problem je tez to ze nezodpovedny devel z toho vetsinou vyvazne bez skrabancu. -
Je-li arogantni namyslenosti myslena opatrnost a braneni se pridelavani prace mimo hlavni cinnost tak to neberu jako spatny odhad. Je-li tim mysleno ze mame ve firme spatne resenou implementaci novych technologii muze to byt tez pravda.
Odbornost IMHO vylucuje pritazeni neceho co netusim jak funguje a jake muze mit interakce s ostatnimi komponentami. Programator ani architekt neni ten kdo pracuje jako kdyz kocicka a pejsek varili dort. A nemel by byt ani tim ktery ten blevajz hodi na krk infrastrukture jejichz cilem je neco jineho nez resit cizi problemy.
Odbornost taktez vylucuje i absence sirsi rozhledu, ktery by mel v pripade zaneseni neceho noveho do architektury zhodnotit knowledge base ve firme. Ci jeho absenci a nutne preskoleni dvou levelu supportu pod nami. L3 lze nastesti vyskolit 10-15m meetingem. Necekejte ze se L2 neco sami nauci. Necekejte ze budou delat deep troubleshooting na urovni konzultace ovladacu s HW vyrobcem.
