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 ... 38 39 [40] 41 42 ... 84
586
OK, tak sa rozhodujem medzi týmito:

https://www.alza.sk/brother-dcp-l8410cdw-d4977646.htm
https://www.alza.sk/hp-color-laserjet-pro-mfp-m479fdn-d5634918.htm
https://www.alza.sk/canon-i-sensys-mf742cdw-d5597886.htm

Já bych šel do toho HPčka. Jako nevýhodu vnímám, že není skladem.

Ono HPčko taky není úplně pozlacené, taky občas najdu nějakou mouchu, ale pořád je jich míň než u konkurence. A ten model, co jste vybral, nebude levný šunt. Hlavně HP stanovuje průmyslové standardy pro formáty tiskových dat. Pokud jste linuxovej, tak to oceníte.

587
Pokud si cca správně pamatuju, cena do 50 kKč za PC server s pár diskovými šuplíky (nebo noname DAS RAID box) vychází tak na nějaké SuperMicro nebo taiwanský RAID s řadičem Accusys/Areca. Možná. Záleží co do toho za motherboard a procesor a kolik RAM. Pokud to má být spolehlivé, tak něco s ECC = entry-level Xeon. Pokud se do toho má vejít víc jak 64 GB RAM, tak to IMO vede na plnotučné Xeony. Supermicro se tu dá koupit. Záruka od výrobce je v základu 1 rok, ale náhradní zdroje bývají dostupné dlouhá léta po záruce. Otázka je, jestli tam cpát HW RAID (který pro nějakých 16 kanálů už taky něco stojí, může být úzkým hrdlem průchodnosti apod.), nebo připojit disky přes prosté HBA - ale o to složitější může být softwarové řešení.

Externí RAIDy a JBODy s Arecou dodává dlouhá léta pod svou značkou německý Starline. Externí box může mít nativní iSCSI, nebo DAS připojení přes SAS či PCI-e. Pravda je, že skvělá doba velkých boxů s mnoha točivými disky je pryč... A záloha dvou řadičů je výsadou spíš fajnovějších značek (jako minimum bych viděl Infortrend, ačkoli koukám že Areca to umí údajně taky) - ale tohle je spíš v rámci jednoho šasi. Poptávka zjevně zněla na nějaké modernější řešení redundance :-)

Nezkoušeli jste někdo CEPH ? Nešel by zapřáhnout? Bloková abstrakce nebo i větší soubory jako bootdisk pro ty virtuály (aby těmi soubory nebo oddíly disponoval hypervizor), případně dát jednotlivým virtuálům přímý přístup i k "souborové abstrakci", pokud bude zájem? Jsem pustý teoretik, nesáhl jsem si na to.

588
Myslíte si že ten atrament skutočne toľko vydrží? Nezashne ani pri dlhšom nepoužívaní tlačiarne? Niekedy sú dni kedy tlačíme aj viac krát za deň, ale máme aj dni kedy tlačíme len raz za pár mesiacov. Tak aby nezashla.

...to je právě ta bolest barevných tiskáren "na doma".

Buď se praštíte přes kapsu a pořídíte si laser, a náplň poprvé vyměníte za 5 let. A nikde nebude nic zasychat.

Nebo si koupíte inkoustovku, protože "na doma je laser moc drahý", a ať už ta inkoustovka bude za dva tácy nebo za deset, jisté jsou dvě věci: při pokusu o tisk bude napřed dvě minuty čistit hlavu, a časem ji zapomenete provětrat a něco v ní zaschne. Viděl jsem tankový systém tuším od Epsonu a zaschlo to časem taky, pokud se nepoužívala. A pokud nebudete ultra-pedant, že chcete fakt jenom echt značkové náplně (inkousty), tak alternativy mají sklon k zasychání asi ještě horší. Přijmete od prodejce neznačkovou náplň, pokud byla čerstvá tak bude zpočátku fungovat, ale protože má vyšší "vysychavost", tak vám zaschne v hlavě - a samočištění už ji nevyprostí... A pokud budete fakt pečlivka, a ta tiskárna Vám bude nějakou dobu fungovat, tak u inkoustovek se vžila všelijaká počítadla stránek a podobná kurvítka...

Jedna možnost je, přistoupit výrobcům na jejich hru, koupit inkoustovku za dva tácy (Kč) a přibližně až dojde původní náplň, tak ji vyhodit do popelnice a koupit novou, v téže cenové kategorii.

Nejspolehlivější byl vždycky černobílý laser, stačí cca druhý nejlevnější :-)

