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] 2 3 ... 89
1
Studium a uplatnění / Re:Osmileté gymnázium v Praze
« kdy: 23. 02. 2024, 10:19:49 »
Z tohoto jsem dneska zaslechl v rádiu asi pětiminutový útržek, vložený do zpráv (asi upoutávka):
https://plus.rozhlas.cz/prijimaci-zkousky-jsou-samoucelne-deti-se-kvuli-nim-uci-nesmysly-upozornuje-9178807
Asi mám fakt kliku, že se moje děcka nebála osmiletého gymnázia, a že se dostala bez velkého doučovacího masochismu.

Příště se uvidíme u přijímaček na vejšku. Aneb Husákův periodický populační boom a jeho ozvěny ve vzdělávacím systému, modelovány gradientem živelné urbanizace a exogenního imigračního tlaku...

A nakonec se uvidí, čím se děcka budou jednou doopravdy živit. Makat trochu rukama si už obě vyzkoušely...

2
Odkladiště / Re:Helpdesk operátor
« kdy: 14. 02. 2024, 17:07:20 »
Pokud nemáš řešení v hlavě, tak holt se budeš muset proběhnout a ověřit to osobně. Bohužel pořád ti budou hlásit někdy voloviny, logicky ne každý všemu rozumí.

Poměrně rychle ale získáš určité typy odpovědí a řešení, často ti stejný problém reportuje více lidí. Když nevíš, určitě ti někdo pomůže.

Jojo. Pokud má člověk dělat support na témata, která nemá v malíčku, měl by zkusit trochu aktivně potrénovat, ve vlastním zájmu. Třeba na specifický software máte být proškolena zaměstnavatelem, pokud to nebylo u přijímacího řízení jako "vyžadovaný předpoklad".

Pokud je to v rámci areálu, je pohyb po place užitečná taktika. Poznáte lidi a prostředí, zjistíte co se ve firmě vyskytuje za počítače, kde mají jaké kontrolky (nebo spíš nemají) atd. Taky to prospívá tělesné kondici - není nic horšího, než jenom sedět na židli.

Na problémy typu "vono to nefunguje" a "nemůžu se přihlásit" - pokud se to týká síťových služeb, tak bývá možnost, podívat se na serveru do nějakých logů. Tam Vás jako nováčka musí někdo pustit / zaškolit, a možná to nebude hned po nástupu = čím častěji budete tohle eskalovat, tím dřív se Vám dostane nějakého zasvěcení od správců, kteří chtějí mít taky svůj klid, že :-)

Hardwarové závady se vyskytují. V monitorech, v počítačích, v Ethernetu. Pokud Vás tahle práce neodradí, časem si vypěstujete postupy hledání chyb a řekněme i nějakou "intuici", ačkoli na tu se moc spoléhat nedá. Základní postup je: krabice A nefunguje? A co když připojíme krabici B, ta bude fungovat? Ne? Máme v zásuvce napájení? Co Ethernet, odkud kam ten kabel vlastně vede? Není vada v patchcordu, nebo v trase? Doběhnete s noťasem ke switchi, zkusíte to do switche rovnou... atd. Velice záleží na detailech prostředí - jak moc máte LANku "bezpečnostně ošetřenou" apod. K tomu byste jako helpdesk měla mít nějaké počáteční podklady / školení.

Elektru a počítačům a síťovinám lze rozumět do různě velké hloubky - zásadní znalosti ale po Vás jako nováčkovi nemůže nikdo spravedlivě požadovat.

Pokud jste fakt jenom na telefonu, a nemůžete se dojít podívat, co se děje na druhém konci, tak je to trochu smutná situace. Čistě na telefonu neporadí sebevětší profík, pokud je tazatel na druhém konci drátu nepoužitelný :-/

3
Neporadím s moderními programovacími prostředími. Mám jenom pár keců v kleci:

Připomíná mi to dobu, kdy databázové aplikace bylo možno provozovat lokálně, s občasným přístupem na centrálu - na požádání se vytočil dial-up a synchronizovala se data tam a zpátky. Říkalo se těmto postupům tuším "disconnected operations" - pobočky měly značnou míru autonomie a data s centrálou si vyměňovaly "líně a pozvolna". Pobočka mívala v zásadě počítač nebo malý server a na něm svoji instanci dbms. (Asi nechci navrhovat, aby na telefonu běžela instance RDBMS :-)

Nápady z tohoto soudku (replikace a tak) tvořily taky část oboru zvaného "distribuované databáze".

