Poslední příspěvky

1

Studium a uplatnění / Re:Kniha o C či C++

« Poslední příspěvek od echo_zulu kdy Dnes v 07:06:44 »

Z kníh by som začal asi priamo u zdroja: https://www.stroustrup.com/tour3.html, je to taký prehľad, toto vydanie som nečítal, ale to prvé bolo predstavením toho, čo sa volá moderné C++ a ukazovalo písanie kódu jednoduchším spôsobom. Myslím, že táto bude mať ešte viac zjednodušení.

Vývoj C++ ako jazyka a knižníc ide v smere hľadania lepších abstrakcií, ktoré nahradzujú tie, ktoré sú považované za nebezpečné alebo náročné na pochopenie, dokonca tie pôvodné techniky už nie sú odporúčané na bežné písanie, skôr sa od nich systematicky odradzuje.

Ďalší smer vo vývoji jazykov všeobecne je, že k sebe konvergujú, takže aj do C++ preniká funkcionálne programovanie, aj keď to je tam v rôznych úrovniach a do istej miery už odvtedy, čo Stepanov uviedol STL a odvtedy, čo, už neviem kto, šokoval ostatných, keď zistil, že šablóny sú vlastne samostatný funkcionálny jazyk.

Potom ešte existujú oficiálne odporúčania ako písať kód, sú spravované kľúčovými členmi normalizačnej komisie (C++ má normu v rámci ISO), to je na https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines. Je to skvelý zdroj Informácií organizovaný podľa jednotlivých tém.

A potom ešte stojí za to sledovať konferencie, najznámejšia je tu: https://m.youtube.com/@CppCon.

Tu je napríklad sumarizácia toho kam C++ smeruje a aké rozšírenia možností a zjednodušenia práce to prinesie: https://m.youtube.com/watch?v=FNi1-x4pojs

2

Sítě / Re:WireGuard pro domácí síť

« Poslední příspěvek od CFM kdy Dnes v 07:06:24 »

Přemýšlím co je cílem např v případě TV? Aby ostatní na stejné WiFi neviděli, co TV posílá? Pokud je to tolik důležité a nejde nainstalovat WG klient, tak ji vytvoř vlastní virtuální AP/SSID s jiným heslem.

3

Nová témata / Nejlepší proxy adresy a reverzní proxy servery

« Poslední příspěvek od weitang kdy Dnes v 06:31:23 »

Různá použití proxy serverů https://www.naproxy.com/residential-proxies/?keyword=w0f0xn51 a reverzních proxy serverů a jejich úloha v zabezpečení sítě. Přečtěte si tento článek a získejte 600 MB provozu zdarma od nejlepších proxy serverů, přihlaste se a zadejte promo kód FRIDAYNIGHT2024, vraťte se sem a klikněte na rezidenční proxy server, který si můžete koupit a získat zasvěcenou slevu. Zde je několik návrhů na zlepšení zabezpečení prostřednictvím rotačních rezidenčních proxy https://www.naproxy.com/pricing/residential/?keyword=w0f0xn51 serverů Tento článek uspořádá některé z hlavních myšlenek:

 

Definice a funkce proxy serverů


1. Základní funkce zástupců

Základní koncepcí proxy serverů je předávání provozu ze zdroje do cíle s možností změny zdrojové nebo cílové IP adresy. proxy servery jsou užitečné nejen pro skrytí IP adres klientů, ale také pro zpracování a filtrování provozu na síťové vrstvě (L3) a aplikační vrstvě (L7). Použití proxy serverů umožňuje vyrovnávání zátěže, přesměrování provozu, řízení přístupu a další funkce. Samotné proxy servery obvykle mění zdrojovou IP adresu provozu, ale změna umístění není u proxy serverů vyžadována.



2. Rozdíly mezi proxy servery a firewally

Ačkoli proxy servery a firewally mají v některých případech podobné funkce (např. filtrování provozu a blokování škodlivých IP adres), pracují na různých úrovních. Proxy servery obvykle pracují na aplikační vrstvě a jsou schopny hloubkově analyzovat a zpracovávat konkrétní aplikační protokoly (např. HTTP, FTP atd.), zatímco firewally pracují spíše na síťové vrstvě a zabývají se základním filtrováním IP adres, portů a protokolů.

 

3. Scénáře použití proxy serverů

Proxy servery umožňují skrýt skutečnou IP adresu, zejména pokud stejnou IP adresu sdílí více služeb, a pomocí virtuálních hostitelů směrovat provoz na různé služby.

