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.


Příspěvky - František Ryšánek

Stran: 1 ... 53 54 [55] 56 57 ... 84
811
Vyzerá to zaujímavo, ale v návode som nenašiel pre mňa základné veci. Robí to aj DPH (+ kontrolné/ súhrnné hlásenia) a je tam nejaká podpora aspoň pre DPP?

Nepletete do sebe účetnictví, evidenci a daně? To jsou dva obory a v softwaru se nepřekrývají.

Riešim možnú náhradu za Pohodu, ktorá toto všetko zvláda. Takže zrejme sa prekrývať budú

Podle mého i6 u nás taky tohle všechno dělá, ale fakt je, že to asi není účto za 10kKč. A pod Wine jsem i6 před pár lety nerozchodil - ono je to dost prorostlé MS technologiemi, zřejmě včetně autentikace/crypto, má to návaznosti na všelijaká DLLka která pod Wine na gamesení nepotřebujete. Samozřejmě v těžkém virtuálu by to na windowsech běželo jako fík. Stejně tak Pohoda.

812
Vývoj / Re:Knihy o C++ a assembleru
« kdy: 18. 09. 2019, 22:39:16 »
Souhlas, taky si myslím, že jako čtení před usnutím tradiční STL úplně stačí :-) Papírové knihy asi nedoporučím, ale nějaké online čtení snad ano...

Jedno konkrétní téma, které si vybavuji jako post-STL výdobytek, jsou "intrusive containers", dlouho zmiňované v souvislosti s alternativní C++ knihovnou Boost, která se tuším hodně zasloužila o novější verze standardu. (Takový střípek vytržený z kontextu.)

Osobně jsem si taky párkrát pohrál s assemblerem pomocí NASM - hlavně v DOSu a okrajově i pod Windows a v Linuxu. V DOSu tuším jednak nějaký "hello world" hello.com napsaný v čistém NASM, a pak primitivní knihovničky přilepené k projektíkům v djgpp, Borland C++ a možná v Borland Pascalu (ačkoli tam se tuším jednalo o inline assembler). Jsem spíš takový turista, ne že bych tomu rozuměl. Hrál jsem si s tím tu a tam až někdy kolem roku 2010 (moje průmyslová branže je dost retro) a šla mi hlava kolem, co všecko se dá dneska na internetu zjistit. V roce 1992 jsem měl akorát z místní knihovny Kernighan+Ritchie C a ze školy vzácnoct: manuál od Turbo Assembleru - na základě toho prakticky nešlo v DOSu napsat vůbec nic. Tzn. několik prostředí pro DOS, pak Windows, a Linux... každé to prostředí má jiný formát spustitelného bináru (v DOSu .COM a .EXE, Windowsí PE-COFF .EXE, linuxový .ELF) a potažmo jsou v každém prostředí jiné názvy povinných sekcí v ASM zdrojáku, a pokud píšete knihovnu pro "vyšší" jazyk, tak potřebujete znát taky jeho "volací konvenci funkcí". Osobně dávám přednost syntaxi "intel/microsoft" (NASM/TASM/MASM) před AT&T syntaxí (gas, gcc inline asm).

Konkrétně se válely svého času na University of Illinois materiály ke kurzu ECE390.

Jednak knížka "Art of assembly programming". Ta je momentálně živá zde (ta homepage je ohavná, ale nakonec to asi jde číst).
 
Druhak "lab manuál" (příručka k cvičením) - pamatuju si HTML podobu, ovšem dneska vidím zdrojáky ve formátu SGML, s Makefilem který z toho zřejmě umí vyrobit segmentované HTML.

Možná bych obě našel stažené v HTML někde u sebe na disku...

V dnešní době snad už ani nemá cenu se trápit s adresací segment:offset, která byla charakteristická pro 16bitové prostředí (DOS). Tzn. v dobách, kdy "640kB musí stačit každému" a pak se řešila oblast od 640 kB do 1 MB, kde se děly magické věci... Na tohle normální člověk už dneska ani nemá fyzický hardware, na kterém by si s DOSem nějak smysluplně pohrál. Stejně tak nemá asi cenu študovat služby BIOSu a DOSu (SysMan od Lízala a Hrůzy, Ralph Brown's Interrupt List). Před chvilkou jsem ale našel docela zajímavý NASM Tutorial pro 64bit prostředí.

Naučil jsem se naprosté základy té instrukční sady: jaké to má registry, nějaké to větvení / skoky / smyčky, jsem schopen podle dokumentace stlouct volací konvenci pro rozhraní s vyšším jazykem... a na stará kolena jsem narazil na skutečného pamětníka, který mi na kratičkém příkladu vysvětlil, jaký jsem zelenáč, jak se dalo úsporně programovat, multitaskovat v DOSu, při práci s interrupty třeba implicitně vrátit STI jako vedlejší efekt POPF apod.

Taky bych doporučil, zkusit sehnat IDA PRO (třeba poslední free verzi, tuším to byla 4.9) a zkusit se podívat do střev nějaké reálné binárce. Tam si člověk pocvičí asi hlavně ty volací konvence vyšších jazyků... Bohužel se dostávám k tomu, že při hraní s assemblerem nakonec nezbyde, než si sednout ke kompu a něco si zkoušet napsat nebo disassemblovat apod. Pasivní čtení knihy je dobré fakt spíš na to usnutí :-)

