Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Témata - František Ryšánek

Stran: [1]
1
Lidičky, odpusťte mi.  Asi se nudím, nebo je to příznak blížícího se mentálního důchodu... ale zamýšlím se nad takovou napohled primitivní a povrchní otázkou. Odtud toto téma.

Ukládání věcí ve firmě do souborů. Jak v tom udělat nějaký pořádek. Třeba nedokonalý, ale systém.
Asi se tím zhruba zabývá obor "document management" - možná komplet, možná zase jenom nějakou fasetou. Nepochybuju, že jsou na trhu softwarové produkty, které se snaží tvářit, že Vám to jednou provždy "vyřeší".

Jasně, máme provozní systém (účto nebo ERP nebo tak něco, podle toho jak je firma velká). Do kterého patří nějaké věci. Kromě toho v organizaci putují různé další soubory. Něco člověk stáhne z netu a je to pro něj užitečné a chce si to nechat (a do databáze ERP to nepatří), něco člověk třeba sám tvoří: interní dokumentaci (sesbíraná data a poznámky) k nějakému "případu", archivní ovladače pro konkrétní model či rodinu hardwaru, nebo nějaký content na web, nebo data k projektu (libovolný ne-IT obor), nebo třeba softwarový projekt nebo tak něco na ten způsob...

Prostě fůra souborů, které člověk buď někde získá, nebo sám vytvoří, a nerad by o ně přišel.
A člověk pracuje ve firmě/organizaci, a v kolektivu třeba sypou některé druhy takto získaných dat "na společnou hromádku" (sdílejí tu hromádku dat v pravém slova smyslu). A potřebují se v tom kolektivně orientovat, nastavit nějaká pravidla, jak strukturovat strom adresářů apod.

Teď ponechme stranou, že jsou v kolektivu lamy, které mají mentální problém pobrat stromovou strukturu adresářů jakožto velmi základní a obecný koncept. A sypou svoje data kam je zrovna napadne, tak jako že šli zrovna okolo. Sdílený fileserver pak vypadá jako předměstí v banánové republice bez svozu odpadků.

Na druhé straně jsme krasoduchové jako já, kteří se tím snažíme zabývat koncepčně, v rovině "datového modelování a metamodelování" - a nejsme z toho o moc moudřejší než početná "střední vrstva" všelijakých kolegů a šéfů, kteří jsou mentálně někde mezi = nevidí tu hrůzu v celé koncepční hloubce a bojují s tím jak umí, tzn. částečně ad hoc, mají sklon podlehnout reklamě dodavatelů NASů, softwarů na "geniální document management" apod.

V zásadě je problém v tom, že naprostá většina konvenčních filesystémů prezentuje uživateli "strom adresářů". Ten strom je vlastně index, pro jednoznačnou (a jedinou?) adresaci přístupu k datovým objektům (souborům). A problém je v tom, že koncepčně můžeme mít mentální problém říct, který aspekt/atribut/kritérium souboru má být určujícím pro třídění = pro formování té stromové struktury. Příklady možností:
- per uživatel (jasně, máme home adresáře)
- per zákazník
- per "projekt"
- per značka/model/rodina hardwaru
- per oddělení/oblast interních činností ve firmě
Který aspekt zvolit jako primární? Je vůbec některý z nich "nepochybně obecně primární"?

Můžu uvažovat tím směrem, že si prostě jeden aspekt jako primární zvolím, a tento použiji pro zatřídění do stromu souborového systému. A následně se budu snažit použít třeba symlinky nebo "extended attributes" nebo třeba klikatelné indexy v HTML formátu, abych zařídil "sekundární odkazy", které neznamenají "vlastnictví" objektu ve stromě (tím je primární umístění). Bohužel operační systémy mi tuto bohulibou "anotační činnost nad primárním souborovým systémem" nijak neusnadňují, znamenalo by to používat nějaký dodatečný software, řešit multiplatformnost (bye bye symlinky a xattr) apod.

