Názory k článku
Linux sysinfo: získávání systémových informací ve formátu JSON

jaký je pro tohle use case? Krátkým pohledem vidím, že parsuješ textový výstup příkazů, což je někdy velice ošemetné, viz třeba tvůj hosts, kde jak vidím nepočítáš s mezerou jako oddělovačem. Krom toho nevidím, že bys nějak pracoval s locales, pro přenosný script se hodí, když si tohle pohlídá.

Na tyhle věci používáme osquery, výstup má daleko spolehlivější. Případně velice slušnou práci dělá ansible -m setup

jaký je pro tohle use case?
- Sběr dat a následná analýza jinými nástroji (např. pro monitoring).

Krátkým pohledem vidím, že parsuješ textový výstup příkazů, což je někdy velice ošemetné, viz třeba tvůj hosts, kde jak vidím nepočítáš s mezerou jako oddělovačem.
- Ano, parsuji textové výstupy příkazů a děkuji za upozornění na jakoukoliv chybu ve způsobu zpracování dat.

Krom toho nevidím, že bys nějak pracoval s locales, pro přenosný script se hodí, když si tohle pohlídá.
- Ne, s locales momentálně nepracuji.

Na tyhle věci používáme osquery, výstup má daleko spolehlivější. Případně velice slušnou práci dělá ansible -m setup
- Nesnažím se konkurovat zaběhlým projektům se spoustou vývojářů. Toto je můj hobby projekt, který je teprve v začátku a nabízím jej jako možnost jak získat užitečné údaje ze systému a nemuset při tom psát vlastní parsery.

Petr.

A proc nesbirat tyto informace rovnou z /proc a /sys, ale cekat na existenci mezi-vrstvy?

Taky si říkám...

Přesně, tohle je peklo a za trest když to někdo takto dělá. Už jsem v životě narazil na několik případů kde toto vedlo ke ztrátě dat a podobným problémům.

Člověk si řekne vždyť ono to jen zpracovává výstup nějaké aplikace a ten dá na výstup. No to platí jen do té doby než se všude po netu začnou objevovat super návody, které daný nástroj využívají jako mezi krok pro další příkazy. A to že to v 90% funguje je sice pěkné, ale v těch 10% to může způsobit obrovské škody.

Za mne by se nikdy neměl zpracovávat výstup nástrojů, které negenerují nějaký standardní formát (TSV,CSV,JSON­,XML,SDL,YAML­...)

A toto je podla teba co?
kill `ps -ef | fgrep nieco | cut -c 12-30`
Na unixe dlhe roky spracovavame textove vystupy nestandardnych formatov a nemame z toho hlavu v smutku.

Tak samozřejmě mohou být případy kdy to funguje. Já ani netvrdím opak. A ten tvůj příklad vůbec není to o čem se bavím.

A ten tvůj příklad vůbec není to o čem se bavím.

Tak mas neco realneho?

Právě, že máme. Na Unixu dlouhé roky existují neřešitelné bezpečnostní problémy, náhodně se vyskytující bugy a odporné rovnáky na ohejbáky, protože v r. 1969 někdo dostal zvrácený nápad zpracovávat jakákoli data jako netypovaný a nestrukturovaný proud oktetů, a od té doby si fanboyové myslí, že je to tak dobře. Není, nebylo a nikdy nebude.

Škoda, že se více neuchytily třeba ty LISP machines. Aktuálně by asi bylo lepší posílat např. EDN, což je superset JSONu a má i další výhody jako jednodušší streamovatelnost. Možná jsou lepší varianty, ale tohle mi nepřijde špatné a je možné v tom reprezentovat dost dobře i čísla různých přesností nebo třeba množiny.
Problém bych viděl v tom, že by muselo existovat něco jako Clojure a bez garbage collection a tedy méně dynamického, aby se to dalo zkompilovat do strojového kódu předem. To by přesto asi umožňovalo nějaký interpret na způsob Babashky. Nemyslím ale, že by to byl neřešitelný problém. Jistě by nebyl problém vytvořit i nástroje, které by pracovaly s EDN v jazycích jako Rust, kde by se "prostě" přidala jen knihovna, která by většinu operací ulehčovala.
Možná by to šlo i nějak nalepit na současný systém na způsob Closh, ale myslím spíš, že je to dlouhodobě víc práce a slepá cesta.

Nevím, jestli víte jak funguje Ansible, ale dělá úplně to samé co moje aplikace (aspoň tedy co se týká získávání dat) . Na vzdáleném hostu spustí systémový příkaz s parametry, získá výstup a ten potom parsuje. Moje aplikace to dělá lokálně.

