Vlákno názorů k článku Nebojte se systemd: další komponenty od libcha - Existuje nějaký přímočarý způsob, jak logovat svou uživatelskou...

Třeba Journal API? To API na ničem dalším nezávisí, můžete ho použít klidně i ve Windows.

Nezávisí? Jen na journald, který ve Windows není, že? :D

Koukni na to API, to vazne k implementaci SystemD nepotrebuje. Z vetsi casti je to cviceni pro druhaky.

Jaká jiná aplikace umí přijímat má data přes to API v *nix like systémech? (Windows mě nezajímají, já s nimi nezačal)

Aplikace? Mohli by všichni odpůrci systemd diskutující v tomto vlákně hned teď odejít dostudovat si význam zkratky API a teprve po té se vrátit a pokračovat v diskusi, pokud to ještě bude účelné?

Tak můžete prosím vysvětlit, když pošlu přes Journal API data, co je teda přijme, když to nebude aplikace?

Dotaz byl, jaké použít API. Vy se teď ptáte na to, jakou použít implementaci logovacího démona, který podporuje Journal API. No já bych doporučil journald, je to v současnosti jediná implementace, o které vím. A myslím, že by neměl být problém portovat ji na jiné POSIX platformy, protože si nemyslím, že by měla nějaké komplikované závislosti.

To, co vy nazýváte „API journald“, systemd nazývá „Journal API“, což tomu rozlišení od journald může trochu pomoci.

Vysvětlovat to mi (programátorovi), je zbytečná práce. Já tyhle věci vím. Akorát mi pořád není jasné, jak to použiju jinde, jak tady někteří tvrdí, že to jde, protože podle mě, když je implementace Journal API jediná a sice pouze v systemd, který je pouze pod Linuxem, tak to prostě jinde (jiné *nix like OS, Windows ap.) nefunguje. Bohužel jsou tu jedinci, kteří tvrdí, že to používat jde, ale odpovědi jak se to udělá, když to jinde neexistuje jsme se stále nedobrali.

Ano přesně tady jsem vás chtěl dostat, děkuji, že jste se nakonec odhalil.

Abych tedy shrnul vaši radu: Abych mohl naprogramovat aplikaci, ve které chci "moderně" logovat, musím si k tomu napsat i pro každý systém mimo Linuxu i logovacího démona, který bude implementovat Poetteringovo API. :-D

Přiznejte se, že jste byl toto léto moc dlouho na sluníčku.

PS: A když je to tak mega super cool věc, jak to že ještě nejsou hromady implementací toho API na všech možných i nemožných OS, aby se s tím každý programátor nemusel mrcasit sám?

Jj jasně, tonoucí se stébla chytá. Na některých OS bude stačit knihovna na jiném bude nutný i daemon. Slovíčkaříte a uchází vám podstatná pointa. Takhle to mají puberťáci, že bazírují na kravinách a podstata jim uniká.

PS: A k čemu bych posílal strukturovaná logovací data přes nějakou zvláštní novou knihovnu do syslogu, který strukturu nemá místo toho, abych to posílal syslogu přímo na všech *nix like platformách, to už mi asi taky nevysvětlíte, ale hlavně že je nutné dělat vlastní implementaci API, které na dané platformě neexistuje. :D

Tak se podívejte pořádně. Já žádné strukturované logování nechtěl, mě bylo nuceno a když jsem se zeptal, proč je to tak super skvělé, tak jsem se dověděl, že proto, že si musím na všech ostatních platformách kromě Linuxu se systemd naimplementovat vlastní a když to udělám, tak na hromadě platforem to stejně jen převedu ze struktury do textu. Rada jak noha :D

Tak si to sám vyzkoušejte. Napište si jednoduchou Hello World aplikaci a přidejte si do ní logování přes Journal API. Přidáte #include <systemd/sd-journal.h>, zavoláte sd_journal_print. Aplikaci přeložíte.

Co jste právě udělal? Naprogramoval jste aplikaci, která loguje přes Journal API. Musel jste naprogramovat logovacího démona pro každý systém mimo Linux? Nemusel. Takže buď umíte zázraky, nebo jste právě předvedl protipříklad ke svému tvrzení.

A praktický důvod, proč bych tu aplikaci o to logování do Journal API přidával, když chci multiplaformní a nikde jinde než v systemd to nejde se prostě nedozvím a nedozvím. Ale spoustu keců, jak jsem blbej, že si mám naimplementovat API na plaformách kde není to jo. :D

Normálně uvažující lidi mají nejprve nějaký problém (např. potřebuji logovat strukturované zprávy) a k němu hledají řešení (použiju Journal API). Vy jste se nejprve rozhodl, že použijete Journal API, a teď zoufale hledáte nějaký důvod, proč jste se tomu vlastně rozhodl.

Mám pro vás takový radikální návrh. Když nevíte, proč byste něco používal, tak to nepoužívejte.

