Příspěvky

1

Hardware / Re:Kde koupit 10m HDMI kabel?

« kdy: 16. 01. 2025, 12:01:01 »

15/DDC mi přijde zapojené přes ten R13 (?), zatímco 13/CEC mi přijde volný (stejně jako v adaptérech DVI/HDMI, co jsem našel na netu).

Jo, je to tak. A CEC narozdíl od toho DDC, které se používá během hand shake, není tak zásadní.
Jak jsem psal předtím, v noci jsem se na fotku špatně podíval a z nějakého důvodu si myslel, že je to HDMI female a počítal ty piny z druhé strany. Brain fart

2

Hardware / Re:Kde koupit 10m HDMI kabel?

« kdy: 16. 01. 2025, 10:54:47 »

Pokud ty signály jedou každý na dostatečně vzdálených základních kmitočtech, tak to klidně můžeš poskládat na společné vodiče a na konci pásmovou propustí zase rozpajtlovat.
Analogie: nevšiml jsem si, že by VKV rozhlas využíval nějakou formu časového multiplexu jednotlivých stanic; ty snad jo?

Ideově tě chápu.. a jasně můžeš mít časový nebo frekvenční multiplex. DDC (v podstatě I2C) je mnohem níž než TMDS. Hlavně mě ten pin 15, když jsem na to v noci koukal, prvně přišel nezapojený. Teď jsem si uvědomil, že je to stranově obráceně, protože je to male konektor. Jak je to PCB na fotce vyndané z té plastové krabičky na TX části, tak je to jen posunuté - mea culpa
No jestli to opravdu komunikuje přes DDC a je to čistě pasivní, tak si nedovedu představit, že je to udělané jinak, než říkáš.
Každopádně ať už je to jakkoliv, tak mi nepřijde, že by tohle pasivní slučování, propusti, hrabání do těch diferenciálních páru mělo mít pozitivní dopad na kvalitu přenosu nebo pomohlo délce vedení (když už je to extender). Ale samozřejmě, jestli to ostatním v konkrétním zapojení funguje nebo dokonce pomohlo, tak to může znít jako vcelku zbytečná debata
Možná si to ze zvědavosti někdy taky koupím, třeba místo jednoho piva

3

Hardware / Re:Kde koupit 10m HDMI kabel?

« kdy: 16. 01. 2025, 00:49:49 »

Hezky pěkně Ali
Nikdy jsem nic takového zatím nepoužil, nebo aspoň o tom nevím. A koukám na to tedy jako puk

Musím se na někdy líp kouknout na tu fotku a zapojení HDMI konektoru.. ta základní věc, co mi vrtá hlavou je, že na plnou funkci prostě nevychází těch osm žil v UTP kabelu, pokud to je úplně pasivní a nic se tam nemuxuje, nepřekódovává.
Na obrázek jsou tam minimálně čtyři diferenciální páry (TMDS bar. složky a clock). Dobře, hot plug detekce se dá asi nafejkovat, ale pořád tam nejde třeba DDC, tzn. rozhodně se nepošle EDID a nemůže fungovat ani HDCP. Což tak i na první pohled vypadá, protože DDC používá piny 15, 16. Pin 16 se zdá nezapojený na tom TX modulu vlevo.
Možná u nějakého řetězce typu Blu-Ray přehrávač -> TV, kdy to např. posílá natvrdo jeden režim, sink si ním poradí a obejde se to bez hand-shake by to teoreticky mohlo fungovat..

Ale každopádně díky za foto i report, že vám to chodí. Jen pro zajímavost s jakými zařízeními to používáte?

4

Hardware / Re:Kde koupit 10m HDMI kabel?

« kdy: 15. 01. 2025, 11:56:01 »

V čem je vlastně CAT6 lepší než ten HDMI kabel? Obojí jede diferenčně přes kroucené páry.