813
Sítě / Re:Iptables blokace komunikace mezi eth0 a eth4
« kdy: 18. 09. 2019, 21:14:55 »
Už asi rozumím, ono to přichází i odchází eth0 a ne že to přijde eth0 a odejde eth4
Nerozumíte.
Nikam to neodchází.
Tak echo reply musí někudy odcházet?
Myslím, že už rozumíte správně. Echo reply vznikne v lokálním IP stacku a chainem OUTPUT směřuje do eth0 a ven do světa. Opět se o eth4 vlastně ani neotře a chain FORWARD se jí taky netýká. Viz KPTD.

814
Sítě / Re:Iptables blokace komunikace mezi eth0 a eth4
« kdy: 17. 09. 2019, 16:43:42 »
Už asi rozumím, ono to přichází i odchází eth0 a ne že to přijde eth0 a odejde eth4

Ping request přijde skrz eth0 a nevstoupí do chainu FORWARD, protože cílem je lokální IP adresa. Tzn. ten dotaz má snahu projít z eth0 chainem INPUT do lokálního IP stacku. Rozhraní eth4 se ten ping request v rovině IPtables nijak netýká, přestože ho adresujete lokální IP adrese, která je na toto rozhraní přiřazena...

Znáte KPTD ? Ještě si zkušte odmyslet bloky, označené "ipchains" = předchozí generace netfilteru, která skončila s kernelem 2.2, tj. málem v předchozím tisíciletí. Se divím, že ten užitečný diagram někdo neaktualizoval, aby mluvil jenom o IPtables a EBtables. Případně o nftables nebo BPF... pořád kroutím hlavou, kdo asi vyhraje...

Tohle mě na Linuxu vždycky bavilo. Na první pohled je jedno ustálené rozhraní/implementace. Při bližším pohledu najdete dvě další implementace téhož, povětšinou si můžete zvolit jednu či druhou, konkurence spokojeně vzkvétá a výsledek ani termín poslední bitvy obvykle dlouho není předem jasný. Viz též různé implementace iSCSI, ovladačů zvukových karet, trasovacích frameworků, hluboce bezpečnostních frameworků, RAIDových vrstev, init démonů, shellů... Nebo třeba utilita ifconfig. Kolik desítek let už je označována za deprecated? :-)

815
Hardware / Re:Tipy na malá levná CPLD/FPGA
« kdy: 11. 09. 2019, 18:24:32 »
Nedělám HW design a nepájím BGAčka, ale v práci prodáváme "tu a tam" nějaké to průmyslové PCčko a jsou i zákazníci, kteří s tím jezdí na vozících nebo v autech, dokola tam připojují USB-A / DB9 / RJ45 konektory apod. Vím jak trpí tyhle stroje, kde se konektory pravidelně připojují a jak s tím zachází "normální lidi". Zničený nějaký coastline konektor je jedna z nejběžnějších závad u nás v servisu.

Zcela úžasně na to funguje jedna konstrukční vychytávka: mít tyhle konektory, co jsou "na ráně", na samostatném plošáku. A na hlavní desku to mít připojené možná líp krátkým kabelem (stačí flexi PCB), spíš než nějakým board-to-board konektorem. Nám tohle řešení usnadňuje výměnu celé "periferní destičky", nebo i její opravu - pomocná destička má nižší hustotu integrace a nejsou na ní kromě konektorů skoro žádné součástky, takže se dá snáz fénovat / upnout / šmatat po ní páječkou/odsávačkou. Ve Vašem případě by se možná ulevilo "motherboardu" s velkými pouzdry od vibrací a prohýbání.

Echtovnější průmyslový hardware má kovové šasi a v něm větší počet distancí / zálisků / nanýtovaných matic, rozesetých pod velkým plošákem, aby tento nebyl namáhán průhybem ani vahou/setrvačností větších součástek.
Napadá mě, i pokud to necháte pohromadě na jediné desce, umístit poblíž "obvyklých podezřelých" vnějších konektorů na plošáku třeba 4 montážní díry pro šroubky, a zafixovat tak footprint konektorů k tuhému šasi. Aby se namáhání ohybem nepřenášelo na zbytek plošáku.