589
Doporučuji vlézt na CZC nebo zelenou obludu, vyfiltrovat HP, seřadit od nejlevnějších vzestupně, a koukat, jak přibývají fičury. Plnohodnotný toner v ceně prvotního pořízení, RJ45 Ethernet, duplexer tisku, pokud to má být multifunkce tak skener s podavačem stránek nejlépe duplexním... nejlíp aby uměla Postscript - v tom případě určitě bude umět taky PCL6 a PCL5e. Zapomněl jsem na něco?

Rozhodně nebrat úplně tu nejlevnější - hrozí, že to bude nějaká GDI hrůza = ovladač na míru s jepičí životností ve víru "technologického pokroku" operačních systémů. = nejmíň druhou nejlevnější :-)

PCL5/6 sice nejsou svobodné formáty v pravém slova smyslu, ale jsou natolik rozšířené, že je lze považovat za "průmyslový standard". A přestože pozoruji, že se v průběhu posledních 20-25 let jejich podpora v OS trochu vyvíjela (třeba PCL5e z nových windows už moc nejde tisknout na starší tiskárny okolo přelomu tisíciletí) tak pořád je tam určitá záruka, že k tomu pár let do budoucna seženete tiskové ovladače pro jakýkoli OS.

Bacha běžné barevné lasery točí válci v barevných patronách i ve chvíli, kdy tisknou pouze černobíle. Tzn. teoreticky spotřebovávají pouze černý toner (laser kreslí jenom na válec černé patrony) ale nějaké zbytkové množství barevných pigmentů stejně ulpí na válci a skončí na papíře = je tam nenulová spotřeba barevných náplní i při čistě ČB tisku.

Podobně u inkoustových tiskáren, ty zas dokolečka čistí hlavy. (Která nečistí dost často, ta tím spíš zaschne.)

Pamatuju jeden starší Phaser, kde výměna silikonových zapékacích válců stála tolik, že prakticky nemělo smysl, tiskárnu opravovat... Dnešní barevné lasery mají tuším válce kovové. Jak je to s cenou náhradních dílů, bůh suď.

590
Studium a uplatnění / Re:Jak začít programovat od nuly?
« kdy: 01. 02. 2021, 14:42:13 »
Hlavně proboha nezačínej s C++ ;D. Naopak časem (až budeš umět základy) můžeš přidat trochu C.

Můj vývoj: v osmdesátých letech jsem zahlédl tu a tam útržky 8080/Z80 ASM na papíře. První vlastní PC v roce 1992, do té doby jsem měl páječku. Na PC začátky basic, pascal - z obojího rozpačité pocity (v tehdejší době špatná dokumentace, nebyl internet). Ve škole mi půjčili jednu knížku = referenční příručku k Turbo Assembleru (Borland, x86, syntaxe Intel) - to bylo zajímavé čtení, ale nekompletní, napsat podle toho něco se moc nedalo. V knihovně jsem začátkem devadesátek narazil na český překlad (?) Kernighan+Ritchie C - to byla poezie. Konečně nějaký jazyk dobře vysvětlený a relativně úsporný. Ale v té době jsem se nedostal k překladači. To až později, patrně na vejšce... (1995 nebo tak nějak). Pořád jenom Borland, ale oproti Pascalu labůžo. Konečně jazyk, který z člověka nedělal blbečka, měl kompletní sadu operátorů pro bit-banging, bohatou sadu datových typů blízkých "stroji". Pro mne bylo Céčko od té chvíle "jazyk, podle kterého se Pascal opičí a stydí se za to" - a na vejšce byly první povinné kurzy algoritmizace v čem? V pascalu :-( Teprve když jsem se dostal ke konci 90.let k Linuxu, pohltilo mě céčko doopravdy - v podobě "GNU ekosystému". Spousta examplů a další dokumentace. Objevil jsem celý svět s poměrně dlouhou historií, která vedla třicet let zpátky někam do Bell Labs... žůžo. C++ jako nadstavba céčka... jo, to se dalo pochopit a uchopit. Takže už ne gcc ale g++. A knížky kolem toho. Konečně v GNU světě jsem začal ostře rozlišovat C od C++ tzn. která z těch dvaceti různých funkcí, jak poslat znak či řetězec na standardní výstup, je ještě céčko, a která už je C++. (Protože Borlandí IDE podporovalo C i C++ a moc mezi tím nerozlišovalo.) Zrovna v tu chvíli mi v práci začla přicházet i smysluplně velká zadání, přestože "do šuplíku" / mimo popis práce. Objektové přístupy začaly dávat smysl. Ve škole základní věci v rovině algoritmizace - datové struktury, jak to jde dohromady s alokací paměti apod.

Od té doby když vidím cokoli závorkovatého odvozeného od C, tak se zhruba orientuji, ale pokaždé si říkám "nojo, tohle je wrapper okolo libc, a není moc povedený ani kompletní" nebo "aha, takže integer, ale délku a znaménko řešit nemám" nebo "jasně, máme garbage collector, takže po sobě neuklízíme a jsme na to pyšní" apod. Ale že by mě něco chytlo u srdíčka víc, než C/C++, jakožto programovací jazyk, tak to ani náhodou.

Potkal jsem v pozdějším věku i Pascal na holém železe, v jedné takové retro-údržbě, a s dnešní dokumentací jsem se dozvěděl o spoustě syntaxe, kterou v základních učebnicích Pascalu nenajdete, přestože ji Borland podporoval zřejmě už dávno - a která doplňuje právě ty věci, kterými se Céčko nijak netají a nikdy netajilo. Přesto ani v tomto kompletnějším skupenství mě Pascal za srdíčko nechytil. A pokud se týče Pythonu... pohyblivý cíl, neúplné wrappery okolo céčkových knihoven a syscallů, garbage collection, bloatware, instalační systém stižený vleklou revolucí... nic pro mě :-)