Zkuste si schválně ty dva pojmy zagooglit, třeba se dočtete něco relevantního - jak postavit datový model, aby to celé samotížně zaklaplo dohromady apod. Odhadem máte výhodu, že Váš datový model je jednoduchý = nebude tam složitá referenční integrita, snad ani potenciál ke konfliktům mezi offline lokalitami apod.

Pokud něco googlem najdete, připravte se, že to bude značně řídké čtení. Spousta akademického textu a sem tam dobrý nápad.

Pokud Vaše zadání obsahuje možnost, že při nějakém plánování času apod. bude mezi účastníky docházet ke konfliktům, tak tam teprve začíná zajímavá činnost = jak řešit případné věcné konflikty. Jednak na úrovni uložení dat, druhak nad tím na úrovni aplikační logiky.

4
Pokud je zaseklý grafický desktop, případně z nějakého důvodu celé grafické prostředí, tak mě napadá, že Windows 10 údajně obsahují jako volitelnou komponentu OpenSSH service. Prostě remote příkazový řádek přes SSH, tentokrát ovšem oficiální. Odtamtud se dají spouštět věci jako tasklist -V, taskkill, jako náhradu správce úloh doporučuji ntop. Hehe to by mě zajímalo, jak tohle funguje v kontextu Windowsích "desktopových uživatelských relací" :-) Jenom jsem to rychle zagooglil, prakticky jsem openssh service zatím netestoval / nemám potřebu.

5
Velmi matně si pamatuju, že v dávných dobách snad existovaly "ladící" karty do PCI, které pomocí bus masteringu dokázaly sáhnout kamkoli do hostitelovy DRAM, tzn. také udělat kompletní obraz RAM zaseklého počítače, pokud byl do té míry funkční.

Nejsem si jistý, zda přístup z PCI do adresního prostoru hostitelova procesoru (resp. fyzické DRAM) podléhá nějakým omezením, a jakým. Vím že PCI host bridge (a další bridge za ním) filtrují/dekódují přístup z hostitele do MMIO oken periferií - ale opačným způsobem... nevím. Je možné, že se toto v průběhu desítek let vývoje PCI nějak vyvíjelo, předpokládal bych směrem k utužení bezpečnosti. Určitě do toho má co mluvit IOMMU v případě mapování PCI(e) zařízení guestům, ale nejsem si jistý, zda v defaultní konfiguraci prostě pustí BM transakce ze strany PCI sběrnice kamkoli do RAMky fyzického hostitele.

A pokud se k obrazu RAMky dostanete, k nápadu "něco z toho zjistit" se tu vyjádřili ostatní. Kdyby aspoň ten obraz byl "plochý", ale ony user-space aplikace dostanou fyzickou RAMku přidělenou několikapatrovým překladem adres stránkovacího mechanismu, a pak nad tím přídělem ještě běží nějaký alokátor... Takže najít a parsovat kernelové page allocation tables, a nad tím alokátor příslušné "runtime knihovny" dané aplikace... a pak se snad dostanete k nějakým datům.

Zkusil bych tomu stroji dát kouř Memtest86+. Přes noc, nebo pár dnů v kuse.
Pokud PC tohle ustojí, tak to pořád není garance, že tam není nějaký další bug. Třeba pokud je načatá grafika, tak zatuhlý grafický ovladač asi dokáže systému taky solidně zamotat hlavu.
Čerstvá verze memtestu je koukám sedmička (hledejte string "latest version"), já tuším jedu ještě na 6.20 - viz archiv, pokud nemáte rád kulaté verze.

6
Studium a uplatnění / Re:Osmileté gymnázium v Praze
« kdy: 04. 02. 2024, 13:37:16 »
Pak nám na třídní schůzce říkali, že je rozdíl mezi těmi co studují na osmiletém a čtyřletém gymplu. To co přišli z devítky byli zvyklí, že na ZŠ dostávali jedničky a na gymplu je chtějí taky. Osmileťáci už na gymplu jsou a maturita je daleko, tak takovou motivaci mnohdy nemají.