Myslím, že se to bude dost lišit podle konkrétního HDMI kabelu, protože je taky více řekněme kategorií. Osobně jsem krom jednoho nefunkčního moc neviděl, co je uvnitř. Nicméně kamarád, který jich měl možnost "kuchat" větší množství a byl zvědavý, tak říkal, že se některé jsou udělané dost mizerně. Měl nějaké tenčí ohebné, kde jsou licny s malými průřezy, špatné nebo dokonce žádné kroucení těch TMDS diferenciálních párů. Ty lepší pak mají vcelku poctivě udělané kroucení - individuální stínění každého páru, lepší geometrii a jsou třeba i zkoušené pro vyšší verze HDMI 2.0, 2.1.
Tam bych si možná troufal tvrdit, že to bude čistě z hlediska přenosu lepší než běžný Cat6 nebo dokonce 6A kabel.
Což by i dávalo smysl, protože HDMI/DVI nepoužívá vícestavový PAM jako gigový nebo desetigigový metalický Ethernet, tak tam jsou při TMDS přenosu násobně vyšší frekvence. Takže Cat6 a 6A kabely jsou i specifikovány (max. útlum, přeslechy) na 250 resp. 500 MHz, což je výrazně míň než používá HDMI v těch vyšší režimech.

Takže jaktože to chodí, přestože dobré HDMI kabely by měly být spíš obecně lepší než běžné UTP? Pokud tu teď na chvíli pominu tu konzistenci a striktnější standardy u UTP kabelů, jak je zmíněno v předchozím příspěvku.
Já myslím, že klíčové bude to, co dělá elektronika v konkrétním extenderu.

Když si vzpomenu na první DVI/HDMI extendery třeba 20 let zpátky, tak ty používaly dva kabely (první pro dif. páry, druhý pro další signály) a víceméně to bez jakéhokoliv překódování jen elektricky přizpůsobovaly pro posílání po UTP/STP kabelech - silnější drivery pro charakteristickou impedanci toho vedení, ekvalizace útlumu, preemfáze, buffer na DDC. Měl jsem několik takovýchhle prvních Gefenů a bylo to peklo na zemi (což mohlo být samozřejmě i implementací, ale bylo to strašně náchylné na souběh s jiným vedením, nakonec jsem to musel všechno vyřadit a nahradit optikou). Pak podobných zařízení přibylo relativně hodně, kvůli dostupnosti hotových řešení např. od Ti.
https://www.ti.com/lit/ug/snlu016a/snlu016a.pdf

Další generace víceméně podobná koncepce, ale pouze po jednom kabelu, takže odhaduji, že první tři páry byly zas pro TMDS složky, na posledním tam musel být nějaký multiplex protože je to víc signálů (byť s nižší frekvencí) a navíc obousměrně.

No a pak (třeba 10 let zpátky) přišly extendery, které víceméně dekódovaly TMDS signál a převedly jej do vlastního streamu, co používá vícestavový PAM a rovnoměrně využívá všechny čtyři páry v tom UTP kabelu, plus samozřejmě řeší i ty zpětné kanály. Což podobně jako u Ethernetu umožní snížení šířky pásma a odolnější přenos přes UTP. Tohle je standardizované v HDBaseT, který je fajn i kvůli interoperabilitě mezi různými zařízeními (např. některé projektory to mají vestavěné). Nicméně je to licencované a má to pod palcem izraelská firma Valens Semi, která i vyrábí čipy. Což je pak i důvod, proč jsou všechny HDBaseT extendery i násobně dražší.
U těch OEM převážně čínských/taiwanských výrobců bych pak čekal, že používají podobný princip, ale vyhýbají se případným patentovaným věcem a mají to v proprietární formě.
Ale je to jen odhad, nikdy jsem nic v poslední době nerozebíral, neodlepoval chladiče, neměřil, nezkoumal..

Možná třeba RDa, který je odborník na podobný hardware, s tím má třeba víc zkušeností z nějakého návrhu. Nebo tomu zkoušel přijít na kloub.