816
Server / Re:Přetížený disk
« kdy: 09. 09. 2019, 19:15:37 »
Dobre rano,

Prosim opravte me pokud nemam pravdu. Prijde mi ze pouziti md raid 1 na ssd neni uplne nejlepsi. Pokud budu delat raid1, tak se pri vytvareni obsah prvniho disku prepise na druhy disk na blokove urovni. Tim si druhy disk bude myslet ze je cely obsazeny. Asi by se to dalo resit tim ze pokud necham oba disky zesynchronizovat, muzu je pote zfromatovat, tam by mel zafungovat trim. Nicmene md raid musi poslat trim oboum diskum. Nevim zdali to umi.

Radek

Trochu nad tím dumám, a je to zajímavý tenký led :-)

Tady o tom debatěj. Sesynchronizovat oba disky při vytváření mirroru je dobré k tomu, aby se později ten mirror dal podrobovat pravidelné kontrole (porovnávat oba disky). Protože ta kontrola jede šmahem po celé ploše na blokové vrstvě, o vrstvu níž, než žije filesystém (a o filesystému nic neví).

TRIM resp. Discard tu pravidelnou kontrolu nijak neovlivní = ani neusnadní. Trim totiž z filesystému MD RAIDem de facto jenom "propadne skrz", aniž by si RAID vedl nějaká metadata pro svou pozdější potřebu, který blok je obsazený (má se kontrolovat) a který nikoli (při periodické kontrole na něj kašlat, minimálně nekontrolovat disky v zrcadle proti sobě).

Pravidelně kontrolovat celou plochu RAIDu je vhodné, protože se tím včas objeví vadné sektory. Protože když se pravidelná kontrola zanedbá, mohou vadné sektory vzniknout potichu na obou discích. Třeba na různých adresách (LBA offsetech) - ale v logice RAIDu to znamená, že oba disky budou při kompletním přečtení označeny za vadné.

Takže v tomto ohledu: počáteční sync ano, bez ohledu na to, že filesystém stejně poroste "od prázdného disku" a postupně ho zaplní svým platným payloadem a metadaty - a cokoli zapsaného bude z principu synchronní mezi oběma disky.

Ten počáteční sync lze vypnout argumentem --assume-clean, ale pak je myslím vhodné, vypnout taky pravidelnou kontrolu :-(

Tak mě napadá, resp. vrtá mi hlavou, jak je vůbec možné, že při pravidelné kontrole není principielně na škodu taky TRIM/Discard. Touto transakcí totiž disku říkáte "tento prostor je volný" = lze zrecyklovat, v případě potřeby přemapovat apod. Chápal bych to tak, že pokud takový sektor přečtete, není definováno, co tou operací získáte za data.
Takže nemá smysl, řešit jejich porovnání mezi disky navzájem při pravidelném RAID skenu. Je vůbec platná operace, číst ze sektoru, na který byl naposledy proveden TRIM? A je v tom případě skutečně uvolněn? Neznamená to spíš, že při pokusu o čtení se ten sektor musí napřed někam namapovat? Takže ten TRIM přijde vniveč? Spousta dobrých otázek :-)
No on na to zřejmě pamatuje ATA standard (hledejte první odpověď, která se zabývá variantami "Read After Trim"). Variant chování disku je dle normy možných několik, konkrétní model disku nemusí podporovat všechny, existuje ATA příkaz na zjištění podporovaných variant, a vyšší vrstvy (FS, RAID) si zřejmě mohou říct o konkrétní variantu... Zajímavé věci toto, asi bych to měl někdy pod Linuxem vyzkoušet. A zapnout si k tomu "maximum verbosity" :-) Jestli MDRAID oficiálně TRIM podporuje, měl by si být této nuance vědom. Heh vždyť ona se ta situace pro konkrétní RAID volume může změnit i výměnou disku za jiný kus (/model / verzi firmwaru).

Každopádně mi z toho plyne, že správně by bylo, použít FS, který si redundanci nějakých sektorů/bloků/clusterů prostě alokačních jednotek řeší sám, a případnou kontrolu provádí jenom nad bloky, které má dle metadat alokovány do souborů (modulo ještě třeba "děravé" soubory = alokované pouze částečně). U FS které jedou přímo nad NAND Flash je to jasná věc. U FS které jedou nad blokovou vrstvou s TRIMem je to trochu nesamozřejmé. Který to umí? Co třeba ZFS?