Ehh... na našem gymplu je rozdíl následující: osmiletého je jenom jedna třída v ročníku, kdežto čtyřleté jsou další asi tři. U přijímaček na osmiletý je veliký přetlak zájmu, snad 1:9. Na čtyřletém je ten poměr mnohem měkčí. Potažmo osmileťáci jsou výrazně víc "vyzobaní z populace" - učitelé si je chválí, a údajně je to znát i ve srovnání "v rámci stejného ročníku".
Co slýchám nesystematické vyprávěnky (jedna paní povídala), tak placené "doučování na přijímačky" nezbytně úplně nekoreluje s tím, co dítě ve finále předvede u přijímaček. To je snad jediná věc, co na přijímačkách není fér: genetická loterie.
Ještě jedna věc: u nás ve městě jsou gymply dva, a jednotné přijímačky se dělají na každém zvlášť = pokud si děcko podá přihlášky na oba gymply, jde na dvoje přijímačky ve dvou termínech - ale následně se bere v úvahu na obou školách lepší z obou výsledků. Takže se částečně eliminuje riziko náhodné indispozice  / jednotlivých chyb z roztržitosti, nepochopení apod.
Děcka jsou na jednu stranu s gustem pyšná na svůj ústav a trochu strouhají mrkvičku těm "od konkurence" - přitom pokud mohu soudit, obě školy jsou fajn. A město není velké, děcka se navzájem znají, chodí spolu na kroužky a nějaká knoflíková válka se nekoná.

7
Hardware / Re:Výběr Wi-Fi modulu s dobrým dosahem
« kdy: 02. 02. 2024, 23:53:05 »
Formát MiniPCI-e je z pohledu inovací uzavřená kapitola. Nové čipy (Wifi 6 / 802.11ax) jsou převážně na kartách ve formátu M.2.
Do nekolika Thinkpadu sem daval mPCIe s AX200 a AX210, maj v sobe i BT 5.x...
Oho! Díky za tip, bude se hodit... No ne, ona je to originál intelka :-) To je hezké, že Intel takhle myslí na nás zpátečníky... (mluvím o sobě)

8
Server / Re:Levné hostování velkého množství dat
« kdy: 02. 02. 2024, 15:36:37 »
Před lety jsem zaslechl debaty toho typu, že některé "subjekty připojené k internetu" (AS) měly velký počet drobných domácích klientů = mocný download, ale skoro žádný upload. A naopak existovaly firmy provozující hosting/housing, které měly veliký upload, ale skoro žádný download. A různě se organizačně spolčovaly a "expandovaly služby" a přeprodávaly konektivitu, aby si ten nepoměr up/down vyrovnaly. Těžko říct, zda je v dnešní době nějaký altruista s hejnem drobných retailových sosačů, který má zbytečných pár gigabitů v uploadu (a byl by ochoten se o ně za drobný peníz podělit).

Hm... na suverénní členství v NIXu to asi nebude :-)

9
Hardware / Re:Výběr Wi-Fi modulu s dobrým dosahem
« kdy: 02. 02. 2024, 15:28:32 »
@dj-bobr ad externí wifi: bejvalo AirLive X-USB s dvěma RPSMA :-) tuším 2.4/5 GHz, čip Ath6k, 802.11n. Ale to už se nedělá, a zřejmě pro to nejsou ani rozumné drivery do moderních Windows. (V Linuxu myslím od přírody.) Nebo koupit levný USB wifi dongle dle momentálního rozmaru, lousknout plastové pouzdro a zkusit uvnitř najít místo, kde škrábnout spoj a připojit si vlastní anténu. Jako cestovat se subnotebookem a mít k tomu na stojánku třeba anténu z plechovky od párků, to by byla jistě známka punku :-) Jinak Google ukazuje i nějaké aktuální dongly s relativně dlouhým proutkem...

10
Hardware / Re:Výběr Wi-Fi modulu s dobrým dosahem
« kdy: 02. 02. 2024, 13:28:16 »
Formát MiniPCI-e je z pohledu inovací uzavřená kapitola. Nové čipy (Wifi 6 / 802.11ax) jsou převážně na kartách ve formátu M.2.

Pokud se týče half-size MiniPCI-e, pamatuju si karty AzureWave s čipem Realtek RTL8821AE - dual-band AC. Bohužel tuším reálně jenom jeden RX/TX chain. Dva anténní porty fungují v režimu diverzity nebo co. Ale pravda je, že pokud jde o dosah / jakost, tak Vám třeba nejde o průchodnost (moje řeč - on přínos MIMO resp. dvou antén je IMO trochu sporný). Zrovna vidím jednu na Aukru. Budou Vám pasovat konektory.

Otázkou je ale anténní systém. Pokud má noťas z výroby rádio, které je B/G/N = 2.4 GHz only, tak antény v noťasu nejspíš na 5 GHz nebudou nic moc. Spíš nic než moc. A měnit v noťasu single-band anténu za dual-band... no nevím :-) Dodnes jsem moc nezkoumal, co se případně dá koupit nebo ubastlit, protože by mě to vcelku ani nenapadlo. Anténa v noťasu je custom design pro dané šasi. Jako dají se koupit miniaturní anténky, často jako obrazec na kusu kuprexitu nebo jako součástka do plošáku, ale pak je ještě otázka, z čeho je víko noťasu, jak by anténa spolu-účinkovala s kovovým rámečkem displeje uvnitř víka apod.
A trochu dumám, zda má smysl řešit anténu na 5 GHz, když delší dosah máte stejně na 2.4 GHz, a free APčka stejně bývají dostupné především v pásmu 2.4 GHz.