Ale já jsem "jinej". Jednak jakožto programátor věčnej hobbík, jednak jsem byl asi povahou systémák ještě než jsem si poprvé šáhnul na klávesnici.

Vybírejte si nástroje podle zadání, které dostanete - resp. podle hobby námětu, který Vás oslovil svou šťavnatostí.

Nebojte se číst, nebojte se experimentovat. Nebojte se debatovat! :-) Když čtete, nebojte se překakovat věci, které zatím nechápete, nebo nepotřebujete. Případně knihu odložit v půlce, pokud je jedněch nebo druhých věcí náhle většina. Dost možná je vinou autora, že zábava náhle uvadá - nebo se Vám prostě další kapitoly už nestrefily do vkusu.

A souhlasím s Jendou, že je blbost začínat ausgerechnet C++, dokud člověk nezná céčko. Tzn. pořídit si knihu, která začne hezky zostra rovnou vychytávkami C++ (a jaksi samozřejmě předpokládá, že člověk je Céčkem už načichlý). V takové situaci bych asi taky reagoval "WTF". Mimochodem starší kniha Thinking in C++ od Bruce Eckela tuším začíná pár kapitolami o Céčkových základech. Tu bych si jako první čtení dokázal i představit...

591
Software / Re:Chyba disku vs. chyba souborového systému
« kdy: 27. 01. 2021, 12:02:15 »
Jinak ještě poznámka k destruktivnímu testu přes badblocks - pokud se dobře pamatuju (kdyžtak mě někdo opravte), tak takový test nemusí sám o sobě odhalit vadné sektory. Jde o to, že pokud jich nebude moc, tak zápisem do vadného sektoru dojde k jeho přealokování diskem a navenek se to z hlediska procesu, který zapisuje (badblocks) bude jevit tak, že všechno proběhlo OK. Jinak se to navenek projeví pouze zvýšením hodnoty SMART atributu "reallocated sectors count", takže tu je dobré si případně před takovým testem někam poznamenat a pak porovnat s hodnotou po testu.

Zhruba souhlasím :-) a taky to nevím přesně a podrobně.

Pokud disk při čtení narazí na sektor, který fakt nepřečte, tak podle mého vrátí řadiči (HBA) chybu média, ale může "pro příští použití" ten sektor realokovat - tzn. přibyde reallocated sector count i offline uncorrectable?

Pokud "ho přečte ale" tak má šanci ho realokovat potichu, přibyde jenom reallocated sector count.

Při zápisu mi není jasné, jak by disk mohl zjistit vadný sektor, když ho zapisuje (leda by zapsaná data vzápětí verifikoval, což IMO nedělá, nebo by ho zkusil předem přečíst, což taky nedělá - už proto, že by mu taková zápisová operace zabrala dvě otáčky.) Zjistit vadný sektor může při zápisu snad jedině tak, že není schopen ani navést hlavu na stopu (seek error / track not found). Navádění na stopu se totiž děje pomocí nějakých režijních značek, které jsou na plotně vyrobeny ve fabrice a za normálních okolností prakticky nezničitelné, resp. mnohem odolnější, než záznam užitečných dat vlastní hlavou. V tom případě by disk mohl při zápisu realokovat - celou stopu (všechny sektory na postižené stopě). Ovšem nakolik toto v praxi potkáte jako "gracefully" odstíněný problém, o tom mám svoje pochybnosti, protože nenalezení stopy obvykle znamená "vidím disk mrzutý, jehož hlava plotny se dotýká" - takže u takového disku rychle řešíte jiné věci, než pár realokovaných sektorů.

