DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
21.7.2017 22:39
| Přečteno: 3039×
| Softwarové inženýrství
| 
Převážně diskusní/dotazovací zápisek na téma návrhu datových formátů.
Při návrhu datového formátu můžeme optimalizovat podle různých kritérií a priorit – a ty jdou často proti sobě. Možná proto existuje tolik formátů…
Předesílám, že teď mluvím primárně o formátech pro strojovou komunikaci tzn. formáty, pomocí kterých budou programy ukládat strukturovaná data do souboru nebo kterými budou programy komunikovat po síti (formát zpráv nějakého protokolu). Nechci zde tedy zabředávat do problematiky formátů pro lidi (tzn. dokumenty, konfigurace, zdrojové kódy…) a hádat se, zda je lepší XML, YAML, INI, JSON atd. tato diskuse probíhá minimálně na dvou místech vedle.
Jaká jsou tedy hlediska, na která se můžeme zaměřit? Napadá mne:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
diff nějakým univerzálním nástrojem (třeba příkaz diff nebo verzovací systém). Např. jsem se setkal s formátem, který byl sice textový, ale na začátku každého řádku bylo číslo řádku (a na konci byl ještě součet), takže při přidání či smazání řádku ukazoval diff změny v celém souboru. Napsat si perlový skript, který to přečísluje, je sice triviální, ale je tohle vůbec nutné?Jaká další kritéria vás napadají?
Už z těch uvedených výše je zřejmé, že ideální formát neexistuje – nezle se zavděčit všem a některá kritéria jdou přímo proti sobě (např. implementační náročnost vs. funkcionalita nebo datová vs. výpočetní náročnost). Jak velké rozpětí tedy lze ještě pokrýt jedním formátem a kdy už je lepší na to rezignovat a mít radši formáty dva… tři, deset, padesát…? Výhody jednoho formátu jsou snad zřejmé: sdílení kódu a znalostí, vyspělejší nástroje (stačí je napsat jednou), lépe otestovaný software (používá ho víc lidí)…
Zajímá mě primárně dnešní pohled a budoucnost – tzn. z hlediska dnešního hardwaru, dnešní situace na trhu, dnešních jazyků, platforem… Řada současných formátů je zatížena minulostí a optimalizují pro něco, co už dneska třeba není aktuální. Nebo obsahují návrhové chyby (což je podle mého mj. aplikační/doménová specifičnost).
-- DDP
Tiskni
Sdílej:
Takova diskuse se tu uz nedavno vedla
No vidíš, na tu už jsem pomalu zapomněl :-) Ale to byl spíš odstrašující příklad, jak to nedělat.
a ja tam napsal vsechno, co bych k tomu mohl rict.
Ten CBOR a MsgPack?
Na stránkách CBORu mě děsí odstavec:
One of the major practical wins of JSON is that successful data interchange is possible without casting a schema in concrete. This works much better in a world where both ends of a communication relationship may be evolving at high speed.
To mi přijde jako zásadní nepochopení toho, jak funguje nebo by měla fungovat volná vazba.
Ale to byl spíš odstrašující příklad, jak to nedělat.Odstrasujici priklad je XML a JSON.
To mi přijde jako zásadní nepochopení toho, jak funguje nebo by měla fungovat volná vazba.Nechapu, co se tim snazis rict. Co ti konkretne na CBORu vadi?
Odstrasujici priklad je XML a JSON.
Takže bys místo nich radši používal nový formát uSX 1.0? A že jsi to tehdy Dumblobovi nenapsal, měl by radost.
Nechapu, co se tim snazis rict. Co ti konkretne na CBORu vadi?
Na CBORu jako takovém asi nic – vypadá to na celkem jednoduchý formát, který cílí na implementační nenáročnost a datovou úspornost – což má jistě svoje využití a není nic špatného na tom zvolit si tyto priority (a obětovat jiné).
Co mě zarazilo, byl ale ten odstavec:
No Schema needed: One of the major practical wins of JSON is that successful data interchange is possible without casting a schema in concrete. This works much better in a world where both ends of a communication relationship may be evolving at high speed.
Pokud si někdo myslí, že odstraněním schématu si nějak pomůže, tak se strašlivě mýlí.1 A to zvlášť v prostředí „where both ends of a communication relationship may be evolving at high speed“. To pak není volná vazba, ale jen náhodná shoda, když na sebe ty dvě strany pasují. A funkčního celku lze dosáhnout jen s vysokými náklady na (ruční) testování a úpravy/kontroly kódu. Navíc pokud tam má komunikovat M:N stran a ty je ani předem neznáš2, tak to ani pořádně otestovat nemůžeš.
Je to hloupý přístup, který stojí spoustu lidské práce – práce, kterou za nás mohly dělat stroje (generátory datového modelu, parserů, generátorů, validátory, konvertory…).
Dobrý meta-formát by podle mého měl podporovat schéma, verzování a rozšiřitelnost – a pak není problém, aby se formát nad ním postavený dynamicky rozvíjel, klidně i „at high speed“ a zároveň implementace budou spolehlivě fungovat – nebude se to chovat náhodně, ale předvídatelným a způsobem (ať už jde o pád/ohlášení chyby či třeba řízené ignorování neznámého atributu/struktury3 – typicky u nové verze schématu). Jmenné prostory pak řeší mj.4 to, aby se spolu omylem nespojily dvě strany, které implementují každá něco jiného, ale náhodou se tam nějaké atributy jmenují stejně.
Znovu říkám, to nutně neznamená, že ten CBOR musí být špatný formát a neměl by se používat – jen bych si ho před použitím důkladně prostudoval, protože tenhle odstavec nepůsobí zrovna kompetentně.
[1] dokonce i webaři na to už přišli – viz OpenAPI (Swagger), kde – zdá se – konečně po letech dohánějí XML, XSD, WSDL a píší strojově čitelnou specifikaci rozhraní, místo aby na web jen vyblili nějaké příklady a útržky komunikace (jak ale bývá mnohde zvykem dodnes) a čekali, že podle nich někdo dobře naimplementuje klienta nebo server; BTW: s tím OpenAPI se pracuje docela dobře – že to ale trvalo :-)
[2] kdokoli si může napsat implementaci, aniž by se tě ptal, a připojit se
[3] některé (meta)formáty k atributům umožňují připojit příznak, zda lze daný (pro druhou stranu neznámý) atribut ignorovat nebo ne
[4] dále pak třeba to, že když někde najdeš nějaký kus dat, tak z toho poznáš, co je to za formát a máš šanci se dopátrat jeho autora/specifikace
Viz #41.
Pro dynamický vývoj a ladění API za chodu je schéma ještě důležitější než při implementaci pevně dané (neměnné) specifikace/standardu.
Na tom neco je. Trochu mi to pripomnelo muj soucasny pocit, ze co by se melo ve skutecnosti v programovani testovat spis nez kod (kod by se mel IMHO hlavne assertovat a automaticky odvozovat/dokazovat) jsou (vstupni) data a skryte predpoklady, ktere na ne kladl puvodni autor kodu.Ano, takhle se poznají dobré testy (a dobrá dokumentace, ale to je asi samozřejmé). A také je to jeden z hlavních znaků dobrých vývojářů.
23.7.2017 18:16
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Přijde mi, že schémata jsou často přeceňována. Ohlídají pouze syntaxi zpráv, což je často ta jednodušší část problému, ve které se dělá málo chyb.
Mám odlišnou zkušenost. Např. jsem pozoroval lidi, kteří seděli metr od sebe, jejich aplikace spolu měly komunikovat a oni se v tom patlali, dělalo jim problém si domluvit API. Resp. napoprvé si ho nějak domluvili, ale pak bylo největší neštěstí v tom dělat změny a synchronizovat se na obou stranách. Jak se nějaký atribut jmenuje, jaký má datový typ, na kterém místě ve struktuře se nachází, jestli je povinný…˙to byly každodenní problémy. O nějakém verzování API ani nemluvě.
Takhle to jde dělat leda, když máš pevně daný standard/specifikaci a už se to měnit nebude (nebo až za pár let). V takovém případě si to můžeš opsat z textové specifikace a uzavřít to. Ovšem i tam by ti existence strojově čitelného schématu práci ušetřila.
Ale pokud se rozhraní ladí za chodu a během vývoje se mění/rozšiřuje API, tak je strojově čitelné schéma k nezaplacení.
Oproti tomu sémantika zpráv bývá složitější, formálně popsatelná mnohem hůře, a proto logicky častěji špatně.
Přijde mi, jako kdybychom se bavili o nakupování a „odpůrce schématu“ pořád zdůrazňoval, že pro úspěšný nákup je důležité dobře vybrat zboží na regálu. Ano, to sice důležité je, ale předně musíš vlézt do správného obchodu a najít ten správný regál. Schéma (strojově čitelná specifikace) je něco jako teleport, který tě dopraví do správného obchodu ke správnému regálu – a ty si tam už jen uděláš, co potřebuješ. Dobré schéma kromě toho teleportování vedle tebe ještě postaví počítač nebo knihovnu, ve které najdeš vše potřebné k výběru zboží.
Jistě, mohl bys postupně obcházet všechny obchody a v nich regály jeden po druhém. Nebo by ses mohl zeptat někoho na ulici. Nebo bys mohl mít ručně nakreslenou mapu… Ale proč bys to proboha dělal, když se můžeš teleportovat? Proč bys měl trávit čas něčím, co za tebe dokáže vyřešit stroj, a ještě riskovat, že v tom uděláš chybu? Proč muset vždy hledat popis atributu ručně v textové specifikaci, když to může být třeba komentář ve třídě vygenerované ze schématu?
Absence schématu je k ničemu a rozhodně nepodporuje volnou vazbu. (že se něco v prvním kroku podaří načíst a nespadne to hned, ale až o krok později – to opravdu nelze považovat za volnou vazbu)
Pokud se dva vývojáři nemohou dohodnout, tak by se jednomu z nich měl dát protokol na starost celý a druhý by mu jen říkal, co mu ještě kde chybí, ale bylo by na tom prvním, jak přesně by to implementoval.Raději někomu úplně jinému. Jinak to pravděpodobně dopadne tak, že vznikne "API" kde se obě strany spoléhají na naprosto nezdokumentované chování té druhé strany. Pokud se někdo pokusí vytvořit alternativní implementaci jedné z nich, rychle zjistí že je to prakticky nemožné. Samozřejmě, je možné že v tom uvedeném příkladě (dva vývojáři se nedokáží zasynchronizovat) je vina zcela na straně jednoho z nich a ten druhý vy to zvládl pěkně.
Kdyby to celé vyvíjel jeden člověk, tak si spíš zapamatuje, co kam přidal a že to má udělat odpovídající změnu i na druhé straně (i když i ten jeden člověk může udělat chybu a neuhlídat všechno). Ale pokud má spolupracovat víc lidí, tak je schéma dobrý způsob, jak se předat tu informaci.
A že jsi to tehdy Dumblobovi nenapsal, měl by radost.Napsali mu to jini, tak proc se opakovat?
Znovu říkám, to nutně neznamená, že ten CBOR musí být špatný formát a neměl by se používat – jen bych si ho před použitím důkladně prostudoval, protože tenhle odstavec nepůsobí zrovna kompetentně.Tak si ho prostuduj.
Ja myslim, ze hlavni myslenka je, ze CBOR muzes parsovat i bez znalosti schematu, nebo jenom s castecnou znalosti. Muzes treba ignorovat tagy.
Napsali mu to jini, tak proc se opakovat?
Nevšiml jsem si. Naopak mu většina lidí psala, jakou to vymyslel blbost a jaké má ten formát vady.
Ja myslim, ze hlavni myslenka je, ze CBOR muzes parsovat i bez znalosti schematu, nebo jenom s castecnou znalosti. Muzes treba ignorovat tagy.
Jestli je to hlavní myšlenka, tak mi to přijde trochu málo.
Ono ty formáty bychom mohli rozdělit na tři skupiny, ne dvě:
Podpora schématu tedy sama o sobě neznamená žádnou nevýhodu – i bez jeho znalosti si většinou můžeš dekódovat zprávu.
Takže bys místo nich radši používal nový formát uSX 1.0? A že jsi to tehdy Dumblobovi nenapsal, měl by radost.Nu, to by byla hodně povrchní radost (pořádnou radost bych měl, kdyby mnozí diskutující lépe četli a přemýšleli a hlavně i něco dělali, aby nezůstalo pouze u planých slov). Na tu diskuzi se již přes tři měsíce těším - naneštěstí jsem od chvíle zveřejnění toho blogu prakticky bez internetu (a když na internetu, tak cca 16 Kbit/s, takže většina spojení vytimeoutuje před stažením nějaké smysluplné části dat). Ale žádný strach, mám to v TODO a do konce roku nejpozději se k té diskuzi dostanu.
Dobrý meta-formát by podle mého měl podporovat schéma, verzování a rozšiřitelnost ...No vida, tak to si konečně budeme rozumět. Přesně tohle podporuje do posledního puntíku uSX 1.0 již od prvního veřejného draftu. Chce se mi znovu postesknout, že diskutující nečtou a málo přemýšlí a nic moc nedělají (např. zkusit diskutovaný formát implementovat v rozličných prostředích a tím nejprve alespoň částečně ověřit různé šílené teorie jak je něco nepoužitelné apod. - on svět nebývá tak černobílý
).
pořádnou radost bych měl, kdyby mnozí diskutující lépe četli a přemýšleli a hlavně i něco dělali, aby nezůstalo pouze u planých slovTady jsi na abclinuxu. Šance, že z téhle diskuse pojde nějaký kód nebo praktický výsledek, je asi tak 0.1%...
hlavně i něco dělali, aby nezůstalo pouze u planých slov
O co min ochotni tu lide jsou neco udelat, o to vic budou ty svoje "nazory" branit. A tak budou vymyslet racionalizacni konstrukce hajici jejich nazor a proc jsou vsichni ostatni strasne tupi idioti. Zajimavy fenomen, pro vetsinu je proste jednodussi vylozit mnohem vic mentalni energie na kecani okolo, vymlouvani se, overengineering a obecne vsechny mozne cinnosti, ktere se daji delat do nekonecna bez toho, aby bylo sahnuto na realnou vec.
Pritom staci jit a udelat, coz je prave to, co urcuje smer a krok. Dalsi se budto chytnou, nebo jdou svym smerem, ale wastovat cas s chytrolinama, od kterych pak clovek vidi sotva jeden commit... skoda si ubirat motivaci. V diskuzi mne vetsinou zajimaji nazory dalsich 'stakeholders', tj. lidi, co na te diskuzi maji realny zajem, jsou v projektu nejak zapojeni a aktivni. Komentare nahodnych kolemjdoucich a obecne tluchubu discarduju vetsinou do kanalu.
Kódu už byly napsány miliardy řádků. A spousta z toho je odpad, šum nebo duplicita…
Analýza a návrh jsou nedílnou součástí vývoje softwaru a pokud se podcení, tak z toho nic dobrého nevzejde. Proto nemám úplně rád, když někdo hned sedne a začne kódovat. Opačný extrém: navrhnout něco jen tak od stolu taky není ideální a všechno se předvídat nedá – proto se dělá iterativní vývoj a zadání/návrh se dolaďuje průběžně. Nicméně nějakou hrubou představu a požadavky by měl mít člověk předem. Jinak má smysl si zkoušet leda nějaké dílčí prototypy, ale těžko můžeš začít vyvíjet.
Co se týče Ábíčka a asi i obecně diskusí – čím odbornější téma a čím větší úsilí je potřeba vynaložit, tím menší zpětnou vazbu dostaneš. Když sem hodím odkaz na nějaký zdroják, tak si ho stáhne jen zlomek lidí a jen zlomek z toho zlomku k tomu napíše něco přínosného (většinou nikdo – v poradnách to bývá lepší, ale tam bývá zdroják jen na pár řádků a je hned v příspěvku). Oproti tomu v nějaké lehčí diskusi (kde diskutující nemusí stahovat a studovat zdrojový kód) je šance, že se tam objeví aspoň nějaké nápady nebo požadavky, které má smysl vzít do úvahy.
Kódu už byly napsány miliardy řádků. A spousta z toho je odpad, šum nebo duplicita…Na to mam protiargument prikladem, ktery mne v posledni dobe hodne netesi - kde je Slack, vs. kde je XMPP... Slacku sice vzdoruju, ale pres XMPP s nikym uz taky moc slov nevymenim ("downgradoval" jsem na IRC).
čím odbornější téma a čím větší úsilí je potřeba vynaložit, tím menší zpětnou vazbu dostanešTo sice jo, ale tu jsme na Abicku, cekal bych z prvni ze tu to odborny publikum bude. Otazka je, kolik z nich jeste zustalo v takovem tom "furt cumim do monitoru", vs. kolik z nas uz to nekde dela za penice a potom chce mit pokoj a pri cteni Abicka si o tom maximalne potrolit.
25.7.2017 19:26
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Slacku sice vzdoruju, ale pres XMPP s nikym uz taky moc slov nevymenim ("downgradoval" jsem na IRC).+1, to samé.
Na to mam protiargument prikladem, ktery mne v posledni dobe hodne netesi - kde je Slack, vs. kde je XMPP... Slacku sice vzdoruju, ale pres XMPP s nikym uz taky moc slov nevymenim ("downgradoval" jsem na IRC).
Asi úplně nechápu, jak tohle souvisí. Chtěl jsem tím říct, že kódu je spousta, není vzácný, sám o sobě nemá valnou hodnotu. Osobně vnímám velký objem kódu spíš jako potenciální průšvih než něco, na co bych měl být hrdý, protože vím, kolik stojí jeho údržba.
Co se týče toho IM, tak já jsem to omezil obecně, protože mne to rozptylovalo od práce – nezměnil jsem technologii, primární/jediná volba je pro mne pořád XMPP a SIP, jen tam nejsem pořád, spíš jen na vyžádání.
To sice jo, ale tu jsme na Abicku, cekal bych z prvni ze tu to odborny publikum bude.
Tak je to pořád o několik řádů lepší než jinde na českém webu, to je pravda. Nicméně už jsem sem víckrát dával odkaz na nějaký zdroják a lidi to moc nečtou nebo si aspoň nenajdou čas na to, něco konstruktivního napsat, to je spíš výjimka.
k tem hlediskum si pridejte paraelizaci pri cteni a zapisu.
Dobrý tip. Trochu to souvisí s tou indexovaností – jednotlivá vlákna můžou skočit doprostřed zprávy a číst odtamtud a dohromady skládat celek.
Dale verzovani. Jak jej resit ?
Ve smyslu verzí schématu/slovníku? Nad tímhle jsem uvažoval, je to důležitá vlastnost… a taky jedna z dost obtížných na návrh a implementaci.
K nefunkcnim pozadavkum bych pridal mit moznost videt data daneho formatu jinak nez se prenasi/ukladaji. To znamena, ze format se muze prenaset jako usporna binarka, ale muzete jej videt jako dobre citelne XML ci neco strukturovaneho. Jedna struktura, vice zobrazeni.
Souhlas. On by měl existovat nějaký logický model a k němu serializace (kterých může být víc).
Word,Excel,Powerpoint 97-2003; Lotus123,...
Upřímně, do starých proprietárních formátů se pouštět nechci. Naopak jsem trochu studoval ASN.1, Diameter, ISO 8583 – to je inspirativní. Třeba ty bitmapy v ISO 8583 jsou zajímavé (i když jinak je ten formát celkem zvěrstvo).
Možná :-) Ale přijde mi lepší o věcech nejdřív trochu přemýšlet a mluvit,1 než se bezhlavě vrhnout na implementaci (pak to totiž dopadá třeba takhle).
[1] S tím, že člověk může dojít i k tomu, že to za tu námahu nestojí – což je taky dobrý závěr a výhra.
Pracoval jsem na pár projektech pro telco operátory (SMS, účtování…) a tam mě právě zaujalo, jak moc podobných formátů existuje. Mnohé byly dokonce navržené stejnou firmou (ale asi jiným týmem). Uvnitř to bylo pořád to samé dokola, nějaké TLV nebo AVP, tzn. nějaká hlavička, bajt nebo pár bajtů označujících typ atributu, pak jeden nebo více bajtů označujících délku atributu, samotná data a pak další atribut. Byly tam nějaké odchylky, datové typy byly trochu jiné atd. takže pro každý formát/protokol byla potřeba jiná knihovna resp. kodér/dekodér. Tahle variabilita byla úplně k ničemu, přínos: nula. Klidně to mohl být celé jeden meta-formát a nad ním odlišné slovníky/schémata definující specifické protokoly / formáty zpráv.
Asi nejlíp z toho vychází Diameter, který je skoro dokonalý, ale i ten má nějaké vady a není obecně použitelný.
Aby nedošlo k mýlce, meta-formát nijak nesouvisí se složitostí – XML, YAML, INI, JSON, CBOR, CSV, javovské .properties, textový formát typu klíč=hodnota… to všechno jsou meta-formáty. Spočívá to v tom, že neobsahují nic aplikačně specifického – to si nad nimi postaví každý sám.
Někdy dává smysl vytvořit DSL – ovšem to se týká dat vytvářených člověkem (ale zdaleka ne všech). Např. POV-Ray má svůj jazyk, ve kterém se popisuje scéna/model. Tam mi to nějaký smysl dává. Pak je spousta případů, kdy je i pro člověkem psané/čtené soubory lepší použít meta-formát + schéma – jednak kvůli podpoře editorů, zvýrazňování syntaxe, znalosti lidí (aby ses nemusel učit tolik formátů, abys nemusel pořád v hlavě přepínat, jak se zrovna tady píše seznam hodnot, jak se píší čísla, jak textové hodnoty, jak se escapuje…). Nicméně hlavně se tu bavíme o formátu, který není psaný/čtený člověkem, ale který slouží ke komunikaci dvou programů – a tam podle mého v drtivé většině případů aplikačně specifický formát nedává smysl a je vhodnější použít meta-formát – pro kódování a dekódování použiješ dobře odladěnou existující knihovnu a jako programátor řešíš jen sémantiku, logiku nad tím, ale nemusíš se zabývat tím, jak převést na bajty datový typ XY nebo jak dekódovat seznam hodnot.
23.7.2017 16:00
xkucf03 | skóre: 49
| blog: xkucf03
Pokud to jde, tak je zpětná/dopředná kompatibilita žádoucí – ale nemělo by to být za cenu chyb – ignorovat některé části zprávy nebo atributy by mohlo mít fatální důsledky. Např. když v nějaké verzi protokolu přibude podpora ACL a já pošli na server data k uložení a k nim připojím ACL, kde řeknu, že k datům má přístup jen někdo, tak pokud bude server ve staré verzi a ignoroval by části zprávy, které nerozumí, zveřejnil by data všem, což je jednoznačně chyba.
Pak jsou atributy/zprávy, které lze v klidu ignorovat – např. když ti poštovní server předem řekne, jaká je maximální velikost přílohy. Pokud této zprávě jako odesílatel nerozumíš a ignoruješ ji, není to žádná tragédie, při odesílání zprávy se jen dozvíš, že to nejde.
Proto je dobré ty atributy nebo rozšíření protokolu dělit na kritické a nekritické – ty nekritické lze ignorovat, zatímco když nerozumím těm kritickým, měl bych ukončit zpracování a ohlásit chybu.
Toto je důležité pro kryptografii, aby se snížilo riziko, že někdo zprávu vycpe takovými daty, že se dopočítá kolize hashovací funkce. Půjde do zprávy vložit nějaká data, která se v tichosti odignorují, ale do případného hashe by se započítala?Toto IMHO v kryptografii vůbec důležité není. Pokud používám rozumnou hešovací funkci, útočníkovi nějaké vycpávání nepomůže, pokud mizernou, mám ji zahodit. Rozhodně nemám navrhovat obezličky.
23.7.2017 16:22
xkucf03 | skóre: 49
| blog: xkucf03
Viz třeba DER kódování ASN.1 (X.690).
To, co píšeš, je sice hezká teorie, ale v praxi máš určité období mezi bodem (A) někdo1 objevil slabiny hashovací funkce a bodem (B) všichni přešli na novou hashovací funkci.
Jednoznačný způsob zápisu snižuje rizika a možné následky útoku. A je nezodpovědné pro takové případy používat formát, který útok usnadňuje.
[1] a ten to ani nemusel zveřejnit, takže se o tom zatím ani neví, nebo se teprve jen diskutuje o tom, zda danou funkci lze efektivně prolomit nebo ne
Navic mam i (nebo spise) intelektualni potreby.. Jak pise Petr - obecny ideal proste neexistuje.
Idealni datovy format neexistuje.
Co takhle si ten text nejdřív přečíst a nereagovat jen na titulek. Vždyť tam píšu, že ideální formát neexistuje a člověk si musí vybrat, která kritéria zohlední a která obětuje.
Jiny format pouzijete pro ukladani konfigurace
Dtto. Píšu, že zde neřeším konfiguraci (nebo lidsky psané dokumenty) a jde mi o formát pro komunikaci mezi dvěma programy.
Co si o tom YAMLu něco přečíst?
YAML: YAML Ain't Markup Language
What It Is: YAML is a human friendly data serialization standard for all programming languages.
A to XML je sice použitelné i pro tvorbu dokumentů, ale v zásadě i ten dokument je strom složený z uzlů různých typů (z nichž jeden je text) tzn. strukturovaná data.
XML se jako formát pro strukturovaná data běžně používá (konfigurace, data, zprávy…) a jestli je trochu ukecané, tak to není až tak dané tím, že umožňuje tvořit i dokumenty.
Ani ty jsi ten zápisek nečetl? Píšu tam, že zde neřeším konfiguráky nebo lidsky psaná data. Zajímá mě formát pro komunikaci mezi dvěma stroji/programy.
To je sice hezké, že „vše je text“ – ale ten text má většinou nějakou vnitřní strukturu – a to je právě ten formát!
kde partneri vedi, co se na kterem miste datoveho proudu nachazi
Pokud např. nevíš, že ten text máš rozsekat na jednotlivé řádky (\n nebo \r\n, na to se ještě dá přijít) a ty řádky na jednotlivé sloupce podle třeba středníků (i na to by se dalo přijít), tak ta data stejně nedekóduješ, protože neznáš formát – nevíš na kterém místě datového proudu se nachází který atribut (např. ve čtvrtém sloupečku). K tomu si připočti, že musíš mít nějak definované escapování speciálních znaků – např. co když nějaká hodnota bude obsahovat středník, který se používá jako oddělovač?
Příkazy jako grep, cut, sed dobře slouží pro ad-hoc práci, kde má člověk věci pod dohledem a ručně si zkontroluje výsledek – nebo když pracuješ s velmi jednoduchými daty, kde nemusíš řešit třeba to escapování nebo víceřádkové hodnoty. Ale pokud to má běžet bez dozoru a má to být 100% spolehlivé, tak to většinou chce jiný formát a jiné nástroje.
\0 některé věci řeší (byť tedy nemůžeš uvnitř hodnoty míst \0), ale problém je v tom, že tím nepředáš žádnou složitější strukturu – maximálně seznam/pole. Ještě se dá udělat tabulka – jako první hodnotu dáš počet sloupců a pak sázíš jednotlivé sloupce postupně ze všech řádků. Ale to už si nad tím stavíš svůj vlastní formát.
Pravda, slovník/mapa se tím dá napsat taky. Ale stejně jako ta tabulka (matice) je to už nějaký formát postavený nad tím, který má svoji specifickou syntaxi spočívající v tom, jak jednotlivé tokeny skládáš dohromady. Stejně tak bys tam mohl dát třeba JSON nebo XML – když je rozsekáš podle mezer, tak z toho máš zase jen posloupnost textových tokenů a můžeš je předat jako parametry na příkazové řádce.
O tom vím, ale neviděl jsem je nikde používat a když na ně přijde řeč, tak se na ně lidi tváří dost negativně.
% nějaký komentář $var = TEST; @TEST = (OBJNAME BUDDY); #TESTHASH = ([OBJNAME]="first simple object" [BUDDY]="more realistic object") .OBJNAME: name = something translate: 1 = first 2 = second something = xxxMám tedy k dispozici skalár/pole/hash/ a objekt s podobnou syntaxí jakou používá Bash (což byl záměr). Jako oddělovače se používají znaky \n případně ; (pokud nechci použít jako oddělovač prázdný řádek). Pro odsazení v objektech se používá \t. Takový formát snadno převedu na CSV s oddělovačem \0 takto:
22.7.2017 09:37
sed '/^[ \t]*%/d ; /^\t/{:a;s/\t/\n/;ta} ; s/;[ \t]*\([$@#.]\)/\n\1/g ; s/;[ \t]*$/\n/' | tr '\n' '\0' file.txt
K obnově a konverzi do potřebného formátu mi stačí program AWK přibližně o čtyřiceti řádcích kódu, který strean převede sestaví tak, aby byl použitelný třeba pro inklůdnutí do skriptu bashe nebo perlu.
\0 ti umožní spolehlivě oddělit prvky seznamu1 – ale pořád je to jen seznam. Pokud chceš místo seznamu mapu, tabulku, strom, nějakou složitější strukturu atd. tak si musíš definovat svůj vlastní jazyk a někde ho popsat. Např. pokud je první prvek T, tak jde o tabulku, druhý prvek určuje počet prvků a následující prvky jsou jednotlivé hodnoty tabulky v pořadí od prvního sloupce prvního řádku po poslední sloupec posledního řádku.
Bez této definice jazyka/formátu nemáš nic víc než pouhý seznam prvků. A i to, že \0 odděluje prvky seznamu, musíš někde popsat.
[1] pokud tedy samy neobsahují \0, ale to je celkem málo časté
treba RIO nebo IBNeznám ani jedno z toho, ale zní to zajímavě. Byl by odkaz? Jinak to, co popisuješ, zní opravdu specializovaně, na to opravdu asi běžně rozšířené formáty nepůjdou. Krom protobuffers vím ještě o Cap'n Proto, kde se bijí v prsa, že jsou bez overheadu, ale neznám to natolik, abych mohl říct, jestli by to šlo použít pro tvůj usecase...
~5000000zprav/s
Pěkné číslo :-)
Co se s těmi zprávami dělá? Rozparsování je jen první krok (a většinou poměrně nenáročný oproti tomu, co přijde potom). Pak je nějaké rozhodování/směrování na základě atributů v té zprávě?
K tomu by stačilo, aby ten meta-formát umožnil napsat schéma tak, že atributy budou mít fixní délky, budou začínat na pevně daných pozicích. A dovedu si představit i to, že by šlo napsat schéma tak, aby zprávu šlo napasovat na céčkovou strukturu (pokud je tedy napsaná jako portabilní, jinak bys musel mít na každé platformě jiné struktury, na které to budeš mapovat).
IMHO by to šlo a je to zajímavý příklad. Nicméně trochu extrémní – tohle je možná případ užití, který je při návrhu formátu pro široké použití lepší raději škrtnout, pokud by to mělo nějaké výrazné nevýhody v obvyklejších případech užití.
aby na zacatku zpravy byla nejaka xml sracka, ktera je ve vsech zpravach stejna
Ne tady opravdu není řeč o XML, ale o nějakém hypotetickém a (zřejmě) binárním formátu. Maximálně by to mohla být binární serializace XML, ale to není věc, kterou bych měl primárně na mysli v tomhle zápisku.
Dela se tim vpodstate vsechno, IPC pro aplikace, semafory, casovace, logovani, konfigurace, externi komunikace... Diky tomu se aplikace mohou vicemene volne presouvat mezi uzly klastru, takze aplikace, co napriklad posila ven logy syslog protokolem, nemusi bezet na uzlu, kde je ethernet (a vedet na jake IP posilat).~5000000zprav/sPěkné číslo :-)
Co se s těmi zprávami dělá? Rozparsování je jen první krok (a většinou poměrně nenáročný oproti tomu, co přijde potom). Pak je nějaké rozhodování/směrování na základě atributů v té zprávě?
jj, presne tak. Jeste pak je limitnim faktorem delka hlavicky, protoze kdyz mi prijde zprava a chci ji preposlat pres UDP na ethernetu a dokazu to poznat podle prvnich X bytu (zavisi na CPU), tak muze stacit prehazet par pointeru a zbytek udela HW, takze zpracovani jedne zpravy je jen par desitek instrukci.K tomu by stačilo, aby ten meta-formát umožnil napsat schéma tak, že atributy budou mít fixní délky, budou začínat na pevně daných pozicích. A dovedu si představit i to, že by šlo napsat schéma tak, aby zprávu šlo napasovat na céčkovou strukturu (pokud je tedy napsaná jako portabilní, jinak bys musel mít na každé platformě jiné struktury, na které to budeš mapovat).
V kazdem formatu je dobre zjistit co nejdrive, co se s danou zpravou bude delat. Kdybych chtel genericky userspace format, tak na zacatek zpravy dam hash schematu (coz mi prijde lepsi nez pochybna kombinace ID/verze, nemusi byt ani moc dlouhy, protoze se stejne musi vse overovat) a strukturu udelam tak, abych pri cteni nemusel parsovat vsechno - aby offset jednotlivejch polozek sel snadno spocitat. Rovnou by to pak i mohlo generovat BPF filtry aby si uzivatel mohl sam rozhodnout, jak si rozdeli praci mezi vlakna a nemusel na to mit dispatcher.IMHO by to šlo a je to zajímavý příklad. Nicméně trochu extrémní – tohle je možná případ užití, který je při návrhu formátu pro široké použití lepší raději škrtnout, pokud by to mělo nějaké výrazné nevýhody v obvyklejších případech užití.
To byl spis obecnej povzdech nad tim, ze spousta formatu cpe uzitecny informace moc daleko od zacatkuaby na zacatku zpravy byla nejaka xml sracka, ktera je ve vsech zpravach stejnaNe tady opravdu není řeč o XML, ale o nějakém hypotetickém a (zřejmě) binárním formátu. Maximálně by to mohla být binární serializace XML, ale to není věc, kterou bych měl primárně na mysli v tomhle zápisku.
Co je konkrétně moc dlouhá hlavička? Abych měl představu.
Např. Private Enterprise Number (přiděluje IANA) jsou čtyři bajty. K tomu stačí přidat třeba čtyři bajty pro označení typu zprávy/protokolu v rámci dané organizace + nějaké magické číslo nebo oddělovač a jsme cca na 10 bajtech a máme globálně jedinečnou identifikaci protokolu/zprávy, jmenný prostor. Je to moc nebo ne?
Pokud by se ten jmenný prostor odvozoval od doménového jména textově, tak to bude trochu víc, ale u krátkých jmen to nebude o moc horší.
Další věc je, že by šlo v rámci jedné komunikace poslat tyhle věci jen jednou a pak už se jen odkazovat na nějaké ID relace. I když pak zpráva sama o sobě neobsahuje vše potřebné a druhá strana si musí pamatovat stav.