Anebo mít RAID, který si taky vede nějakou "bitmapu využití bloků". Per sektor by to asi trochu zabolelo kapacitně (0.2%, nebo 0.025%), sežralo by to na režii pár IOps (asi by to nemuselo běžet v "direct" režimu), ty bitmapy by se přepisovaly pořád na jednom místě, a to tak že pravidelně (tohle by mohlo zabolet z hlediska opotřebení flashky, možná i plotny).

On MD RAID má v modernějších verzích headeru tzv. write-intent bitmap - což se uplatní při rebuildu, ale nevede si to informaci o využití/nevyužití bloku vyššími vrstvami (navíc to má zřejmě dost hrubé rozlišení = velkou "velikost bloku"). Přesto ale: ejhle další věc, která by mohla zvyšovat počet zápisů na disky = opotřebení SSD, pokud porovnáváme "RAID 1" vs. "žádný RAID". Ta bitmapa dá vypnout, při vytváření pole mdadm --bitmap=none. Ale jakýkoli rebuild pak jede po celé ploše...

817
Server / Re:Přetížený disk
« kdy: 08. 09. 2019, 18:22:48 »
> 2. Proč disk nebyl teda vyhozen z pole?

Protože pořád ještě nenahlásil fatální chybu, jenom zpomalil.
Patrně mu došly volné celé erase-bloky a má čím dál víc práce s průběžnými škatule-batulemi, aby v rámci wear levelingu mohl nějaký erase block celý smazat a realokovat na něj použité uvolněné řádky, sesbírané z jiných částečně zaplněných erasebloků...

818
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 21:59:11 »
Jestli se to vyplatí, to asi nespočítám... ale k technické stránce věci:

Je zajímavé, že má UPSka vstup na externí baterii - to se často nevidí. V této souvislosti by mě zajímalo, jestli má měniče uvnitř tepelně stavěné na trvalý provoz (vs. na 10 minut jednou za půl roku).
Pokud byste vzal normální UPSku a připojil k ní velkou baterku (vyvedl si kabely ven), tak riskujete, že pokud ji zatížíte na vyšší desítky procent po neomezenou dobu, může zahořet :-) Dost UPSek nemá ani ventilátor, některé mají,
některé mají na ventilátor "přípravu".

Jak psal pan Šilhavý, že UPSka nebude mít stavěný nabíjecí obvod na velkou baterku...
Ono nejde o to, že by velká baterka "z nabíječky žrala víc a tím ji přetížila" - baterka si prostě vezme, kolik proudu jí nabíječka pošle. Osobně spíš vnímám jako problém "střídu nabíjecího cyklu" = aby nabíjecí část UPS svým proudem stíhala v cyklu s časovou střídou 66% doplnit do baterie energii, kterou si zátěž=rack vysosá v době mimo nízký tarif.

Dimenzovat v takhle krutém cyklickém provozu baterku přesně na potřebnou kapacitu, to mi přijde krátkozraké. I kdybyste uvažoval jeden cyklus s 8h "zálohou" denně, tzn. počítal byste 8 hodin provozu. Ona kapacita baterek se udává od abs.maxima do abs.minima (práh pro odpojení ochranou proti nadměrnému vybití) což je obecně dost optimistický údaj - jednak kapacita stárnutím baterky ubývá, druhak 100% hluboký cyklus nedělá dobře ani trakčním olověným baterkám (ani autobaterkám).

Pokud by mi šlo o životnost baterií (a účinnost cyklu), asi bych koukal po nějakém Lithiu a využíval bych z něj naschvál tak 20% kapacity :-/ tzn. sehnat nabíječ, kde půjde nastavit cílové nabíjecí napětí podle sebe (= snížit oproti maximu). Tuším se tu už několikrát probírala teorie, jaké napětí a hloubka cyklu dělá LiIonkám dobře...

Ať už lithium nebo olovo, spíš než po počítačových UPS bych možná koukal po "staničních nabíječích". Z místních výrobců Axima, NES, BKE. Z tohoto hardwaru se totiž staví velké bateriové zdroje v datacentrech a původně v tlf. ústřednách.

Přemejšlím, jak moc je problém zrovna s účinníkem. Pokud v tom racku většinu odběru tvoří počítačové zdroje s aktivním PFC, tak by ta zátěž měla mít účinník jako fík. K tomu střídač s čistým sínusem a ta sínusová 230V pornografie bude dokonalá.
Ale jak správně říkáte, ten správný punk je napájet počítač rovnou stejnosměrem. Přesněji řečeno, 48V je spíš nostalgické retro - ale třeba 12V hladina je naopak ten správný zelený grass-roots radikalismus. Až na to, že silnější nabíječe (vyšší stovky W a výš) začínají tuším na 24V. Protože na 12V ty dráty a ztráty vycházejí tlusté.