592
Software / Re:Chyba disku vs. chyba souborového systému
« kdy: 27. 01. 2021, 10:44:38 »
Znovu: ve SMART logu vidím (pouhé) dva výskyty charakteristické chyby, že někdo zkusil přečíst sektor 0x0FFFFFFF pomocí LBA28. Netvrdím, že tuto chybu zreprodukujete v tom Linuxu, pod kterým aktuálně testujete - třeba proto, že ten Linux se s diskem baví nikoli přes USB mass storage, ale skrz "tunel" zvaný SAT, takže možná lžičkuje čísla sektorů správně. Nebyl by kompletní výpis dmesg, kde je vidět nalezení a inicializace /dev/sde + jeho odpovídajícího HBA?

Bohužel neznám badblocks. Zaujalo mě, že nahlásil 1 953 514 582 "bloků", ale v dmesg vidím chybu při čtení LBA sektoru č. 3 209 068 147, a pohledem do Vašich výpisů smartctl vidím 2TB disk = to znamená, že dmesg mluví o low-level LBA sektorech o tradiční velikosti 512B, které potkáte ve většině low-level toolů jako jsou různé odrůdy fdisku, kdežto badblocks mluví o "blocích" velikosti 1 kB, ve kterých se vyjadřuje třeba df nebo du (což jsou ale spíš nástroje nad filesystémem). Doufám, že si to vysvětluju správně.

Zlatý starý IDE/ATA subsystém v Linuxu, který vypisoval do dmesg podrobné hlášky včetně ATA commandu, který selhal, a kódu chyby tuším z jakéhosi stavového registru IDE/ATA. Bohužel toto je minulost.

Znovu doporučuji, zkuste si stáhnout a zkompilovat hddtest - možná Vám dá přehlednější průběžnou informaci než badblocks. Například průběžně ukazuje rychlost přenosu.

Jinak docela dobrý tool na zobrazení okamžité rychlosti v MBps a IOps je iostat z balíku "sysstat". Doporučuji spouštět tak, aby data vypisoval periodicky - např. "iostat 2". IOstat je jenom ukazatel, nikoli generátor zátěže = spusťte si ho na samostatné konzole, zároveň se zátěží, kterou generuje třeba badblocks (nebo cokoli jiného, oběcně živý systém).

Ano, externí disky v USB rámečku jsou líné. USB 2.0 reálně představuje úzké hrdlo třeba 40-50 MBps sekvenčně. Vaše 3.5" 2TB Barracuda by měla dávat řádově něco kolem 200 MBps, jestli mi šedá kůra správně slouží (pokud ne 300 MBps - už vážně nevím). Dlouhá léta dávaly disky něco kolem 100 MBps. Pokud byste měl rámeček s USB 3.0, tak patrně nezjistíte rozdíl mezi externím rámečkem a onboard SATA.

Mimochodem, má ten Váš rámeček nějaký ventilátor? Pokud ženete 3.5" disk této kategorie několik hodin v kuse bez chlazení, tak se nedivím, že se mu třeba neudělá dobře. Pravda je, že ve Vašem výpisu SMART vidím okamžitou teplotu 48*C, maximum 55. Běžně disky při těchto teplotách neprovozuji, takže Vám neporadím, zda je to OK nebo už na pováženou. Ptám se proto, že vím, že prakticky žádný externí rámeček nemá ventilátor. Na svůj soukromý rámeček jsem si ventilátor sám přidělal, takže můj externí disk má za provozu něco kolem 30*C.

Protože externí USB rámečky neprodávám a neservisuju, tak Vám bohužel neposloužím statistikou, která chyba je "statisticky nejčastější". Mohu ale velmi doporučit systematický postup = problém "izolovat" metodickými záměnami A/B jednotlivých součástek, na které ten krám lze dekomponovat. Pokud je to vada kusu, tak se Vám bude stěhovat.

A chválím nápad, vyndat disk z rámečku a zkusit ho otestovat taky na přímém propoji SATA rovnou do motherboardu, napájený PS/2 ATX zdrojem. Natočte pár průchodů hddtestem. Pokud se nevyskytne chyba, (zatímco v externím USB kastlíku ano,) tak už budete vědět, že diskem to není.