Co mi to vkládáte do úst? Já vůbec Journal API nechtěl používat. Já naopak na začátku říkal, že journald a jeho API je vlastně k ničemu. Ale byl jsem přesvědčován, jak je to super věc a když jsem se zeptal proč, tak jsem se dověděl, že proto, že si ho můžu všude možně na různých platformách naimplementovat :D

Pokud ho nechcete, nemusíte ho používat. Pokud Vám stačí řádkové logy, tak si dál logujte přes syslog nebo na standardní výstup jak jste zvyklý a na Journal API zapomeňte.

Me by zajimalo, jak dlouho to jeste bude mozne a kdy aplikace prestanou rozumet Syslog API a bez systemd nebudou umet logovat.

Aha, takže do vlákna o použití Journal API jste přišel jenom trollovat. Aspoň že to přiznáte.

To nebyla neochota něco pochopit, ale uvědomění si, že s tím bude kdekoli jinde potíž a proč to tedy vůbec používat. Doteď nemám kloudnou odpověď a pochybuju, že kromě té "naimplementovat si to sám", že ji vůbec dostanu.

PS: A když je to tak mega super cool věc, jak to že ještě nejsou hromady implementací toho API na všech možných i nemožných OS, aby se s tím každý programátor nemusel mrcasit sám?

Za tim stoji zpatecnictvi a zavist lidi, kteri nedokazi ocenit neci genialitu.

Nic proti, ale po tom co jsi tady napsal je potřeba úspěšně pochybovat o tom, že jsi programátor. Každy slušný projekt přesahující jakousi minimální hranici (definujme ji například cca 1000+ SLOC) loguje buď na standardní výstup/error výstup pokud nemá extra potřeby (třeba i kvůli Dockeru) nebo používá nějakou slušnou logovací multiplatformní knihovnu (pro každý jazyk jich bývá přehršel). A v těchto knihovnách si jednoduše nakonfigurujete, kam všude to má jít. Není jen standardní výstup/soubor/sys­log/rsyslog, loguje se do logstashe/gra­ylogu/fluentd, existují mraky cloudových logovacích služeb (ani nebudu vyjmenovávat). Takža kam se loguje je otázka změny konfigurace. Normální programátor neřeší API logovacích knihoven.

Na mne tyhle diskuse dělají dojem, že si tady honí trika správci ojedinělých serverů, občas o sobě prohlašující, že jsou programátoři. Opravdový programátor nebo správce opravdu rozlehlé sítě by nikdy něco takovéhohle nemohl napsat.

Proc bych mel v aplikaci resit jestli to pujde do logstashe atd. kdyz to muzu lokalne poslat do syslogu a z nej pak dal? Jde mi o to neresit zmeny (treba IP/DNS logovaciho serveru) na X ruznych mistech, ale pouze na jednom - v konfiguraci syslogu.

Ano to je taky přesně ta věc, co mi vadí. Proč bych měl měnit hromady aplikací, když taková věc má být konfigurací té komponenty, která ji má v systému na starost (v *nix like systémech syslog)? Poettering vyrobí novou (nespolehlivou) službu a nutí takhle ostatní, aby ji používali a to tímhle způsobem. Takhle se to podle mě nedělá.

Příklad nucení ostatních do změn je v poslední době v rozbití funkčnosti screen, tmux ap. a pak vysvětlování jeho nohsledů v diskuzi tuším právě u tmuxu, že to mají opravit oni. Mám obavu, že tohle není poslední věc, kterou budou autoři systemd tímto způsobem tlačit a problémy ohledně nové logovací služby to podle mě dokazují.

Normální programátor neřeší API logovacích knihoven.

Ano a to je v podstatě ten problém, na který jsem upozorňoval. Běžný (osobně se mi vaše dělení na normální a nenormální nezdá) programátor to nemá co řešit. A proto se mi to nabízené řešení v podobě toho, že si to má sám naimplementovat nelíbí.

PS: Vaše pochyby směrem ke mě rozebírat nebudu.

Řešení, že si to máte sám implementovat, je váš vlastní nápad, který tu pořád prosazujete. Všichni ostatní vám radí, ať použijete nějakou univerzální knihovnu pro logování a nesnažíte se řešit detaily, kterým nerozumíte.

API je definováno mezi logující aplikací a libsystemd (je to Journal API), nikoli mezi libsystemd a journald (tam je to implementační záležitost). Když chcete nahradit journald, napíšete vlastní implementaci Journal API, a aplikace nepoběží s implementací Journal API z libsystemd ale s implementací z vaší knihovny. A ta vaše knihovna třeba vůbec nemusí komunikovat s dalším běžící procesem, ale může rovnou zapisovat na disk.

Jak jste přišel na to, že Journal API závisí na journald? Viděl jste to API vůbec?

Tak to API na journald zavisi tim, ze je to jeho jedina implementace. A vzhledem k tomu, ze Poetterig to API jeste treba 20x zmeni, tak se do alternativni implementace asi nikdo nepozene.