Opačný extrém je stejnosměr mezi 100 a 220 V. Toto je k vidění třeba v energetice, v trafačkách/rozvodnách.
Chce to speciální variantu jističů a problém je, že tohle napětí když kopne, tak nepustí. (U střídaviny je přece jenom aspoň nějaká šance.) I dobrá zpráva by se našla: přestože to výrobci ATX zdrojů přiznávají spíš vzácně, realita je taková, že snad každý zdroj s aktivním PFC a full-range AC vstupem (100-240V) reálně pojede i na stejnosměr v rozsahu cca 100-350V.

Dají se koupit ATX napájecí zdroje standardního formátu PS/2 se vstupem 24 nebo 48 V ss. (I v některých dalších divnějších formátech.) Není to levná sranda - řádově v tisících Kč. Pokud máte nějaký 1U nebo 2U server tak do něj asi "svůj" stejnosměrný zdroj neseženete - ale do nějaké skládačky s PS/2 zdrojem poměrně snadno.

Do úsporného počítače by patrně stačilo PicoPSU. To je malá destička s ATX konektorem, která pustí 12V skrz, a dovyrobí větve +5V a +3.3V (se skromnou zatížitelností). Dělá se tuším i varianta se širším rozsahem vstupu, cca do 24V = musí snižovat i na 12 V.

Pustit si do počítače přímo bateriové napětí "12V" (reálně v rozsahu 10-14.5 V) teoreticky může zafungovat.
Přímo z 12V dneska na motherboardu už žádná logika neběží, jenom snižující point-of-load měniče pro různé bloky - a tyhle měniče mívají širší rozsah vstupu. Problém by mohl nastat, pokud by deska obsahovala nějakou přepěťovou ochranu (zenerku / transil) třeba na 13 Voltech - opět by patrně unikl dým. Nebo pokud by si BIOS hlídal napětí softwarově podle health monitoru (mimo meze by nemusel projít POSTem.) A třeba PicoPSU obsahuje tuším elektronický hlídač s poměrně úzkým rozmezím - technicky možná i zbytečně, ale baterka se do toho rozmezí nevejde. A pak je tu obecný problém, že kdyby baterka ztratila kapacitu, a nabíječka by nebyla regulací řádně oříznuta někde na 14.5 V, mohlo by dojít i na skutečně smrtelné přepětí (cokoli nad 15 V je nejspíš na druhém břehu). Jo a možná bych se trochu bál o 3.5" disky - tam sice taky 12V větev napájí jenom pohon motoru, logiku těžko, ale neznám podrobnosti a byl bych opatrný.

A pak společná zem v objektu a vedení té 12V siloviny na vzdálenost kratší než nulovou = úbytky na vedení (i zemním) při těch proudech apod. Mimochodem - i bezpečný malý stejnosměr je třeba jistit, nejlíp selektivně per spotřebič. Protože to sice nekope, ale baterka do zkratu snadno taví izolaci na drátech...

819
Odkladiště / Re:Jak zdrhnout z IT?
« kdy: 27. 08. 2019, 09:53:51 »
Máš se kam vrátit.

On i ten odchod se dá v dosavadním zaměstnání podat různě. Možná není nejlepší postup, vztekle prásknout dveřma, spálit mosty, vysmát se šéfovi do obličeje. Pokud to podáte lidsky a věcně, = že už nemůžete, potřebujete na vzduch, poděkujete za ta dosavadní léta slušné práce, tak zadní vrátka zůstanou po nějaku dobu odemčená. Přinejmenším napoprvé.

820
...pak ještě koukám, že existuje starší TCPview od SysInternals. Vedle GUI má i konzolovou verzi. Jako lepší netstat, zřejmě jenom pro TCP. Odhadem některé jeho funkce Mark Russinovich integroval do novějších verzí Process Monitoru (což je takový švýcarský armádní nůž, do kterého postupně přibývají funkce z původně samostatných utilitek, klasicky filemon a portmon).

A pak bych ještě zmínil APImonitor - bohužel dost kanón na vrabce, pro kontinuální logování možná nepříliš použitelný, třeba jenom zorientovat se v konfiguraci je trochu dřina (veliký strom syscallů a knihovních funkcí, ze kterých je třeba si vybrat), tuším je třeba si vybrat konkrétní proces, který se má sledovat, a při forknutí nového procesu vyskočí GUI okno se žádostí o potvrzení, že ho má taky háknout apod.