Proxy servery lze také použít jako filtry provozu, které uživatelům umožňují definovat specifičtější pravidla provozu, zejména pro blokování nežádoucích aplikačních protokolů (např. P2P provozu) v podnikových sítích.

Proxy servery mohou také ukládat často využívané prostředky do mezipaměti, čímž se snižuje spotřeba šířky pásma.

 

Zabezpečení a ochrana soukromí
1. Výzvy spojené se šifrovaným provozem

S oblibou protokolu HTTPS a šifrované komunikace čelí proxy servery obtížím při provádění filtrování provozu. Šifrovaný provoz znemožňuje proxy serverům zobrazit obsah přenosu, a proto nemohou filtrovat na základě obsahu. nové šifrovací protokoly, jako je DNS přes HTTPS, tento problém ještě zhoršují.

 

2. Proxy servery v síti LAN

Pokud se proxy servery a klienti nacházejí ve stejné síti LAN a sdílejí stejnou veřejnou IP, jsou proxy servery relativně méně užitečné, protože účinně neskrývají zdrojovou IP ani nemění cestu přenosu. Hodnota proxy serverů v tomto případě spočívá především ve správě provozu a distribuci služeb.

 

Aplikace reverzních proxy serverů
1. Úloha reverzních proxy serverů

Reverzní proxy servery jsou obvykle nasazovány mezi veřejnými servery a interními servery a slouží především k ochraně interní sítě před vnějšími útoky a k filtrování škodlivých požadavků. Mohou být také použity pro rozdělování zátěže provozu k distribuci uživatelských požadavků na různé interní servery. Rozdíl mezi reverzním proxy serverem a tradičním proxy serverem spočívá v tom, že proxy server prochází provozem na straně serveru, nikoli na straně klienta.

 

2. Funkční překrývání reverzních proxy serverů a firewallů

Reverzní proxy server může fungovat jako brána firewall, skenovat provoz, který přes něj prochází, a blokovat nevyhovující požadavky. Zaměřuje se však spíše na ochranu interních serverů před přímým vystavením vnějším sítím prostřednictvím proxy serverů. Reverzní proxy servery mohou také poskytovat bezpečnostní opatření, jako je ověřování a řízení přístupu.

 

Použití v osobních domácích sítích
1. Proxy servery v domácích sítích

Použití proxy serverů a reverzních proxy serverů v domácím prostředí může zvýšit bezpečnost. Proxy servery lze například nakonfigurovat tak, aby monitorovaly chování členů rodiny v síti, filtrovaly nežádoucí obsah a zabraňovaly úniku IP.

 

2. Kombinované použití virtuálních privátních sítí a proxy serverů

Při práci s aplikacemi, které mohou způsobit únik místních IP adres (například Kodi), může být použití proxy serverů nebo reverzních proxy serverů v kombinaci s virtuální privátní sítí účinné při zajištění anonymity a bezpečnosti provozu. Soukromí lze zlepšit tím, že se aplikace připojuje pouze prostřednictvím sítě VPN a vyhne se přímému přístupu k internetu.

 

Shrnutí
Tyto diskuse ukázaly rozmanité možnosti proxy serverů a reverzních proxy serverů, zejména v oblasti bezpečnosti a řízení provozu. Ačkoli proxy servery mohou měnit IP adresy a provádět filtrování provozu, jejich úloha v moderní šifrované komunikaci je omezená. Reverzní proxy servery se naproti tomu častěji používají k ochraně interních služeb a umožňují vyrovnávání zátěže. Oba typy lze použít v domácích sítích a podnikových prostředích ke zvýšení zabezpečení sítě, skrytí skutečných IP adres a optimalizaci řízení provozu.

4

Sítě / Re:WireGuard pro domácí síť

« Poslední příspěvek od Pentheus kdy Dnes v 05:13:58 »

michaelscz // přesně takhle to používám teď a problém mám s TV co zmiňuje k3dAR.

5

Sítě / Re:SMB client - multichannel support

« Poslední příspěvek od Michal Šmucr kdy Dnes v 02:10:50 »