Výrobci OS dokáží ještě tak propašovat do OS "indexační engine", který pravidelně ráno po spuštění počítače sežere na hodinu 100% disk IO kvůli reindexaci...

Anebo prostě cpát BLOBy do databáze a dávat jim nějaké tagy, podle kterých jsou dohledatelné. Ať už ty bloby jsou primárně umístěné jako soubory na disku v mělké/tupé adresářové struktuře, nebo přímo v RDBMS.

Interní dokumentaci lze spravovat třeba v nějakém Wiki-based enginu... prostě hypertext. Což je ale práce navíc, a nakonec to stejně moc neřeší, "kam sypat bloby všeho druhu a jak v nich udržovat pořádek".

Pokud se vrátím na zem k obyčejné adresářové struktuře, tak řekněme, že lidi dostanou home adresáře na fileserveru, do kterých si tradičně navzájem nevidí (za normálních okolností), a pak bude existovat nějaký "sdílený share", kam můžou všichni, případně mají nějak rozparcelováno uživatelskými právy, kdo smí kde zapisovat/mazat apod. A pak se podrobněji uplatní nějaká kritéria, jak věci podrobněji třídit.

A teď si vemte, že ten sdílený share je někde na fileserveru. A lidi mají každý noťas, s ním cestují, a třeba taky chtějí pracovat offline, nechtějí být závislí na internetové konektivitě (protože VPN). To znamená, že si chtějí některé věci zrcadlit na lokální disk v noťasu. Ale jaksi nejde, aby si každý ve firme synchronizoval na své noťasy celý fileserver - prostě z kapacitních důvodů. Řekněme, že lze realizovat synchronizaci "home adresáře". Nojo, ale co věci na sdíleném sharu? Synchronizovat jednotlivé foldry, které si uživatel nějak označí? To už zase vyžaduje netriviální pozornost. Nebo mít pravidlo "pracuju na noťasu, a co vytvořím v tomhle adresáři, to se syncne na server, ale nikoli naopak"? Co když na jedné věci pracuje víc lidí, a třeba se naštěstí nepotkávají nad jedním souborem (není třeba řešit slučovací konflikty) ale hodilo by se, synchronizovat množinu souborů?

Jasně, existují specializované "softwarové systémy" pro konkrétní použití: podnikové aplikace (na škále mezi účtem a ERP), existují systémy pro správu verzí zdrojáků (GIT a jeho poddaní), řadil bych sem i kanonické "document management systémy" třeba na ISO dokumentaci, nebo třeba obyčejnou DokuWiki apod.

Zůstaňme ale ještě chvíli u "holých souborů v adresářovém stromě". Realita je taková, že se zvolí nějaké kompromisní uspořádání, a ono to nějak (kompromisně) funguje.

Ďábel se ovšem skrývá v detailu a občas se ohavně zasměje - třeba ve chvíli, kdy šéf prohlásí "potřebujeme zlepšit zálohy". A má představu, že zařídíte zálohu toho kompostu na celofiremním sdíleném svazku, nejlíp se zachycením chronologie. Toto na prostoru, kam lidi ještě s bídou mentálně zvládnou sypat čerstvá data, ale nejsou už mentálně schopni, třeba jednou za čas uklízet = odmazávat nepotřebné staré verze dočasných imagů toho či onoho apod. Nemluvě o vysloveném odpadu, který tam nikdy nepatřil. Třeba narazíte na to, že někdo už pár let do GITu ukládá archiv surových videosekvencí z nějakého přístroje pro kontrolu jakosti... nebo někdo navrhne, že se do ERP mají archivovat instalátory ovladačů a doprovodného softwaru toho či onoho... (a zálohy ERP jsou ty nejpečlivější, co máme).

Takže můžete nakoupit veliký storage, který Vám bude s nějakou rezervou stačit na aktuální rozměr nahromaděného kompostu. A můžete se snažit o deduplikaci. A prostě to urvat hrubou silou. Proti Vám stojí rostoucí dav bezelstných užovek, které se o pořádek nestarají do chvíle, dokud jim nepřeteče disk - a pak mají sklon řešit problém tím, že žádají disk nový a větší, nebo naopak mažou bezhlavě i věci, které by třeba někdo jiný rozhodně zatím nemazal apod.
A v mnoha případech je pravda, že hardware je levný, zato omylem smazat nějaká unikátně pořízená data (třeba i poměrně objemná) může hodně bolet, i ve finančním vyjádření.