821
Nějaké možnosti existují. Process monitor je hodně slavná utilita, zkuste si pohrát s filtrem, každopádně pokud to necháte běžet, tak přesměrujte výstup do souboru, protože RAMky může snadno být málo. Process monitor sleduje zajímavé syscally (nebo snad i knihovní volání, nevím). Na tom webíku dále zmiňují netstat, spouštět ho ve smyčce nějakým skriptem. Což znamená, že získáte sérii "snímků" seznamu otevřených relací, kde každý snímek je k určitému okamžiku v čase = nejedná se o kompletní log, co kam otvíralo jaký socket. Hledaný provinilec může proklouznout. Dále: s pouhým parametrem "-t" se Vám vypíše seznam otevřených TCP relací, ale například se nedozvíte, který program má kterou relaci otevřenou. Osobně bych navrhoval netstat s argumenty -tno, kde "o" způsobí výpis PIDu (Process ID) pro každou otevřenou relaci. Bohužel není přímý způsob, jak vedle číselného PIDu vypsat taky název EXE souboru nebo nějaký textový popis, o jaký proces se jedná - a číselné PIDy se recyklují. Leda ten típanec okamžitě zpracovat nějakým skriptem, který přiřadí PIDu ještě textové jméno procesu - s trochou štěstí to stihne dostatečně rychle, aby tam nebyly chyby a prázdná místa.

No a nakonec třeba dojdete k tomu, že ty relace otvírá svchost.exe . Což je pod Windows "superslužba", v rámci které běží v jednotlivých vláknech jednotlivé "services". Tradičně se ve Windows dalo jen velmi obtížně dopátrat, která konkrétní služba užívá jaké konkrétní zdroje, nebo způsobuje spotřebu RAM / CPU / disk IO apod. A existoval postup, jak konfigurací jednotlivých služeb zařídit, aby běžela každá služba ve vlastní instanci svchost.exe. Takhle ten opruz fungoval pod XP a Win7. Situace se začla mírně zlepšovat tuším po Win 8.1. Pod desítkami (a v novějších verzích Windows Serveru) už je přinejmenším systémový "správce procesů" poměrně inteligentní, dokáže vypisovat spotřebu zdrojů per service - nejsem si jist, jak na desítkách vypadá výstup Process Monitoru (zmíněná utilita od SysInternals).

Ještě mě napadá, že poměrně podrobný seznam otevřených TCP relací ukazuje resmon.exe, od Win7 standardní součást Windows, možná že v desítkách už integrovaný do správce procesů (nejsem si jist). Bohužel ResMon minimálně v sedmičkách neumí ukládat log do souboru, přestože potřebné informace má zjevně hezky pohromadě k dispozici (nejsem si jistý, jestli trasuje syscally jako procmon, nebo jenom dělá snapshoty jako netstat).

822
Studium a uplatnění / Re:Práce v NIC.CZ
« kdy: 23. 08. 2019, 12:12:54 »
Znal jsem pár lidí, kteří do CZ-NICu před lety přešli na řekněme administrativní pozice ("core business" okolo registrací domén). Všecko pohodáři, přitom precizní profíci. Pozdější/nové vedení osobně neznám, ale soudě zvenčí podle toho, co už asi 10 let vytváří R&D tým, čím se smějí zabývat a jaké mají výsledky, připadá mi náplň práce jako cosi z říše snů. Přirovnal bych to snad ke zlaté éře Bell Labs.

823
Studium a uplatnění / Re:Rozbitá záda, karpály
« kdy: 23. 08. 2019, 12:00:16 »
Omluva za exhumaci vlákna :-) Sešlo se mi poslední dobou pár příznivých okolností, které možná stojí za zmínku...

Především mi menší dítě dorostlo do té míry, že přesedlalo z 20" kola na 24" (je na tom větším kole dost našponované, ale menší kolo už  nechce ani za nic) a prodělalo "příměstský tábor" na inline bruslích, který si velice pochvalovalo - ne že by získalo kdovíjakou výkonnost, ale už s gustem brázdí třeba hodinu téměř v kuse. (Přičítám to skvělému vedení zmíněného prázdninového příměšťáku.) To znamená, že jsem náhle pravidelně venčen :-)

Taky jsem pořešil svoje cyklistické nářadí, takže disponuji ojetým celopérem přiměřeně moderní konstrukce, na které jsem namontoval nový zadní tlumič Manitou McLeod - asi nejlevnější tlumič, u kterého lze nezávisle štelovat útlum odskoku i _komprese_ (a samozřejmě tlakem vzduchu přizpůsobit strmost pružiny). V téhle cenové úrovni bezkonkurenční odpružení. Plus jsem přidal "ploutvovité" gripy, abych ulevil zápěstím. Prostě jsem z toho sebevědomého sportovního náčiní vytvořil takový silniční rotoped pro venkovní použití pro seniora se zchátralou páteří. Posez jak na gauči.