Tak ještě další věci.
Teď jsem si všiml, že v předchozím příspěvku jsem psal o tom povolení sysrq a cifsFYI přes sysfs.. To jsem omylem zkopíroval z historie terminálu, kde to bylo pro ukecanější debug přes dmesg, což by to info o spojeních v DebugData nemělo být třeba, pardon.
Dělal ještě test s víc jádry, resp cifs moduly.
U 5.15 a CIFS modulem 2.33 (Oracle UEK) to chodí přes jednu síťovku jak pro čtení, tak i zápis.
To, co jsem psal předtím, že zápis využije obě síťovky, fungovalo s kernelem 5.11 a CIFS modulem 2.50 (jak Oracle UEK Next, tak OpenSUSE Tubmleweed).

6

Studium a uplatnění / Re:Kniha o C či C++

« Poslední příspěvek od František Ryšánek kdy Dnes v 00:29:43 »

Knihy mého mládí jsou dnes do jisté míry zastaralé. Mám na ně ale hezké vzpomínky :-)

Třeba Beginning Linux Programming. Nakousne spoustu témat, ale tak akorát, aby se člověk zakousl a dál už študoval po svém / jinde. Třeba kapitola o libpthread (vláknové synchronizaci) je ve skutečnosti velice "nekompletní" - tehdy mi dost pomohl článek na Linuxových novinách (linux.cz) který dnes už nenajdu ani skrz wayback machine... škoda. Ta kniha má kapitoly o všem možném, doporučuji.

Další byla Thinking in C++ od Bruce Eckela. Bejvala zadarmo na mindview.com, dneska se válí kopie různě po webu. Volume 1 základy, Volume 2 "pokročilá" témata. Volume 2 jsem nedočetl - přišlo mi, že jsem u konce s dechem buď já, nebo možná autor :-) Hlavně to co byla před 25 lety pokročilá témata, to je dnes buď dětská hra, nebo bizardní slepá vývojová větev. Navíc mi ve zpětném ohledu připadá, že ta kniha byla sice čtivá, ale ne úplně systematická... A některá tehdejší dogmata se rozplynula jak pára nad hrncem apod. Některé věci se změnily, hlavně do standardní knihovny přibývají užitečné objekty, které si dřív člověk musel obstarat po svém. V dnešní době dost užitečný zdroj aktuálních informací je cppreference.com (online referenční příručka standardního C++, prakticky každé heslo končí examplem).

Ohledně posixových vláken a synchronizačních primitiv mám pocit, že se nedávno dostala prakticky nastojato do standardu C++, akorát už se jim neříká libpthread :-) Je to maličko komické ve světě Windows, kde komunikace mezi vlákny vypadá v rámci WinAPI nativně dost jinak.

A nakonec, čtivé bylo už evangelium podle Briana a Dennise: The C Programming Language (Kernighan and Ritchie). I tady se za těch cca 40 let tu a tam něco změnilo, ale ne natolik, aby starému textu nebylo rozumět :-)

7

Hardware / Re:Zvuková karta pro Linux

« Poslední příspěvek od Marvin kdy Dnes v 00:27:26 »

Převodník USB->TOSLINK (optický) od chiňana stojí pár $$$, některé umí i 24bit/192kHz.
S/PDIF výstup na RCA (koax) by měl mít oddělovací pulsní transformátorek, ale často bývá ušetřen a zemní smyčka zůstává.
Jako USB zařízení to musí mít ve frontě vzorky na milisekundy, aby to stále mělo co vysílat, nějakou latenci to přidává.

8

Sítě / Re:SMB client - multichannel support

« Poslední příspěvek od Michal Šmucr kdy 21. 11. 2024, 23:53:40 »

V poslední době jsem neměl moc potřebu tohle řešit, protože jsem používal buď rychlejší rozhraní nebo bonding (a víc klientů), ale je to zajímavé.

Zkusil jsem si to nasimulovat a musím říct, že se to chová dost specificky.
Pokus jsem dělal jen teď na QEMU/KVM virtuálu, kde jsem pak zalimitoval rychlost dvou síťovek na fyzický počítač (který byl zároveň CIFS klientem) na cca 1Gbit.
SMB multichannel připojení se povedlo.
Pro jistotu jsem to ověřil přes

echo 1 >/proc/sys/kernel/sysrq
echo 1 >/proc/fs/cifs/cifsFYI

cat /proc/fs/cifs/DebugData

...kde pak bylo následující:

   Server interfaces: 2   Last updated: 570 seconds ago
   1)   Speed: Unknown
      Capabilities: None
      IPv4: 192.168.202.240
      Weight (cur,total): (1,1)
      Allocated channels: 1
      [CONNECTED]

   2)   Speed: Unknown
      Capabilities: None
      IPv4: 192.168.202.134
      Weight (cur,total): (1,1)
      Allocated channels: 1
      [CONNECTED]