On je obecně dobrý nápad, na začátku postupu hledání problému řetězec "maximálně zkrátit" = zkusit problém reprodukovat v minimalistické konfiguraci. A pokud se neprojeví, tak postupovat "signálovým řetězcem" plné konfigurace buď sekvenčně, nebo půlením intervalu, nebo jak se Vám zrovna chce (třeba podle pracnosti záměn A/B na různých rozhraních).

Jinak pokud hddtest a podobné tooly v režimu "pouze čtení" jedou bezchybně, tak to ještě neznamená, že disk je zdravý. Viděl jsem disky, které běžely týden bez chyby s čistým čtením, ale při zápisovém testu (= přepíše data na disku) padl disk na ústa téměř okamžitě :-/

Kromě toho je v hddtestu nebo iostatu hezky vidět, jak kolísá okamžitá sekvenční rychlost - a pokud sekvenční čtení nejede jak podle pravítka, je to taky indikace, že má disk problém, přestože se k němu třeba ve SMARTu zatím moc nepřiznal. Obvykle se později v testu začnou sypat vadné sektory.

Heh taky jsem viděl disky (WD Raptor/Velociraptor?) které při čtení už zadrhávaly nebo timeoutovaly, tak jsem zkusil zápisový test (přepsat celou plochu nulami) což proběhlo, a po tomto zápisovém testu se disk začal chovat zcela zdravě i při čtení :-) ale vydrželo mu to třeba dva týdny a pak se začal zase sypat i při čtení...

593
Sítě / Re:ipv6 u o2 - pristup zvenku
« kdy: 26. 01. 2021, 18:51:50 »
Hlavně by se hodilo, mít na pozici "hraničního L3 hopu" nějaký box, na kterém lze spustit tcpdump. Za mně OpenWRT, už si nepamatuju jestli taky Mikrotik tohle umí. Nebo pasivní odposlech na L2 (resp. aspoň mirror port na switchi).

BTW na nesíťaře jste ten dotaz zformuloval moc pěkně :-)

594
Vývoj / Re:Práce s vlákny v C
« kdy: 26. 01. 2021, 13:31:55 »
Klasické synchronizační vzory jsou výborně popsány ve free knize Little Book of Semaphores: https://greenteapress.com/wp/semaphores/ . Vždy jsem tam našel co jsem potřeboval.

Musím uznat, že to je vypadá jako milá knížečka :-) Se svými 300 stránkami není úplně maličká, ale tím líp. A dokonce tam kolem vidím pár dalších spisků téhož autora, na potenciálně zajímavá témata, všechny volně k dispozici... to zas bude mít rodina zlost, že si furt jenom čtu :-/
Díky :-)

595
Vývoj / Re:Práce s vlákny v C
« kdy: 26. 01. 2021, 10:33:20 »
Osobně jsem se základy práce s mutexy a podmínkovými proměnnými dočetl v tomto starodávném článku. Ten článek sice vyšel dávno před přechodem libpthread v Linuxu na NPTL, takže některé poznámky o interně používaných signálech apod. už neplatí - ale základní "o čem to je" platí myslím dál.

Ještě jsem si vzpomněl, že jsem možná první zmínku o libpthread a vláknech četl v papírovém vydání "Linux - začínáme programovat", někdy v roce 2000. A jak jsem při následném online studiu užasl, že v té knížce úplně vynechali podmínkové proměnné (conditional variables). A teď vidím online 4.vydání v PDF, a v kapitole 12 dodnes není ani zmínka o podmínkových proměnných :-) Ostuda. Listuju v papírové knížce a našel jsem jako záložku svůj papír, kde jsem si průchod dvou vláken "synchronizací s podmínkovou proměnnou" načmáral :-) A vytištěnou stránku z Linux Standards Base reference, která obsahuje seznam funkcí libpthread.

596
Sítě / Re:Síťovka blokuje port - může?
« kdy: 26. 01. 2021, 09:40:21 »
To je celé AMT. Krade pakety na síťovce integrované v south bridgi "postranním kanálem" (sideband). Když si člověk nedejbože usmyslí, že to využije pro remote údržbu, tak to často nefunguje, zejména u neznačkových výrobců motherboardů - ale škodit, to by mu šlo. Vrtá mi hlavou, nakolik je to reálně použitelné jako backdoor pro třípísmenkové agentury, jak se obecně traduje. Mám podezření, že je v tom tolik bugů a principielních omezení, že je to stejně nejspíš k ničemu i v tomto ohledu :-(  Nastavit chudáka první onboard síťovku, aby kradla pakety, to je na celém "lights out managementu" ta nejjednodušší část. Naštěstí se zrovna tohle žádných jiných síťovek *netýká*.
Ghehehe žeby to Intel kamarádům z donucení vytvořil a zároveň naschvál švejkoval údržbu? :-D

597
Software / Re:Chyba disku vs. chyba souborového systému
« kdy: 26. 01. 2021, 09:17:46 »
Přidám své názory k již prezentovaným = budu souhlasit s některými výroky, které tu padly.

"Raw read error rate" je vždycky hausnumero a obvykle ho zcela ignorujeme. Jo a děkuju @ByCzech za vysvětlivku :-) Zkusím to občas použít.