Jak už psal ".", vysílané výkony jsou omezené normou, tuším 100 mW. Rádia si výkon upravují dynamicky, ale pokud bojujete s dosahem / sílou signálu, tak nejspíš AP i klient vysílají maximum co smí. A pár decibelů sem nebo tam prakticky není znát na kvalitě spojení.

Pokud se bavíme o starém notebooku: koaxy k anténám vedou obvykle skrz panty a po letech otvírání a zavírání se ukývou. Výsledkem je mizerná síla signálu a dosah. Pokud máte srovnání s jiným zařízením, a vnímáte, že ten noťas má wifinu "tupou jako kopyto", tak bych se mračil především na průchod koaxů skrz panty. Nevím, zda dokážete koupit hotové patchcordy/pigtaily pro Váš noťas. Případně by se asi daly z něčeho přizpůsobit. Bohužel koaxy v noťasech jsou hodně tenoučké a relativně dlouhé. Konektor proti WiFi kartě se jmenuje U.FL a podle mého nemáte šanci si ho sám nakrimpovat na koax - je to strašně titěrné a chce to správný vercajk. Pokud byste dokázal koupit hotové pigtaily k wifi nebo LTE kartám (MiniPCI-e) o potřebné délce (podle mého 25 cm bude málo), můžete si posloužit - ustříhnete patrně SMA na opačném konci, oholíte střižený konec a přiletujete na původní anténu (praporek z kousku plechu, nebo cihlička na malém plošáku). Pozor, pigtaily pro M.2 mají jiný konektor, ještě titěrnější, jmenuje se MHF4 - ten je Vám k MiniPCI-e k ničemu.

https://www.soselectronic.com/en/products/2j/c485gst-030mc113-ufl-323388
https://www.soselectronic.com/en/products/2j/c485g-050-113-ufl-226295
https://www.soselectronic.com/en/products/2j/c485g-075-113-u-fl-321435

https://www.soselectronic.com/en/products/2j/2jf0102p-010-137-ufl-2jf0102p-010-113-ufl-306170
https://www.soselectronic.com/en/products/2j/2jf0102-015-113-ufl-216708
https://www.soselectronic.com/en/products/2j/2je07e-216707
https://www.soselectronic.com/en/products/2j/2je07d-216706

11
Distribuce / Re:Distro na starý šrotonotebook
« kdy: 14. 01. 2024, 21:42:09 »
Skylake není nijak hrozná vykopávka. Procesor byl uveden na podzim 2015, tzn. noťas bude z roku 2016 nebo mladší.
Škoda že nemá dva SODIMM sloty, takže RAMka nemůže jet v prokládaném režimu.
Pokud je paměť typu DDR4 (což bych předpokládal) tak jí procík zvládne až 32 GB, tzn. jednotlivý modul 16 GB.
Jedná se o příjemně úsporný model ("U") proto to není na druhou stranu vyložený trhač asfaltu.
3.1 GHz turbo nezní úplně blbě, a čtyři vlákna jsou lepší než drátem do oka.
Moderní děcka jsou hrozně rozmazlená šesti/osmijádrovými Ryzeny :-)
Mimochodem pokud má nalítáno, vyčistil bych prach před chladičem (ve výfuku ventilátoru) a asi bych i přepastoval procesor (SoC) protože stará pasta většinou teplo spíš izoluje než vede. Možná se Vám procesor zázračně zrychlí.
Má hardwarovou akceleraci pro přehrávání videa až někam po H.265 HEVC a s nějakým omezením VP9. Jestli si to správně vykládám, specifickou podporu pro AV1 nemá.

Jo a jaké distro: osobně bych skoro řekl Debian 11 XFCE, ale větší pohodlí bude asi v nějakém Xubuntu.

12
Sítě / Re:Mesh Wi-Fi síť po domě
« kdy: 12. 01. 2024, 12:32:49 »
Mikrotik pro interní wifi jsem před cca 3 lety zavrhl proto, že s ním dlouhodobě zlobily jabka. Prostě dvě různé ne-kanonické implementace Wifi. Jabka nikdy neměly problém s OpenWRT a Ubiquiti (nevím zda to souvisí s tím, že Ubiquiti firmware býval/je? založený na OpenWRT).