Při čtení ze serveru to pak jelo pokaždé pouze přes adresu a síťovku, kterou jsem použil při připojování CIFS sdílené složky (tedy v mém případě první).
Ať jsem nastavoval, co chtěl, měnil způsoby čtení (iodepth, vlákna..), zkoušel různé nastavení SAMBY na serveru atp.
Monitoroval jsem na serveru i device statistiku přes sar (ze sysstatu) a data šla vždy jen přes jednu síťovku.

Ano podle toho by se zdálo, že to opravdu nefunguje (minimálně na agregaci rychlosti, failover jsem nezkoušel)
Nicméně pak jsem testoval zápis.
Pokud to bylo jednovláknový zápis s iodepth=1 (nebo třeba jednoduchý zápis z urandom přes dd), tak se to chovalo úplně stejně jako čtení - vše přes první síť.
Ale když jsem zvedl iodepth třeba na 4, nebo na server zapisoval víc souborů naráz, tak to vysaturovalo obě linky na max.
I při kopírování souboru v Nautilu (GNOME) na server to šlo v pohodě až na 220MB/s - kopírování tady evidentně také naplní delší frontu IO operací a ty pak jedou přes obě spojení/adresy.

Takže v tomhle testovacím prostředí to vypadá, že multichannel smysl má i z Linuxového CIFS klienta, ale jen pro zápis.

Možná by na to čtení teoreticky mohlo mít vliv i to, že mám s těmi virtuály specifickou topologii sítě s bridgem a pokud bych to opakoval třeba na dvou fyz. počítačích, kdy by měl každý dvě fyz. síťovky, tak by se to mohlo chovat odlišně.. Ale moc bych na to nesázel. Plus jsem dělal teď jen rychlý test, nehledal jsem nikde ve fórech, mailing listech atp.

9

Hardware / Re:Zvuková karta pro Linux

« Poslední příspěvek od František Ryšánek kdy 21. 11. 2024, 23:28:13 »

Pokračuji v debatě už notně off topic a trochu se za to stydím:

...
Jenom mi vrtá hlavou, proč výrobci desek nepřipojí zem zvukovky/USB portu odděleně přes jeden/více GND pinů/kabelů ATX konektoru, aby se to spojilo až v tom proletovaném hnízdě v PSU, kam vede i PE vodič. Ale možná to někteří tak dělají, netuším.

Pochybuju :-)
Mimochodem by se pak na motherboardu musela nějak "izolovaně překračovat" analogová vs. digitální zem, mezi kterými by se hemžilo všechno možné od DC po pár MHz (v desítkách milivoltů, pokud ne víc).
A stejně by to nebylo dokonalé z hlediska odrušení té "samostatně vedené analogové země", protože by byla částečně v souběhu s tou pracovní zemí silovou, takže by se tam ledacos indukovalo skrz magnetické pole...

Ani řešení pomocí symetrického analogového vstupu neztlumí rušení úplně do nuly, protože CMRR je konečné číslo. Jasně, může to pomoct docela dost, zejm. pokud to rušení nejde moc vysoko nad akustické pásmo (aby to vstup "stíhal odčítat", aby mu na to stačila šířka pásma / rychlost přeběhu). Na 50Hz brum to stačí s velkým přehledem.
Tímto nechci tvrdit, že jsme ve sporu :-) Sám jste zmínil galvanické oddělení, což je i moje oblíbená metoda řešení zemních smyček.

Pravda je, že USB má i v "interruptovém" přenosovém režimu de facto periodický polling v taktu 1 ms, plus tam budou nějaké buffery (=latence) takže "ten můj USB dongle" v tomhle ohledu není dokonalý, 

Tak dražší profi USB zvukovky používají highspeed bInterval i 125us, což je úplně v pohodě. Samozřejmě USB MIDI dongle pojede na lowspeed, tudíž min. 1ms již na připojení. Na druhou stranu i ta PCI zvukovka má nějakou latenci obsluhy přerušení...

Díky za dovzdělání, tohle mi unikalo :-) Jestli správně chápu, granularita 125us je vlastnost highspeed fyzické vrstvy? Oproti fullspeed, kde je natvrdo 1 ms. A bInterval je celočíselný násobek tohoto vrozeného kvanta.

Co se týče čistoty výstupu a šířky pásma k basům, stojím si za tím že ten konkrétní model generického USB donglu co jsem uvedl, se 24bit DAC/ADC, není vůbec marnej, i ve srovnání se svým hloupějším 16bitovým bráchou (vypadá stejně, jenom nemá v obj.kódu "HQ").