5

Odkladiště / Re:Zálohování stále se měnících velkých dat

« kdy: 14. 01. 2025, 00:13:22 »

Samozřejmě banka (resp. jakýkoliv subjekt) má více kategorií dat a u každé by pak měla být odpovídající strategie zálohování - včetně RTO (kolik času trvá, než se to obnoví) a RPO (jak stará data ještě můžeš ztratit, aby tě to neohrozilo, např. prezentace z marketingu stačí ze zálohy jeden den zpátky, některá data potřebuješ z poslední hodiny, a jinde je to nula).
Tomu jak to má daný subjekt naplánované tak, aby případná havárie nebo útok neohrozila jeho fungování se obvykle říká BCP, Business Continuity Plan, kde by to mělo být vcelku detailně popsané co a jak dělat včetně třeba i školení obsluhy atp.

Na data v vysoce dostupných transakčních systémech v podstatě nelze použít nic jiného než nějakou formu synchronní replikace (tzn. transakce se nedokončí dokud to není zapsané ve dvou či více systémech) ideálně v součinnosti s CDP (continous data protection) - https://en.wikipedia.org/wiki/Continuous_data_protection kdy se ještě jinam ukládají data včetně kompletního logu všech operací/transakcí a s možností případného návratu zpět (což je nutné v případě nějaké logické chyby, smazání atp).

6

Windows a jiné systémy / Re:Zálohování z Windows na vzdálený linuxový server

« kdy: 13. 01. 2025, 14:51:02 »

Ano, těch možností je hromada, zvlášť když se započítají ještě komerční programy.

Rdiff-backup už zmínil M Z a je fajn.
Restic https://restic.net/ má Windows verzi a spousty možností. Například použití VSS (snapshoty filesystému před zálohováním, pro běžící programy). Do inicializovaného vzdáleného restic repozitáře se pak dá zálohovat víc různých cest nebo strojů. Data v repozitáři jsou šifrovaná, takže například není problém je následně zkopírovat pomocí rclone na nějakou další službu (i třeba veřejné cloudové úložiště typu One Drive, Google Drive atp.) a udělat si tak relativně jednoduše další kopii zálohy.

7

Windows a jiné systémy / Re:Windows - vlastny dns resolve

« kdy: 12. 01. 2025, 12:47:08 »

To je spíš obráceně, ne? V hosts souboru se dá nastavit jeden nebo více jmen ke konkrétní IP adrese.

Jinak asi moc ne, je to asi jako na všech ostatních platformách, hosts soubor je typicky jediné místo, kde se dají nastavit statická mapování pro systémový resolver.
Samozřejmě pokud si nenainstalujete lokální DNS server, který pak používá systémový resolver. Tam si pak můžete dělat ledacos, třeba Microsoft DNS server (z Windows serveru) má hromadu cmdletů do Powershellu.

Ale ten hosts file má jednoduchý formát a dá se editovat i třeba z nějakého skriptu.
Tady jsou např. jednoduché skripty do Powershellu (add, remove).
https://tomssl.com/a-better-way-to-add-and-remove-windows-hosts-file-entries/
Nebo si udělat jen dva alternativní hosts soubory (hosts.home, hosts.work) a pak prostě skriptem přepisovat nebo linkovat do reálného hosts.

Nevím, na co to konkrétně chcete, ale na nějaké přenášení notebooku mezi různými sítěmi a manuálním přepínáním by možná stačil i GUI editor na hosts file.
Jeden je v Powertoys
https://learn.microsoft.com/en-us/windows/powertoys/hosts-file-editor
Druhý je samostatný a umí přepínat i mezi různými hosts soubory.
https://hostsfileeditor.com/

8

Sítě / Re:Školení firewallů

« kdy: 11. 01. 2025, 17:12:02 »

Asi takhle těžko říct přímo nějaké doporučení a většina lidí, mě nevyjímaje, tam nejspíš bude promítat to, jak se k těm podobným vědomostem dostávali sami.