Jedna moje oblíbená štace: našli jsme trasu vedlejšími uličkami skrz okolní brownfieldy téměř bez aut do sousedního městečka. Převážně po asfaltu a po rovině, asi 5 km tam a 5 km zpátky. Tamní osvícená radnice zřídila bezvadné dětské hřiště, včetně pár rozhýbávacích strojů pro větší děti a zchátralé dospěláky. Chtěl bych na tomto místě zmínit konkrétní model "bočního stojacího houpadla", které dělá velmi dobře mé křížové páteři. V příloze pár fotek. (Druhý takový stroj mají v jiném sousedním městečku u cyklostezky.) Takže 5 km po rovině ulejváckým tempem na pojízdném gauči na hřiště, pohoupat křížovými obratli do všech stran ("tatí slez už z té houpačky, my už se nudíme, chceme domů"), zmrzlina u sámošky a 5 km zpátky stejnou cestou. Jako zpestření dvě rušné křižovatky s nácvikem pravidel silničního provozu.
Už jsem s tím novým tlumičem podnikl i pár vyjížděk "svým" tempem, ale nezdá se, že by vyšší zátěž páteři nějak svědčila (když to nepřeháním, tak řekněme nevadí). Možná když budu jezdit pravidelně a pomalu zvedat dávku, bude ta vyšší zátěž časem přínosná. Každopárně ty ulejvácké vejletíčky na hřiště s houpadlem fungují dost znatelně a hned. Šetrně zahřát a rozhýbat, pohoupat v odlehčení, volně doplandat domů.

Tohle konkrétní houpadlo má několik nenápadných půvabů: jednak když se přizvednete rukama, kývete nohama (páteří) v podstatě bez svislé zátěže a i bez výrazné páky do stran. Druhak to kyvadlo má sklon se samovolně vrátit dolů, a při kmitavých výchylkách do stran si můžete dost přesně dávkovat krajní hraniční polohy, které jenom "líznete" - v kombinaci se svislým odlehčením (které obecně páteř "srovná do latě") minimalizujete riziko, že se "zaseknete" v extrémní poloze. Za třetí máte chodidla mechanicky srovnaná na podložce, která má pevný úhel kolmo ke kyvadlu = když držíte chodidla na podložce, tělesná kinematika se snaží kývat přesně ztuhlou křížovou partií. Za čtvrté pokud máte aspoň trochu sílu a jistotu v pažích, můžete do toho kývavého pohybu nakombinovat "vrut" - chci říct pootočení trupu o nějaký úhel doleva či doprava, nebo se trochu nahnout dopředu a dozadu. Takže to kývavé rozhýbání není jenom kolmo doprava a doleva. A není to taková dřina na ruce, jako dospělácké prolézačky typu "bradla". Snad jenom pro postavy 180cm a vyšší by mohl být kloub kyvadla na tom houpadle o 10-20 centimetrů výš (lépe by odpovídal křížové oblasti).