Nebo si přiberete k dosavadnímu popisu práce ještě roli "datového pedanta a uklízečky". Budete pravidelně pročesávat diskový prostor a hledat nápadně velké objemy dat, a prudit jejich vlastníky s dotazem, zda je to ještě potřeba, zda to tam vůbec někdy patřilo, zda to náhodou "podle zavedených konvencí" nepatří ve stromě adresářů někam úplně jinam, nebo aspoň o úroveň níž, apod. Tzn. ono to taky znamená, hrabat se lidem v "soukromém" nepořádku. A při tom neustále koukat na zaplnění záložního storage.

Když za někým přijdete, že byste potřeboval, aby si udělal pořádek v datech, zhruba "dle takových a takových zásad". Víte jak to skončí? U mě většinout tak, že mu ten pořádek musímu udělat já. Za různých okolností jsem se k tomu už párkrát dostal (zálohy, migrace, přetečení disku, disaster recovery). Prostě lidi jsou ještě schopní uklidit si na stole - ale uklidit si na harddisku? :-DDD

Přiznám se, že jsem tohoto "v podnikovém rozměru" naštěstí zůstal zatím převážně ušetřen, protože jsem nikdy nedělal správce fileserveru ve firmě větší než malé - a v malém kolektivu se věci snáz řeší "out of band", když se všichni denně vidíme navzájem... Mohu se komukoli osobně vysmát v odpověď na dotaz "ty Franto neměl bys někde volných pár desítek TB? já bych tady potřeboval něco dočasně odložit / zazálohovat"...

Podle mého je to prostě boj. Je to o osobním sklonu k pořádku (nebo o jeho pravém opaku). A pak ten hlavolam, podle čeho soubory třídit, když si musíte zvolit pouze jednu primární hierarchii, a implementovat "druhotné paralelní hierarchie" je problematické. A připadá mi, že je ten problém posledních 30 let pořád tak nějak stejný - nebo jsem šeredně zaostal.

Takže končím s vynalézáním suché vody (četli jste někdo Neználka?) a jdu zas něco kompromisně rozseknout.

Z toho, že existují a fungují velké firmy, usuzuji, že spousta těch dílčích "problémů", o kterých fantazíruji, je dávno vyřešená (= vynalézám kolo). Ostatně jsem od svých zákazníků tu a tam nějaké rady a postupy z "corporate" prostředí zaslechl :-) Naschvál je nebudu citovat.

K nakousnutí tohoto tématu ve fóru mě poňouklo, že na to téma nevidím nikde nic sepsaného "v kostce" - jako že akademickou publikaci, nebo nějaký "best practices" blogospisek, ani si nepamatuji, že by o tom někdo třeba tady na rootu zeširoka debatoval. Řeší se tu věci jako ZFS nebo CEPH, ale to jsou technologické vrstvy pod VFS, které se snaží "vstřebat cokoli, co na ně užovky nahází a nějak se s tím důstojně vypořádat", se slušnou průchodností, redundancí apod. Mě jde spíš o to, jak zajistit pořádek ve strukturách, které jsou uživatelům viditelné a jimi ovlivnitelné - k čemu je vést, jaká jim stanovovat pravidla, jak uživatelům zjednodušit život v této rovině. Aby příště našli, co dneska někam uložili/zatřídili. A aby to dokázal najít taky někdo jiný.

Koho jsem pohoršil mělkostí této své halucinace, tomu se omlouvám.
Uvítám jakékoli reakce - asi už mě znáte...
A pokud se mi podaří vyprovokovat k věci flame war, tak možná tím líp :-)