Ta různá školení se můžou lišit třeba v tom, kolik času se v nich bude probírat obecně aplikovatelná teorie, samotná obsluha konkrétního zařízení, praktická cvičení a úkoly příp. nějaké "best practices".

Vybíral s ohledem na stávající, vstupní znalosti a případně toho jestli bude používat konkrétní technologii. S těmi vstupními znalostmi myslím hlavně obecný přehled v síťování. Možná, že jestli je po nějaké technické škole, tak to už všechno ví a bude na to přirozeně navazovat školení s firewally.

Nedávalo by mi moc smysl tam někoho posílat, pokud by třeba neměl ponětí o těch základech (vrstvy, protokoly, PDU), netušil rozdíly mezi unicastem, multicastem, proč se někde používá TCP a jinde UDP, co je ICMP, jak základně funguje adresování, směrování, DNS atp.
Což mi přijde, že mi osobně vlastně zabralo daleko víc času a zkoušení s různými zařízeními. Pak už samotná obsluha nějakého fitru a vytváření access listů, IP konfigurace byla vlastně brknačka, když si to člověk zasadí do kontextu.
Fajn je třeba i základ z nějakého programování, takže člověku nepřijde úplně divné, proč je někde zrovna číslo 255 nebo 65535 a jak to vypadá dvojkově, že existují odlišné datové struktury s různými charakteristikami použití, porozumí pak třeba i stavovým diagramům, které někde uvidí. Zároveň si pak jde i líp představit, co se musí stát s daty (payloadem), když se posílají a v každé vrstvě se k tomu něco přidá, a naopak odebírá když se přijímají.