Tak to API na journald zavisi tim, ze je to jeho jedina implementace.
To ovšem nechápete význam zkratky API. To, kolik je implementací, není věcí autorů API.

A vzhledem k tomu, ze Poetterig to API jeste treba 20x zmeni, tak se do alternativni implementace asi nikdo nepozene.
To jsou akorát vaše ničím nepodložené kecy.

LOL!

Otázka: Jak použiju Journal API jinde než v Linuxu a systemdd?

Odpověď Jirsáka: Úplně normálně, API je API a můžete to použít třeba i na WIndows

Otázka: Ale když to jinde než v Linuxu a SystemD neexistuje, jak to teda použiju?

Odpověď Jirsáka: To ovšem nechápete význam zkratky API. To, kolik je implementací, není věcí autorů API.

To už je na Chocholouška toto :D. A prej neexistující problém jak je výše psáno. Jasně, hned jdu do Windows programovat pomocí Journal API, které Windows nepodporují :D :D :D

Já do toho Windows tahat nezačal, já ne. To si vyřiďte s těmi, co tím začali argumentovat, tak mě zajímalo, jakže se to teda dělá. Takže to na mě neházejte. Já mluvil o *nix like OS a argumentátoři začali s Windows. Zajímavé, že jim neřeknete, že se chytali stébla.

To, že nechápete pojem API, není zas taková tragédie, rozhodně to není na Chocholouška. Na Chocholouška je to, že místo abyste si to zjistil, píšete pořád různé nesmysly založené na nesmyslných představách o tom, co je API.

Zkusím to ještě jednou. API je rozhraní mezi dvěma softwarovými komponentami. Použití API znamená, že dokážete zavolat funkce poskytované tím API. API může mít nějaké podmínky použití a závislosti – např. pokud bude funkce vyvolána zasláním zprávy dbus, je takové API závislé na dbus. Pokud se funkce vyvolává zasláním zprávy vytvořené přes funkci CreateEvent Win32 API, bude to API závislé na Win32 API. Journal API je tvořené pouze voláním C funkcí, takže nemá žádné závislosti a je multiplatformní.

Jako programátor Journal API použijete tak, že do svého zdrojáku includujete příslušný hlavičkový soubor a zavoláte funkce v něm deklarované. V závislostech své aplikace pak uvedete, že k běhu potřebuje (volitelně nebo povinně, záleží jak jste to implementoval) implementaci Journal API. Tím to pro vás končí, neřešíte, kde je jaká implementace, stejně jako neřešíte, kde vaše aplikace sebere implementaci funkce fopen nebo SSL_accept.

Když pak někdo chce vaši aplikaci použít, musí nejprve splnit všechny její závislosti. Když bude potřebovat implementaci SSL_accept, použije třeba LibreSSL – a to přesto, že v době, kdy jste psal ten program, LibreSSL ještě vůbec nemusela existovat a jediná implementace SSL_accept byla v OpenSSL. Úplně stejně je to s Journal API. Vy dneska napíšete aplikaci používající Journal API, a vůbec vás při programování nemusí zajímat, jaké existují implementace. Ten váš program může zítra někdo vzít a spustit s implementací, o které jste ani nevěděl. Dokonce ten program můžete napsat i tehdy, když neexistuje vůbec žádná implementace toho API. A v tom je právě celá výhoda API a jeho smysl – vy jako programátor se nestaráte o konkrétní implementace, je vám jedno, jestli není žádná, je jedna nebo jich je padesát, je vám jedno jestli zítra přibyde dalších dvacet implementací, protože pro vás se tím nic nemění, vy píšete pořád proti tomu jednomu API.

Z toho je mimo jiné patrné, že vaše věta „Windows nepodporují Journal API“ je nesmyslná. Žádná podpora Windows není potřeba. Když někdo napíše implementaci Journal API pro Windows, můžete pod Windows Journal API klidně používat – na Windows samotných se přitom nic nezmění, v Redmondu nebudou muset hnout ani prstem, aby Windows nějak začaly podporovat Journal API. To, zda můžete nějaké API v daný okamžik někde použít, je totiž závislé pouze na jeho závislostech a na dostupných implementacích. Pro použití API nepotřebujete žádnou podporu operačního systému.

Tolik k původní otázce autora programu, jaké multiplatformní API může použít. Vedle ní je také možné položit otázku uživatele: mám aplikaci vyžadující implementaci Journal API. Jakou implementaci Journal API mám použít? Což je ovšem jiná otázka, než ta, která byla na začátku tohohle vlákna.

Cituji

--- cut ---
- Žádná podpora Windows není potřeba

- Když někdo napíše implementaci Journal API pro Windows, můžete pod Windows Journal API klidně používat
--- cut ---

Já se bavím o tom co je ne o tom, co by kdyby.

Koukám, že Lael má mohutnou konkurenci. Zbytek vašeho příspěvku je OT vata.