A druhá oblíbená venčící trasa: dovezeme se (autem :-( ) do jednoho místního central parku, kde naše radnice nedávno vyasfaltovala bruslařský okruh, dlouhý asi 1300 m (uprostřed je pěkné dětské hřiště). Tam se jezdil ten příměšťák, takže si tam děcka připadají "doma". Tady děcka objedou cca tři kolečka, než je to přestane bavit. Já bych mohl bruslit, ale radši běžím - spíš je to takový flákací "indiánský běh".

Pár poznatků, pokud se týče stravy: předně k mému lehkému překvapení, na moje záda zřejmě příznivě účinkuje nemírná konzumace melounu (klasického červeného) - zřejmě antioxidační vitamíny a stopové prvky. Druhak náš křeček domácí má v oblibě ledový salát, ale jenom venkovní zelené lupeny. Bílé vnitřní lupeny mu nejedou = ty zbydou na mě. Nepozoruji nějaký výrazný efekt (jasnou korelaci s projevy křížové páteře), ale odhadem to taky není na škodu. A za třetí není vhodné, omezovat maso na nulu. Formuloval bych to tak, že v rozporu s obecnými poučkami, že červené maso a zejména uzeniny jsou zlo, v mém případě bych řekl, že plátek kvalitní šunky jako součást několika malých svačinek v průběhu dne není vůbec na škodu. Nejlíp když se zároveň průběžně hejbu. Nemusíte zrovna chroustat chupavky nebo čištěný kolagen prodávaný v lékárně.

Pokud se týče všelijakého "vnějšího mazání" tak mohu myslím bezpečně konstatovat, že mi funguje Traumaplant (třeba na noc - namazat plochu jako dlaň na bolavých zádech). Jestli správně chápu složení, tak ta mastička neobsahuje žádná chemická analgetika, jedinou účinnou látkou je výtažek z Kostivalu. Tzn. není třeba plenit lokality s přírodním výskytem téhle bylinky a nějak to doma zpracovávat / uchovávat.

Pak si troufnu navrhnout (neotestovanou) hypotézu, že problém v našem případě (strnulé sedavé zaměstnání) může způsobovat právě ten "historicky evolučně nefyziologický" statický tlak na plotýnky a kloubní pouzdra, nedoprovázený systémovou zátěží / vyšší tepovou frekvencí, výdejem energie ve svalech. Tělo si prostě té statické zátěže moc nevšímá. A že tělo se lépe přizpůsobí jisté míře dynamické zátěže = pokud je zátěž doprovázena svalovou námahou, zvýšenou tepovou frekvencí, tak se rozběhnou přirozené opravné a "posilující" mechanismy = určitě posilují svaly a vazy a snad i poškozené chrupavky třeba dorostou. Čili trik vidím v tom, vyvolat si pohybovou zátěž. Zejména zpočátku spíš na celý organismus, konkrétnímu poškozenému místu spíš ulevovat. Co jsem tak zatím četl, kloubní vazy a chrupavky a kluzné plochy / prostor mezi všemi těmi kloubními chrupavkami patří k nejméně prokrveným a proplachovaným částem těla. Takže pokud to "v odlehčeném stavu rozhýbeme", nějakou nezátěžovou pravidelnou aktivitou, která trvá víc než pár sekund (víc než pár minut), tak pomůžeme "výměně tekutin" (lymfy) v těch mezichrupavkových prostorech - vyplaví se "odpadky", které mají jinak sklon se tam usazovat, dopraví se tam čerství "agenti imunitního systému" apod.

Trochu extrémní příklad: strávil jsem odpoledne štípáním dříví dvoukilovou sekerou. Za těch pár let, co mě zlobí záda, už má moje motorická pamět zmáknuté pohyby / polohy / geometrie námahy, kterým se musím vyhýbat, abych si svůj problém nezhoršoval (BTW nejhorší zlo je krumpáč). Takže jsem se vcelku dokázal pohybovat tak, aby páteř netrpěla. Večer jsem cejtil zápěstí a ramena, ale křížová páteř na tom byla ráno překvapivě líp než jindy... Možná pokud je ten problém v kříži ("revma") taky částečně autoimunitní, prostě měl imunitní/samoopravný systém "zrovna práci jinde", takže např. nějaké otoky v křížové oblasti dočasně ustoupily...

Netvrdím, že tyhle nápady budou fungovat každému. Bolavá záda můžou být rozbitá různými způsoby, může se jednat u různých lidí o různé problémy (čistě mechanické různého druhu okolo plotének, ochablý svalový korzet, dna, artrotické poškození kluzných povrchů kloubních hlavic, nebo komplikované latentní infekcí, obecně autoimunitní apod) s různou geometrií, různou mírou poškození plotének / vazů / kloubních pouzder apod. Čili opatrně a různé "recepty" testovat s rozvahou.

Ty drobnosti, co částečně fungují, je vhodné pro maximální účinek kombinovat. V kombinaci s míchanými léčivy lze zaslechnout názor, že "míchaná léčiva jsou zlo, protože když to zabere, tak nevíte, co konkrétně zabralo". Můj názor je, že to možná zabralo právě díky té směsi, díky účinku na více frontách současně, proti více problémům. Ostatně přesně v tomto duchu se naopak míchají směsné bylinkové čaje. Problém je potřeba potlačit co nejvíc, aby neměl sklon se dál/znovu rozjíždět. Aplikováno na bolavá záda, nejlepších výsledků dosáhnete kombinací vhodného pohybu, stravy a mazání... Pro mě osobně je vzácná jediná ingredience: volný čas. Čas kdy se můžu hýbat podle svého.

824
Distribuce / Re:Boot na druhy pokus
« kdy: 22. 08. 2019, 19:55:52 »
Po 10 letech je možné ledacos. = i já bych doporučil, vyvrátit hypotézu tím, že to zkusíte s jiným zdrojem - pokud možno solidním. Taky se pro zajímavost podívejte dovnitř do původního zdroje, jak vypadají elyty na výstupu.

825
Distribuce / Re:Boot na druhy pokus
« kdy: 22. 08. 2019, 13:45:23 »
Jak starý je ten zdroj, a co je to zač?
Co jsou zač ty dvě desky, stará a nová?

Stran: 1 ... 53 54 [55] 56 57 ... 84