Viz Ansible - systemd.py
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/systemd.py#L331

def parse_systemctl_show(li­nes):
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/systemd.py#L290

Ansible je tu již nějaký ten rok a za tu dobu má vyladěny parsery a obrovské množství přispěvatelů.

Položím vám otázku - pokud by moje aplikace používala stejné příkazy a parsery jako Ansible, tak by pro vás byla důvěryhodná?

Petr

Důvěryhodnost si získáte tím, že bude dlouhou dobu fungovat a dávat správné výstupy na různých hardwarech, s různými jádry, na různých locales, ... Toho nedosáhnete, když se nebude používat - a nebude se používat, dokud toho nedosáhnete. Obvykle start života takového nástroje začíná tím, že jej potřebuje nějaký "vyšší" systém. Viz např. ansible.

Komentáře kolegů chápu, taky mi nepřijde jako příliš progresivní brát výstupy (a tím pádem být závislý) na dalších programech, nota bene, když ty informace máte při ruce v /sys a /proc. Použít výstup z jiného programu IMO dává smysl jen v tom případě, pokud je potřeba data interpretovat - doplnit např. o hodnoty z číselníků, které jádro neposkytne přímo.

Jenže, co člověk, to názor. Nejlepší je vrátit se k tomu, na co se Vás už někdo ptal. Jaký je use case. To usnadní zodpovědět tyto otázky.

Že má nějaký produkt "vychytaný" parser ještě neznamená, že způsob, jakým data získává, není z principu špatně zvolený. Tudíž že nemá jenom poměrně spolehlivý rovnák na ohýbák. Není podstatné, jestli mu důvěřuje ten nebo onen; až v tom Ansible nebo někde jinde narazí na okrajový příklad, který nevychytali nebo ten parser někdo "zoptimalizuje" tak, že část případů nebude fungovat, bude to houby platné.

Nový projekt má smysl, pokud máte dostatečně speciální případ použití nebo nějakou novou funkcionalitu. Může být, že třeba považujete Vaši verzi za technologicky lepší, pak je ale vhodné se vyhnout opakování starých chyb a slepých uliček.

Problémem není jen parsování nestrukturovaného výstupu nebo Python 2. Ansible je důvěryhodné i proto, že má za sebou obrovské množství lidí. Když už se objeví nějaký bug, tak ho v Ansible celkem rychle opraví. A je poměrně dobrá pravděpodobnost, že to bude platit i za rok nebo dva.

NIH (not invented here) syndromu je potřeba se vyhýbat. Prospěšnější je přispět do už zavedených projektů. Soukromé pokusy jsou v pořádku, pokud se něco potřebujete naučit. Nicméně pro jejich úspěšné rozšíření je potřeba mnohem více úsilí.

Mimochodem zrovna u toho systemd je tam skoro více dokumentace než kódu. Právě proto, že si autoři jsou vědomi toho, jak to může být křehké.

A ansible jde pustit lokálně: ansible -m setup localhost

ano, ansible také volá také cli příkazy, nepovažuji to za nejlepší způsob, ale je poměrně dobře ověřen praxí a za mě dává spolehlivé výsledky, dá se použít rychle. Za dobu co ho používám jsem hlásil jen minimum problémů.

Osquery od facebooku nebo třeba monitorovací nástroj netdata používá /dev, /proc aj. zařízení pro získávání věšiny informací, to považuji za správnou a udržovatelnou cestu. API v tomhle případě se totiž mění pozvolna, naopak formát textových výstup je mění každou chvíli a závisí na spoustě jiných skutečností.

Každý kdo pracuje s linuxem si parsuje cli a repl výstupy, ale je rozdíl si to udělat pro sebe na konkrétní použití, rovnou si ověřovat výstup a předhodit to jako projekt veřejnosti, kde bych už nějakou přenositelnost a ověřenost čekal.

Ja už tu zaznělo, celkem dobře se dá využít ansible modul setup. Také doporučuji ke shlédnutí golang knihovnu https://github.com/jaypipes/ghw

Nápad je to zvláštní (pokud necílí na platformy, kde trojka z nějakého důvodu není). Na druhou stranu o osudu Pythonu 2 je už rozhodnuto, takže si autor akorát plete na sebe bič - bude muset do odvolání řešit kompatibilitu se starým Pythonem a omezovat se v používání šikovných konstrukcí z nových verzí.