Já tohle získával víceméně za běhu strašně dávno z různých zdrojů - od manuálových stránek na FreeBSD, kusů zdrojáků, kde jsem se snažil něco málo pochopit, přes různé dílčí návody. Pak mi pomohly zmíněné knížky (v 90tkách to byla bichle od Rity Pužmanové o síťování, kterou jsem pak půjčoval dál , kdy jsem si to aspoň trochu uspořádal.
Ale samozřejmě dneska těch materiálu bude určitě řádově víc, zvlášť v Angličtině.
Já jsem před pár lety pár středoškoláků něco doučoval (covid, absence) a hledal jsem, co bychom si mohli sdílet a zároveň to bylo v nějakém rozumném rozsahu a pochopitelně napsané. Moc pěkně udělaná mi přišly skripta, co dělá p. Vavrečková ze SLU v Opavě. To v tu chvíli velmi pomohlo a myslím, že to může třeba dobře zafungovat i třeba na osvěžení, než jde někdo na školení.
https://vavreckova.zam.slu.cz/obsahy/pocsit/skripta/sitebc.pdf

Na to už by se podle mě dalo pěkně navazovat v nějakém školení na konkrétní firewall, ať už by to bude cokoliv (Mikrotik, Cisco, NetGate/PFSense..)..
I když dneska se tam nejspíš budou, minimálně v tom pokročilejším kurzu, zasahovat i další oblasti (šifrování, certifikáty, PKI, ověřování uživatelů a klientů atp.).

9

Sítě / Re:Vhodný modem pro internet Vodafone Fibre

« kdy: 11. 01. 2025, 12:21:47 »

Na zákaznické lince mi řekli, že můžu mít svůj modem (protože ten ten jejich se mi nevleze do skříně), takže sonduju, jestli to někdo udělal tak jako já a nebo se většina prostě podřídí těm jejich dementním podmínkám.

Já jsem dělal v síti s Vodafone GPON, ale bylo to firemní připojení. Je tam jejich dodaný router Huawei s přepnutý do bridge, neměl jsem žádné ambice to řešit (stejně už to bylo nasmlouvané předtím). Tady to ničemu nevadí, je to prostě koncové zařízení v racku, co je dál propojené metalickým 1GbE, monitoruje jej a zodpovídá za něj ISP včetně všech nastavení.
Takže se hlásím do té druhé skupiny

Jinak nedávno se tu řešilo něco podobného, mrkněte na pár posledních postů, co by pro vás mohly být zajímavé.
https://forum.root.cz/index.php?topic=29970.0

V podstatě jsou tam dva aspekty pro jiné zařízení (ONT)
- podpora standardů vyžadovaných v jejich GPON síti
- zařízení se ověřují přes svá sériová čísla (případně ještě vendor ID). Tzn. pak ISP povolí číslo vašeho zařízení (ideálně, pokud obecně umožňuje provoz jiných ONT). Nebo jak je v tom vlákně zmíněno, některá specifická ONT umožní nastavit/klonovat libovolné číslo, které už tam předtím bylo připojené.

10

Software / Re:Rsync se nezastaví na chybě

« kdy: 06. 01. 2025, 11:57:27 »

Ten unbind, bind na USB by se možná vyzkoušet dal. Ale je otázka, jestli to na konkrétním zařízení pomůže, protože to většinou neresetuje interní firmware. Ten výtuh při čtení typicky vznikne tak, že SSD má požadavky ze systému v interní frontě IO operací a ty se neprovedou, protože to čeká na tu flash stranu, kde se to podle FTL mapy skládá z více čipů (je tam proklad), některý z nich "váhá" a v podstatě to celé vymrzne. Když se zařízení fyzicky odpojí a připojí nebo se vypne napájení, tak firmware naběhne celý znovu s prázdnou frontou IO operací z hosta a dá se to případně zkusit znovu. Aspoň takhle se to většinou tvářilo mě v podobných situacích, když jsem zkoušel třeba soft reset SATA portu (delete a rescan přes procfs) vs. přerušení napájení/odpojení v UASP USB externí škatuli.

Mimo to některé operace na pozadí (odlišné od běžného host IO) jsou pak často v persistentní frontě, to je případ třeba blkdiscard (trim, unmap z hosta), garbage collection. U nich pak reset nic neřeší, firmware si po nějaké době po startu načte frontu a pokračuje tam, kde předtím skončil. Což je třeba důvod toho, že pokud někdo na SSD omylem smázne data nebo zruší partišny a má v OS zapnuté trimování, které to pošle do zařízení, tak ho většinou nezachrání ani rychlé odpojení SSD nebo vypnutí počítače. Jakmile firmware SSD znovu naběhne, klidně i v jiném počítači, tak dokončí operace z fronty a z těch oblastí už se dají přečíst jen nuly.

Ale je to asi relativně jednoduché otestovat, jestli to v tomhle případě pomůže.

11

Software / Re:Rsync se nezastaví na chybě

« kdy: 06. 01. 2025, 00:50:59 »

Ja pouzivam PHP v CLI na hodne veci (vse na co je primitivni bash skript kratkej)

To je originální a veskrze pragmatický přístup, pokud tě to neomezuje (třeba rychlost u těch kodeků) a navíc máš evidentně hromadu existujícího kódu, tak samozřejmě proč ne. Koneckonců vlastně i do PHP se dá napsat rozšíření v C.
U mě je ten další stupeň za shellem Python nebo na Windows pak Powershell (kde se dají používat i .NET objekty a třídy, takže na takové Win specifické věci to občas pomůže), ale povětšinou jsou to bastly pro interní použití (nástrojárna .

12

Software / Re:Rsync se nezastaví na chybě

« kdy: 06. 01. 2025, 00:12:09 »

Dopadlo to tak, ze jsem si to cele oskriptoval sam.

Takze mam jeden skript co analyzuje soucasnou situaci mezi zdrojem a cilem (z pohledu velikosti souboru a timestampu), a pak to vyprodukuje seznamy serazene podle nazvu, velikosti a casu, plus seznam pro castecne soubory, vcetne statusu:
...
Odpoledne to vypadalo ze jeste 48 hodin, pokud vse dobre dojede:

Disk ma fakt problem pod zatezi, treba za noc (12hodin cca) se objevila jen 4x ta soft chyba kdyz to slo 5MB/s ... a neodpojilo se to. Takze to necham dojet - a vsude kde jsem chyby zahledl tak ty video soubory prehrat opravdu sli, bez nejakeho glitche.. predpokladam tedy ze data zkoruptena nebudou.

Bezva, byl jsem zvědavý. Držím palce, ať to dojede a je tam co nejmíň porušených souborů.
To je asi poprvé, co vidím použití PHP mimo web (nebo nějakou správu web projektů).

Pripojeny to je v 10G rezimu, jsem linej shanet A-C kabel, nebo A-C/C-C s usb2 only, zda to neblbne kvuli USB samotnemu. Ale vzhledem k tomu ze nedavno nahrana data slo stahnout plnou rychlosti, a problem je zejmena u starsich.. tak bych rekl ze to bude problem na opacnem konci - smerem do flashek nebo ve FW.

Jo taky si podle popisu nemyslím, že by to tím bylo. Měl jsem před pár lety podobný problém s nějakým SATA SSD Crucial, co známý vyndal z notebooku. Ta pravděpodobnost přečtení souborů se měnila podle stáří a taky jsem brzdil rychlost, ale nedělal jsem to rsyncem, ale přes cgroups pravidlem na blokové zařízení. Nakonec z toho chtěl tak 15% prioritních souborů, z toho pak většina prošla. Po kopírování jsem na SSD zkoušel ještě blkdiscard, jestli se nevzbelhá, ale šlo do koše.

Se mi podle odkazu zda ze to funguje jen s hubama, a kdyz mam jediny Type-C port na desce, tak to nebude fungovat?

V dmesg se totiz objevovalo attempt power cycle:

Kód: [Vybrat]

[120146.136098] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120151.768091] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120151.976031] usb 2-7: device not accepting address 37, error -62
[120151.985187] usb usb2-port7: attempt power cycle
[120159.448095] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120165.080089] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command