Pokud SMART obsahuje nenulové hodnoty "reallocated sector count", je vhodné zpozornět.

Nenulové hodnoty "offline uncorrectable" znamenají vadu, takovému disku už nevěřit.

Pokud je SMART zcela čistý, tak to ještě není stoprocentní záruka, že je disk jako celek zdravý, může mít nějaký vakl v elektronice, který se ve SMARTu neprojeví, nebo jsem zažil disky, které bez problému četly, ale při zápisu okamžitý zátuh (každopádně už disk nebyl schopen si zapsat chybu do SMART sektoru) apod.

Ctěnému publiku dále velmi doporučuji error log, kterým končí výpis "smartctl -a". Je tam vidět celkový počet chyb, a posledních pět je rozepsaných hezky podrobně. Tento log bývá obecně velmi užitečný.

No a v našem případě, konkrétně hláška UNC... tipnu si, že obecně znamená "uncorrected", tzn. nedalo se přečíst z plotny. Ale zde bych upřesnil: všimněte si LBA adresy 0x0FFFFFFF . Toto je velmi charakteristické kulaté číslo. Dle ATA standardů je tato adresa již neplatná v ATA LBA28 (viz inline funkce lba_28_ok() ), je třeba se na ni dotázat přes ATA LBA48. Toto vypadá na bug v kernelu - žil jsem v domnění, že byl odstraněn někdy relativně brzo v řadě 2.6. Budu se opakovat, "starej ale dobrej" - fakt bych nečekal, že ho ještě dneska potkám, po tolika letech. Pokud se k disku přistupuje skrz USB Mass Storage, tak nemohu vyloučit, že za tu chybu může firmware USB/SATA převodníku (který generuje ATA LBA28 transakce). Pokud je do toho nějakým způsobem zapletena translace SAT tak si nejsem jistý, kde přesně hledat - jestli v USB/SATA převodníku, nebo v kernelu...

Je jistě otázkou, zda za narušené NTFS může konkrétně "mina na LBA adrese 0x0FFFFFFF" (desítkově 268435455).

Hypotéza o špatném zdroji - obecně jistě stojí za prověření. Chce to ale vědět poměrně dost podrobností: jak silný zdroj, jak starý, nejlíp se mu podívat na zoubek skopem... pokud není skop, ale chyby se projevují reprodukovatelně, tak třeba aspoň zkusit spekulativně vyměnit zdroj za nějaký "nezpochybnitelně kvalitní", zda závada zmizí. A možná lze řešit kondíky apod. Zdroje jsou samostatná kapitola. Radši to nechám na jindy :-)

BTW, chcete-li prověřit, zda Váš linux o tu adresu 0x0FFFFFFF zakopne, zkuste třeba něco jako
dd if=/dev/sda of=/dev/null bs=512 count=10 skip=268435450

Nebo zkuste můj hddtest (před pár týdny jsem konečně opravil dávný bug se staticky alokovaným bufferem o pevné velikosti, který způsoboval pády při příliš širokém okně terminálu).