Hmm, nedavno jsem psal do prace neco prodobnyho. Portfolio serveru RHEL4,5,6,7 a mozna i HP-UX. Nakonec jsem to napsal v Perl-u. Dokud nebude RHEL8 alespon na 2/3 korporatnich serveru, tak bude Python2 potreba.

Autor nepozna PCP? Mozno lepsie vyuzitie casu by bola implementacia noveho PMDA, napr. aj prave v jazyku python.

To je zas diskuse. Dokonce nás tu Šilhavý označuje za "kolegy", což je mi osobně až nepříjemné.

Za sebe musím říct, že projekt je v pohodě. Je docela dobře napsaný, i když rozhraní není oddělené od získávání dat, ale pro spoustu lidí může být užitečný. Kdybych ho implementoval já, tak jdu cestou psutils a zapojím do toho trochu víc abstrakce. Radit přímý přístup do /proc a /sys je podle mě stejně špatné jako parsovat výstup, jen z druhé strany.

Kolegu beru od slova kolektiv, takze za me to je ok. Pozastavoval bych se teprv nad soudruhem, ale kdyz tady stejne vsichni zamrzli v unixovych sedumdesatkach u terminalu.. tak me to vlastne neva :-)

Já bych autorovi doporučil tyto věci neřešit na rootu. Tady jsou lidi, co se jim líbit nebude nikdy nic a ostatní budou akorát odrazovat, úplně od čehokoliv. Kdybych tyto mudrce poslouchal já, tak neudělám nikdy nic. Kolik z těch kritiků tady má nějaký open-source projekt, na kterém pracují, a který by se nebáli tu zveřejnit?

Co jsem četl, tak tady byly docela věcné připomínky a autor na ně mohl reagovat - např. vysvětlit, proč se jemu jeví takový postup jako dobrý. Nebo taky nemusel reagovat, ale mohl si to uvážit sám. Je ale dobře, když různé názory zazní. Nebo si myslíte, že někdo bude ztrácet čas tím, že bude psát pod článek nějaké chvalozpěvy? Ty možná zvedají náladu a sebevědomí, ale kritika posouvá vpřed.

Osobní preference != věcná kritika. Chvalozpěvy netřeba, ale trochu pozitivity by některým prospělo.

Osobně preferuju programy, které fungujíá správně a ideálně proto, že používají postupy, které riziko chyb minimalizují či eliminují. Myslím, že to je jediný směr, který tuhle branži posouvá na žádoucí level.

Pozitvní je, že autor něco napsal, dal o tom vědět a třeba mu zpětná vazba v něčem pomůže. Že něco napsal a dal si s tím práci, to mu nikdo nebere. Pokud ho dosud nikdo nepoplácal po zádech, klidně to udělám; ano je to super. Akorát je možno, jak doufám, to dělat ještě lépe a bude to výhra pro všechny.

Kritika tady je často přímo esence motivace :-D

Je ale dobře, když různé názory zazní.
Proč je to dobře? Adorace názorů je v poslední době všudypřítomná. Kde kdo má pocit, že když se mu udělal názor, je kvůli tomu nedotknutelný. Ale je to opravdu tak, že každý další názor je přínosem? K čemu je dobrý názor, který vychází z neznalosti faktů, z předsudků nebo který plyne z neochoty nebo neschopnosti nad věcí pořádně přemýšlet?

Ty možná zvedají náladu a sebevědomí, ale kritika posouvá vpřed.
Pochvala také pro autora znamená ujištění, že se vydal správnou cestou a má pokračovat. Naopak zdaleka ne každá kritika posouvá vpřed.

Ale je to opravdu tak, že každý další názor je přínosem?

Je. I objektivně nesprávný názor dává informaci - např. o tom, jak ostatní smýšlejí.

Pochvala také pro autora znamená ujištění, že se vydal správnou cestou a má pokračovat. Naopak zdaleka ne každá kritika posouvá vpřed.

Obvykle to funguje tak, že za sebou musíte mít opravdu obrovské dílo nebo skvělou myšlenku, aby Vás někdo pochválil. Do té doby se pohybujete mezi mlčením a kritikou. Kritické názory možná taky nejsou správné (kdyby to kritik uměl lépe, udělal by to sám), ale vyjadřuje to, že ani kritizované dílo (ještě) není dobré.

Kritiku musíte umět přijímat. To neznamená, že se jí odevzdáte a necháte vydeptat, ale že z ní umíte vydolovat tu zdravou podstatu.

Je. I objektivně nesprávný názor dává informaci - např. o tom, jak ostatní smýšlejí.
Takže takový názor dává informaci, že někdo má takový názor. Není to poněkud samoúčelné?