Ale nic se nedelo - vyresil to pouze rucni zasah.

Deska je to tahle, Type-C port je zrejme z Q670E chipsetu: https://www.kontron.com/en/products/k3833-q-mitx/p176291

Hmm.. to vypadá, že ten USB-C port pravděpodobně opravdu neumí PPPS, přestože to inzeruje. Chodí to někdy i s interními HUBy na desce, třeba můj starý Intel Z77 (kancl PC) to uměl v pohodě. Novější Haswell to na interních portech nedává.
Ale mám pod tím doma downstream externí HUB Axagon HUE-F7A z Alzy, kde to jde v pohodě i selektivně na jednotlivých portech.
Pak mám ještě USB 3.0 HUBy z Amazonu, modely které jsou explicitně zmíněny jako kompatibilní a testované. Kdyby ti to nějak pomohlo, můžu ti je určitě půjčit. Ale má to jen klasický modrý 5Gbps A konektor.

13

Software / Re:Rsync se nezastaví na chybě

« kdy: 05. 01. 2025, 22:02:20 »

Jak to nakonec dopadlo? Podařilo se ti nakonec přesvědčit ten rsync, aby to dokopíroval bez nulového obsahu souborů? Snad to SSD nezdechlo úplně..

Když jsem o tom ještě přemýšlel po tom, co jsem poslal poslední post, tak bych to osobně asi zkusil udělat tou poslední zmíněnou variantou, rsyncem udělat jen seznam souborů, které chybí, a pak vlastní skript, co by kopíroval jednotlivé soubory pomocí ddrescue. Mohl bych tam totiž přidat do toho cyklu i nějaký automatický mechanismus, který by reagoval na chybu kopírování aktuálního souboru (podle návratového kódu z ddrescue), zkusil by to párkrát zopakovat a mezi tím by mohl dělat něco s USB zařízením ( třeba power cycle toho konkrétního portu pomocí uhubctl https://github.com/mvp/uhubctl ), což by mohlo ušetřit i to manuální odpojování a připojování.

14

Software / Re:Rsync se nezastaví na chybě

« kdy: 04. 01. 2025, 20:33:31 »

Netuším, jak přesně se chová rsync při kopírování z toho konkrétního zařízení. To že to neskončí chybou a kopíruje nuly rozhodně není košér. Nezměnilo by tam přidání parametru timeout, kdy mu přidáš nějaký časový limit - nevím vteřina - pro získání konkrétního souboru? Pokud při tom read requestu to blokové zařízení nějak váhá, tak by to možná mohlo něco hodit.

Jinak ještě mimoběžně. jediné, co mi trochu vysvětluje, proč by mělo projít kopírování, ale ddrescue selže takhle brzy, je to, že si při sekvenčním kopírování všech bloků FS hrábne na nějakou oblast, kde sice nejsou reálně není žádné alokované soubory, ale SSDčko se z toho přístupu už nevzbelhá.
Já už párkrát používal ddrescue dohromady s partclone - primárně aby netrávil čas zbytečnými opakováními při čtení z oblastí, kde nejsou užitečná data. Pokud je čitelná alokační tabulka, tak partclone vytvoří mapu alokovaných oblastí, a ddrescue pak ignoruje zbytek.
S exfatem a omezením rychlosti čtení u ddrescue by to mohlo být něco jako..

partclone.exfat --domain -s /dev/partition -o /tmp/partition.domain
ddrescue --max-read-rate=$((1024*1024)) --domain-mapfile=/tmp/partition.domain /dev/partition /tmp/image
mount -o loop /tmp/image /mnt/tmp

I když vím, že jestli už máš zachráněno větší část dat rsyncem, tak to možná nebude dávat úplně smysl, krom zkoušky s více možnostmi čtení a chování při chybě, co nabízí ddrescue oproti rsyncu.
Další možnost s ddrescue je - udělat si seznam zbývajících souborů ke zkopírování (třeba rsyncem s dry run), pak případně vytvořit cílovou adresářovou strukturu a finálně to protáhnout smyčkou ve skriptu nebo xargs, co bude pro každé kopírování souboru volat ddrescue s parametry.

15

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« kdy: 03. 01. 2025, 18:04:40 »

Pokud mám možnost nainstalovat ověřovací appku na více zařízení, je to možné řešení, ačkoliv je to trochu rovnák na vohejbák - člověk musí udržovat více telefonů/tabletů. Ale stejně nějaký starší mám vždy v šuplíku...

Dvoufaktor mám všude vyřešený vícenásobnou zálohou. Ale nikde to není pomocí dvou telefonů/tabletů, jsou to prostě různé metody.

Já jsem právě taky klidnější, pokud můžu mít nějakou formu záložního ověřování. U nějakých obecných TOTP ověření je to jednodušší, ale mám těch různých služeb i pracovně vcelku dost a někdy jsou to prostě vynucené speciální aplikace, takže starý mobil mi přišel nejjednodušší řešení. A s KB klíčem to fungovalo bez problémů, prostě jsem přidal další ověření přes nastavení KB profilu na webu. Podobně také se Smart klíčem od ČSOB.
Samozřejmě beru, že každá varianta má svoje nevýhody a já to bral spíš pragmaticky. V tomhle případě to chce asi počítat s tím, že se za určitou dobu pravděpodobně člověk dostane z nějakého okna podporovaných verzí systému na mobilu. I když KB klíč mi zatím v pohodě chodí na starém telefonu s iOS15. U Androidu je to, myslím, 8 a výš. U toho ČSOB to bylo podobné, když jsem to rozcházel rodičům, tam to dokonce šlo dát i na záložní Huawei s prvním Harmony OS (vykoštěný Android).