598
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 23:57:20 »
Osobně jsem se základy práce s mutexy a podmínkovými proměnnými dočetl v tomto starodávném článku. Ten článek sice vyšel dávno před přechodem libpthread v Linuxu na NPTL, takže některé poznámky o interně používaných signálech apod. už neplatí - ale základní "o čem to je" platí myslím dál. Hrál jsem si s tou synchronizací v C a základním C++ postupně víc a víc, až jsem v jednom proprietárním prográmku měl asi 7 různých tříd objektů (které cosi obalovaly), každý měl svá 1-4 vlákna, mezi sebou si předávaly "práci" a pochopitelně se přitom všelijak zamykaly... jako houfec baletek. Fronta nebo obecně nějaká hromádka krmení, ochráněná podmínkovou proměnnou, je mocná zbraň :-) Není vůbec na škodu, myslet trochu "mimo předdefinované škatulky", a ze shůry daných základních synchronizačních primitiv si stavět složitější konstrukce na míru svému problému. Třeba více producentů pro jednoho konzumenta... podmínkovou proměnnou lze chránit prostou frontu, nebo třeba nějaký složitý key-value index s multikriteriální porovnávací funkcí... Jednalo se tehdy o nějakou komunikační gateway mezi více rozhraními, a dalo se to celé rozdrobit na datové objekty držené v indexech, které na sebe navzájem odkazovaly, kolem každého objektu tančilo několik vláken... jedním ze základních návrhových principů bylo, že každé vlákno smí delší dobu (až na neurčito) blokovat právě v jednom bodě, aby se zabránilo nepříjemnostem typu zbytečné vzájemné čekání nebo dokonce uváznutí. Tím jediným bodem mohla být podmínková proměnná (vlákno = konzument) nebo třeba čekání na vstup (událost) od fyzického I/O zařízení... Všimněte si, že při čekání na podmínkové proměnné je související mutex *odemčený*. Držet mutex dlouhodobě zamčený je hřích - přípustný pouze v případě, že to fakt nejde udělat rychleji nebo odložit na dobu, kdy zámek není potřeba (třeba když je zámkem chráněna manipulace s nějakým btree asociativním polem / indexem, byť u rozsáhlejšího btree může být třeba rebalancing procesorově a časově náročný).

BTW
Když si vezmete že jeden thread lockne resource, do toho mu kernel sebere kvantum, tak bude případný další thread viset než ho ten přerušený znova uvolní. Pro to co píšete to je jedno (desetiny sekundy za uherskej rok u příkladu na naučení se). Ale do budoucna je dobré mít pro lock/unlock makra a pak to časem udělat dobře (futexy pro linux, něco přenositelnějšího i jinam)

Možná tomu špatně rozumím, ale zrovna v tomhle případě mě držený zámek neuráží :-) Pokud má konkrétní vlákno zrovna práci na nějakém zamčeném "vzácném zdroji", třeba se delší dobu hrabe v nějakém indexu, a přeruší ho preemptivně scheduler, tak to vlákno prostě zůstane ve stavu "running". A pokud nějaká další vlákna trpělivě čekají na tentýž zámek, tak holt čekají dál a zcela po právu / smysluplně. Z pohledu scheduleru tato další vlákna "z vlastní vůle spí". Takže scheduler půjčí procesor na chvilku nějakému jinému procesu, který by také rád běžel. Halt zas chvilku někdo jiný tahá pilku. Nebo pokud se nikdo jiný o procesor nehlásí, dostane ho obratem zpátky naše původní vlákno, které se chce ještě chvilku hrabat v tom svém indexu - vlákno dostane procesor zpátky, protože je z pohledu scheduleru "running". Prostě: které vlákno má práci, a indikuje toto scheduleru, má šanci procesor dostat zpátky - a vlákna spící na podmínkových proměnných patrně spí dál zcela oprávněně, a při správném rozvržení dat a vláken je to jako celek dost slušně efektivní.

Mám na tuhle dobu a programátorské problémy hezké vzpomínky. Jak shluknout v kódu objekt (struct) a k němu náležející vlákna. Jak nastartovat vlákno a "memberizovat" ho, aby běželo jako metoda konkrétního objektu. Jak do toho objektu (třídy/structu) zakomponovat podmínkovou proměnnou a mutex, které si "vlastní" vlákna objektu budou zdvořile předávat. Jak to zamykání zabalit do "manipulačních" metod, aby další kód volající tyto metody nemusel řešit pthread primitiva. Jak z různých tříd takových "rozvlákněných objektů" skládat hierarchie / mesh topologie, a zároveň zajistit "graceful cleanup" při ukončení jednotlivého vlákna, případně kaskádovitý úklid vláken a objektů při ukončení programu... Nabízí se, zapojit do hry reference counting = osobně jsem přidával do "užitečných" objektů šablonový "invazivní" reference counting objekt, který tuším navíc obsahoval zámeček... aby ten reference counting fungoval z více vláken, a aby fungovalo "poslední zhasne" = po dekrementaci ref.counteru na nulu se objekt dále prostřednictvím zmíněného invazivního reference counteru sám destruuje... jde pouze o to zařídit, aby po dealokaci paměti
dobíhající member metoda už nesáhla do dat nyní již neexistujícího objektu :-) = dealokace dělat až těsně před návratem.

Podobně zábavné situace "slepice nebo vejce" nastávají při graceful shutdownu a řízenému zastavení všech vláken hlavní smyčkou programu, kterou přerušil signal handler apod. Resp. zařídit, aby došlo ke graceful shutdownu jak při zastavení vnějším povelem, tak při zastavení spontánním (vlákno zjistí chybu a proto se samo ukončí, případně to napřed nějak nahlásí).