vyjadřuje to, že ani kritizované dílo (ještě) není dobré.
Ne, někdy kritika nic takového nevyjadřuje.

že z ní umíte vydolovat tu zdravou podstatu
Díváte se na kritiku příliš nekriticky. Někdy prostě v kritice žádná zdravá podstata není.

Zdravim.

Za me osobne je Vase prace s urcitymi vyhradami dobry pocin. Ovsem za predpokladu, ze vystup z programu ma jasne definou strukturu, hodnoty a moznost integrace do aplikace bez ohledu na pouzity jazyk.

Ja osobne uz dlouho krituzuji "piseckarstvi" a "cochcarnu" v Linuxovych projektech. Je to asi jeden z nejignorovanejsich a zaroven - podle meho - nejpalcivejsich problemu linuxoveho sytemu obecne. Sam se snazim uz nejakou dobu na tom pracovat a navrhnout nejake reseni, ale je to dost obtizna cesta. Vas projekt je malou vlastovkou, ktera miri presne timto smerem - umoznuje delat praci na jednom miste, jednim zpusobem a unifikuje rozhrani. Jsou bohuzel lide, kterym takovy bordel vyhovuje, u nich moc pochopeni necekejte. Za me vsak, dobra prace - jen tak dal.

Asi nejvetsi vyhradu bych mel k "natvrdo" zvolenemu jednomu vystupnimu formatu. Osobne bych spis ocenil moznost volby vystupniho formatu (JSON, XML, prosty text, ...). Uz proto, ze pri integraci s aplikaci bych musel dodavat mechanizmi pro praci s JSON. Nerikam, ze je to buh vi jak zavratne slozite, ale v pripade, kdy uz aplikace umi s pracovat jinym formatem, znamena to zbytecne mnozeni kodu a praci navic.

S tímto plně souhlasím, ten čurbes v rozhraní je pekelný. JSON není příliš vhodný formát, pokud hledáme jasně definovanou strukturu, hodnoty a možnost integrace. Osobně bych třeba preferoval XML jakožto primární formát (s definicí) a JSON a text jako podružné výstupy.

Skvělé by jednou bylo, kdyby k tomu nebyly potřeba specifické předpoklady v prostředí, na mysli mám ten python. Třeba to k tomu jednou dospěje.

[Miroslav Šilhavý]
Souhlasim.

K tem formatum, to je jeden z duvodu proc bych volil moznost volby formatu, ale ne na urovni klientskeho projektu, nybrz jeste pred nim. Bud rovnou data generovat v volitelnem formatu, nebo jednoduchou a rychlou konverzni mezivrstvou. XML je na tohle skvely nastroj, ale ma take spoustu odpurcu, a ja bych nerad zabredl do podobnych hadek a diskuzi, jake mame moznost cist vyse - v nich totiz casto v zaplave banalnich argumentu a proti-argumentu (vzhledem k moznostem dnesnich jazyku mi prijdou takove diskuze ... s prominutim hloupe) zanikne puvodni myslenka a nikam se nedohrabem.

Co se tyce integrace, podle meho nazoru by uplne nejlepsi bylo takove utility vytvaret dvoufazove, nejdrive core knihovnu, ktera bude definovat a implementovat samostatnou funkcionalitu s API na urovni C (takove API je pak mozno pouzit v podstate vsude) a az potom samostanou aplikaci. Jednak muze slouzit jako samostatny nastroj, tam kde C API by se tezko dostavalo, nebo by to bylo moc tezkopadne (treba shell) a jednak taky jako univerzalni a funkcni example jak vlastne knihovnu vyuzit.

3. 1. 2021, 12:32 editováno autorem komentáře

Name : lshw
Arch : x86_64
Version : B.02.18
Release : 12.el7
Size : 933 k
Repo : installed
From repo : anaconda
Summary : HardWare LiSter
URL : http://ezix.org/project/wiki/HardwareLiSter
License : GPLv2
Description : lshw (Hardware Lister) is a small tool to provide detailed informaton on
: the hardware configuration of the machine. It can report exact memory
: configuration, firmware version, mainboard configuration, CPU version
: and speed, cache configuration, bus speed, etc. on DMI-capable x86s
: systems and on some PowerPC machines (PowerMac G4 is known to work).
:
: Information can be output in plain text, XML or HTML.
:
: For detailed information on lshw features and usage, please see the
: included documentation or go to the lshw Web page,
: http://lshw.ezix.org/