2
Hardware / Prodává se nový noťas se 2x SODIMM slotem?
« kdy: 10. 09. 2021, 22:11:57 »
Dobrý den vespolek,

řekněme "z dlouhé chvíle" si aktualizuju představu o trhu "levnějších" notebooků a žasnu, kam se branže posunula. Točivé disky pryč, SATA SSDčka ve 2.5" formátu pryč, M.2 NVME SSD běžně půl tera, s trochou štěstí druhý M.2 slot k dispozici...
V jednom nejmenovaném e-shopu jsem zjistil, že už jenom menšina nabízených strojů má metalický RJ45 Ethernet - jako že "normálním lidem přece stačí wifi". No děkuju pěkně...

A proč vlastně píšu = můj dotaz: dělá se vůbec ještě nějaký noťas, který by měl 2x SODIMM slot?

Všecko co jsem viděl, má jeden kanál zaplácnutý 4 GB onboard, a na druhém kanálu SODIMM slot, běžně osazený 4 GB. Vyšší modely 8 GB natvrdo onboard + 8 GB ve slotu - ale 16 GB už jsem viděl jedině v kombinaci se stand-alone grafikou, což osobně nepreferuji (stačí mi IGP, taky míň žere a motherboard je s ním jednodušší). Na tomhle mě štve, že jeden kanál RAM má natvrdo konkrétní kapacitu a rychlost. Takže pokud osadím větší SODIMM do slotu, většina kapacity RAM pojede neprokládaně. Kromě toho onboard bývá poměrně malá kapacita, čímž přijdu do budoucna téměř o půlku kapacity, kterou by procesor zvládl pobrat. Asi planned obsolescence :-(

Je to divná doba. Jestli máte někdo přehled, tak mě prosím nasměrujte. Díky za pozornost :-)

3
Já jsem asi vážně mimo a asi už i dost dlouho. Přišel kolega "hele potřebuju TXT záznam v DNS, kvůli jednomu kancelářskému SW balíku. Prej abych dodavateli ověřil, že legitimně užíváme doménu, na kterou je u nich v cloudu napojené naše předplatné, které mám správcovat." Zdvihl jsem obočí, na ověření identity u projevu vůle mezi firmami jsou přece dávno zavedené jiné postupy a inštrumenty, ale říkám "jasně, vím co je TXT záznam, tak mi dodej jak se má jmenovat a co má obsahovat". No a trochu mě nadzdvihlo, když mi přišlo "jméno: @"  . To si jako třetí strana dupne, že chce svůj TXT záznam přímo na 2nd-level jméno naší DNS domény?

No evidentně ano. Pokud se týče mého duševního rozpoložení, trochu mě uklidnilo, že ten TXT záznam na 2.úrovni není exkluzivní. A nakonec jsem zjistil, že zmíněný konkrétní provozovatel cloudové aplikace tuhle fintu zřejmě sám nevymyslel.

Není potřeba ani složitě googlit, kdo všechno tohle svým klientům dělá. Zkuste si vypsat "host -t txt $domena" kde za $domena dosaďte 2nd-level doménu libovolné veliké firmy nebo třeba úřadu na celostátní úrovni (mluvím o firmách v roli dotčeného uživatele).

Kde je nějaká ohleduplnost / pořádek? Přístup "řádného hospodáře" ve správě DNS? Vždyť i DKIM si skromně vystačí se jmény čtvrté úrovně (jsou navěšena na jediném jméně 3.úrovně _domainkey). Kdyby se tahle móda (každý svůj TXT záznam na 2nd-level doméně) rozmohla i v druhé a třetí lize SAAS poskytovatelů, tak se nám to DNS pěkně zaplevelí. Celé to vypadá jako přetlačovací hra. Kdo posprejuje víc nároží svojí muří nohou. Kdyby se tohle standardizovalo = vyrobit na to well-known subdoménu třetí úrovně např. _owner_validation (helemese podtržítko), byla by to pro rozpustilé megakorporace jistě mnohem menší sranda. Hehe oni to po sobě chtějí nejspíš i *navzájem* ;-)

Stran: [1]