Máš prosím konkrétní link?

Jasně: 1) Axagon chytřejší dražší brácha, 2) Axagon hloupější levnější brácha.

Já mám toho dražšího, a moje hodnocení je pohříchu subjektivní. Měřit tomu zkreslení a šum jsem nezkoušel, mj. protože nemám čím (leda smyčkou).

Zkusím přiložit .TXT dump lsusb -v. Říká, že výrobcem čipu je VIA, a že fyzická vrstva je USB 1.1. Ona je to možná přesněji "USB 2.0 na full-speed rychlosti" :-) což je prakticky totéž. V tom případě pro mě platí ta 1 ms.

Když jsem zkoušel googlit USB PID 0x3417, našel jsem kdesi zmínku, že dotyčný čip je VT1620A. Parametrově by to vcelku odpovídalo. A tenhle šváb je skutečně jenom USB full-speed.

Google mi našel taky (pěkně uleželý) paperlaunch čipu VIA Envy VT1730, který byl údajně jako jeden z prvních high-speed. Ale nedaří se mi, nalézt s ním nějaké produkty.

Pokud tam bude na výstupu zes ve třídě D, tak bych moc neřešil, jestli je DAC 16b nebo 24b,

Jenom k těm D - dneska už se to hodně posunulo. Takové TPA335x 100+ W za 40USD včetně bedny má velice slušné parametry, i ty superlevné TPA3116 minikrabičky hrají velice slušně (mám jich doma několik).

Heh taky mám jednu čínskou destičku s TPA3116. Zkoušel jsem s ní budit takové sranda bedničky osazené Visaton BG-20-8, a jako zdroj signálu právě tenhle zmíněný USB dongle. Šumělo to relativně slyšitelně, třeba z podání vyššího konce pásma jsem taky nebyl úplně odvařenej... ale fakt je, že jsem nad tím mávnul rukou a třeba napájecí zdroje jsem nezkoumal. Po téhle Vaší recenzi se k tomu myslím ještě vrátím :-)
Do sluchátek ten USB dongle nešumí.

A moderní Dčka ve zkreslení při výkonu a celkové vychovanosti v zátěži už jasně nad lineáry vedou, viz např. https://www.audiosciencereview.com/forum/index.php?threads/purifi-eval2-eigentakt-mono-amplifier-kit.54938/

:-O

Pokud se týče výstupu do zesu, ještě bych zmínil, že existuje optický digitální propoj TOSLINK resp. S/PDIF. Je to sice spíš záležitost spotřební elektroniky než profi audia, ale zemní smyčku to přeruší. Nemám představu, jestli to třeba nepřidává nějakou latenci.

Latence bych se asi nebál, vysílač bude mít téměř nulovou, přijímač např. DIR9001 uvádí latenci 3 vzorky, tedy nic.

To nezní marně! Akorát... vytáhnout z počítače S/PDIF výstup znamená buď začít motherboardem (okolo 3kKč už se najdou s S/PDIF výstupem) nebo přidat soundblaster s tímhle výstupem, a co pak s tím dál: buď převést levným DAC donglem za pár šupů na analog (a dát si pozor na země a napájení), nebo koupit receiver okolo 10 kKč jenom abych měl zes nativně s tímhle vstupem...

Jinak - 50Hz železné trafo má velkou výhodu, že neprodukuje VF rušení.
Jakýkoli spínaný měnič/adaptér, klidně ve třídě II a "medical grade", má slabý průsak (směs 50 Hz a VF). Pár desítek až stovek mikroampérů. Pokud by byl zájem o medical-grade napájecí adaptér, a dalo by se to zpřevodovat konektorově (a skladbou výstupů), tak tyto jsou k nalezení v TME, k dispozici je filtr "použití: pro lékařské aplikace". Zde k tématu jsou relevantní nejspíš kategorie stolní napájecí zdroje (formát "notebooková cihlička") nebo adaptéry do zásuvky.

10

Sítě / Re:WireGuard pro domácí síť

« Poslední příspěvek od k3dAR kdy 21. 11. 2024, 23:06:57 »

[...] a na všech klientech (mobil, notebook apod) mám konfiguraci, kde je důležité:
[Peer]
AllowedIPs = 0.0.0.0/0
[...]

a jak to nastavi na te TV? (tedy pokud to neni TV s Androidem) :-)