Řekl bych, že tahle práce "bolí, ale hezky" :-) Ladit ty vejce a slepice je někdy záhul na mozkovnu. Ale je super, když to po vyladění celé chodí jak hodiny. A naopak není vůbec super, když to napíšete a odladíte na nějakém stroji/procesoru, pak to spustíte na jiném s troji s jiným počtem jader apod., a ono to začne padat, protože se změní "charakter konkurentního běhu více vláken" v těsném okolí zamykaných kritických sekcí :-) Je to *hodně* náročné na předvídavost a pečlivost při psaní kódu. A je to potenciálně veliká zábava.

599
Distribuce / Re:Linux distribúcia pre začiatočníka
« kdy: 25. 01. 2021, 17:34:58 »
Ten ATOM není úplně ztracenej. Jedná se o čtyřjádrový BayTrail, tzn. je to z první generace ATOMů, kterou osobně nepovažuji za hroznou (cokoli předtím bylo vážně slabé). Má to 4 out-of-order jádra bez HT, dohromady 2 MB L2 cache. Pravda ty hodiny jsou dost nízko - což je daň za miniaturní spotřebu. Taky grafika je podle všeho už Intelova vlastní, žádná PowerVR hrůza = úplně to netrhá kostky, ale mělo by to být bez problému funkční s open-source ovladačem.

2 GB RAM - a na tom běžely desítky? Předpokládal bych, že samotej OS sotva dejchal, nemohl tam být antivirus ani Windows Update...

V Linuxu rezidentní antivirák ani rezidentní updaty nepotřebujete. A pokud chcete řešit updaty, tak fungujou zcela nenáročně a nenásilně. Skromné distro potřebuje pro svůj základní rozběh pár desítek až stovek MB RAM.

Souhlasím s doporučením "něco s XFCE". Konkrétně osobně tíhnu momentálně k Debianu s XFCE, ale je možné, že Xubuntu bude lépe odladěné a Mint/XFCE by mohl být vyloženě přítulný. Osobně nemám rád Ubuntu s prostředím Unity, ale to je subjektivní volba.

S těmi 2 GB to nebude úplně růžová zahrada (nešly by upgradovat?) ale řádově 1 - 1.5 GB RAMky pro aplikace Vám tam zbyde, takže dnešní browsery v tom půjdou používat, pokud jim moc nenaložíte (hodně tabů a složité weby).

Jestli "skočit do vody a plavat"... asi ne úplně bez rozmyslu, ale už Váš dotaz na tomto fóru znamená, že jste dostal pár dobrých rad do začátku, a jste v rámci možností v dobrých rukou. A dokud do té vody nestrčíte palec, plavat se nenaučíte. Tak se nebojte - hlavně pokud na tom počítači nemáte nějaká cenná data a nechcete řešit dual-boot, tak se nebojte klidně začít párkrát znovu, pokud by se něco na první pokus při instalaci zadrhlo (což nepředpokládám). Mám například pocit, že dnešní distra po Vás asi při instalaci už ani nechtějí, abyste věnoval pozornost rozdělení a mountování disku.  Pokud máte nějaká data, o která nechcete přijít, tak samozřejmě předem zálohovat, lépe dvojmo.

Pokud byste to chtěl pojmout jako studijní záležitost, sežeňte si nějaké tutorialy. Podotýkám - může to být hodně čtení a teoretické znalosti nejsou zdaleka podmínkou, abyste si zkusil Linux osahat.
Napadají mě dva dotazy do Googlu - hlavně se proboha neděste, nejhorší smrt je z vyděšení, to čtení není zdaleka povinné a když už něco čtete, ignorujte věci, kterým v té chvíli nerozumíte:
https://www.google.com/search?q=Linux+disk+partitioning+howto
https://www.google.com/search?q=Linux+system+boot+sequence
Dostanete chumel odkazů různého data publikace, a v obou výše uvedených oblastech se toho za posledních 20 let stalo docela dost, takže najdete mnohá zastaralá doporučení... je to vážně jenom čtení před usnutím, pokud byste měl zájem. Kdyžtak se ptejte dál. Ozvěte se, až budete mít funkční linux. Třeba by Vás mohlo zajímat, jak se začít nesměle rozhlížet pod kapotou... ne? Tak ne :-) I to je legitimní uživatelský přístup.

600
@IDontCare : hezky. Děkuju.

Stran: 1 ... 38 39 [40] 41 42 ... 84