Je možné, že v souvislosti s implementací WPA3 a dalších moderních fičur se ledy pohnuly, a už to třeba s jablečnými produkty proti Mikrotiku není tak zlé.

Pokud se týče 802.11r, tak už si údajně Mikrotik taky zametl před vlastní prahem.

13
Sítě / Re:Mesh Wi-Fi síť po domě
« kdy: 12. 01. 2024, 10:45:15 »
Ohledně "roamingu": nechám na Vašem zvážení, jak moc Vás ruší, když se klient občas přepne na jiné AP ve vlastní režii. Handshake mu může trvat nízké jednotky sekund. Pokud potřebujete koukat na YouTube a přitom běhat po domě, tak asi chápu, že je potřeba to řešit i na straně sítě. Nebo máte otevřené nějaké relace, které by mohly při neřízeném handoveru pod Windows popadat a vyvolá to rušivé efekty (SSH, RDP, DB, co já vím).

Rychlý hand-over podpořený sítí je řešen pomocí 802.11r. Obvykle je k tomu potřeba "kontrolér", kam se "sbíhají nitky" od jednotlivých AP (aby si klienta předaly bez opakování kompletního WPA handshaku) - ale viděl jsem i konfiguraci pro OpenWRT, kde se předkonfigurovaly nějaké klíče, křížem proti sobě mezi AP, aby se navzájem "znaly" - a kontrolér pak pro 802.11r nebyl potřeba.

Řešit proprietární samokonfigurační mechanismy z kategorie "mesh" = vzdát se své správcovské zodpovědnosti, na dvou APčkách, když navíc mám ke každému APčku kabel... není to hloupost?

14
Sítě / Re:Mesh Wi-Fi síť po domě
« kdy: 10. 01. 2024, 15:43:03 »
Hm... provozuju po baráku pár kusů UBNT uAP AC Lite a Mikrotik cAP AC - pod OpenWRT. Hezky ručně nastavené. Bohužel aktuální hardware s podporou 802.11ax ještě nemá podporu OpenWRT - vámi zmiňované U6-InWall, EAP655-Wall nebo třeba Mikrotik cAP AX (má dva Ethernety). Takže pokud něco z toho koupíte, tak ústup na OpenWRT zatím není možný...

15
Software / Re:řeší Linux afinitu procesů vs thread jinak?
« kdy: 10. 01. 2024, 15:11:29 »
https://stackoverflow.com/questions/58370707/what-is-the-thread-group-leader-name-in-the-proc-file-system
Ty cesty v procfs jsou popsány v prvním komentáři.

Kernel provozuje v zásadě vlákna / threads. "Aby se to nepletlo", tak klíčový kernelový objekt, který drží informaci o jednom konkrétním vlákně, např. má atribut thread_id, se jmenuje "struct task_struct" :-(
https://chengyihe.wordpress.com/2015/12/29/kernel-thread-and-thread-group/

User-space process pasuje na kernelovou "thread group", z toho jedno vlákno je "thread group leader" = jeho TID figuruje též jako PID za celou skupinu, jinak ale thread group leader nemá žádné výsadní postavení. Je to prostě první vlákno programu, kterým začalo provádění programu (procesu). Pokud mohu soudit, "thread group" nemá žádný svůj objekt (struct), který by se instancioval - pouze thread group leader ve svém "struct task_struct" obsahuje pointer
struct task_struct *group_leader;
...plus dva list-heady pro dětičky a sourozence.

Takhle to figuruje v kernelu. User space (libpthread resp. NPTL v rámci libc) nad tím pentlí nějaké svoje mírně odlišné názvosloví.

A závěrem kvízová otázka pro chtré hlavičky, jestli dávaly pozor: co je to "struct task_group" ? Inu není to objekt pro "thread group" nebo-li kernelový pohled na rozvlákněný proces. Je to struct pro "control group" = skupinu procesů, která patří přihlášené terminálové relaci...

Připadá to někomu srozumitelné? :-D

Ve starší linuxové implementaci phtreadů (linux-threads, v linuxu 2.4) volání getpid() vracelo v každém vlákně jiný PID, tzn. ID vlákna. Tentýž kód zkompilovaný pro Linux 2.6/NPTL vracel ve všech vláknech tentýž PID. Takže když jsem chtěl držet seznam vláken podle jejich vlastních ID, pídil jsem se, kde ho vezmu - a ejhle, během nějaké doby probublal do user-space hlavičkového souboru s kernelovými syscally nový syscall gettid(). Dále pthread_create() od téhož okamžiku už nevrací PID, ale pointer na struct... (toto se skrývá pod typedefem pthread_t).

viz též man getpid, man gettid

Stran: [1] 2 3 ... 89