Poslední příspěvky

21

Vývoj / Re:Proč se cpe JavaScript na backend?

« Poslední příspěvek od CamperPL kdy 02. 02. 2025, 23:26:24 »

Asi mi něco uniká, já jsem nikdy ten boom JS na backendu nepochopil. Nedokážu si představit, jak by na něm fungovaly moje projekty. Dělám e-shopy a mám tam plno blokujících operací, např.:
- Čtení a generování velkých XML/Excel dat (stovky tisíc produktů)
- Následné zpracování (dost často plnohodnotným ORM)
- Různé prasárny, kde se porovnávají obrovská pole atd. I těch rychlejších CPU operací je stejně hodně a podle mě se to nasčítá.

Jestliže celou administraci bude obsluhovat jedno vlákno, bude se to vzájemně blokovat a nebo budu každou blbost explicitně pouštět ve vlastním workeru a v tom případě mi to celé přestává dávat smysl, ne? A vůbec jsem nezmínil, že bych teoreticky mohl kvůli procesům na backendu blokovat dokončení objednávky zákazníkem - shop bych asi provozoval na samostatné instanci.

Pak jsem vůbec nepochopil, že ten boom začal v době, kdy se ještě moc nepoužíval TS. Bez typů je to krok zpět.

22

Vývoj / Re:Proč se cpe JavaScript na backend?

« Poslední příspěvek od ogdru6jahad kdy 02. 02. 2025, 22:59:06 »

Javascript a švábi (album)

kryl - dekuji, za cecko dekuji, jenz nauci me pili.

23

Vývoj / Re:Proč se cpe JavaScript na backend?

« Poslední příspěvek od fortran1986 kdy 02. 02. 2025, 22:52:43 »

Proč se cpe JavaScript na backend?

pretože isomorfné aplikácie umožňujú zdielať jeden kód medzi frontendom a backendom. takže môžem rovnaké triedy, funkcie a libky používať na frontende aj backende.

24

Vývoj / Re:Proč se cpe JavaScript na backend?

« Poslední příspěvek od fortran1986 kdy 02. 02. 2025, 22:41:48 »

Za 20 rokov som si prešiel asi všetkými mainstreamovými jazykmi a TypeScript je môj obľúbenec [*1] Nepoznám žiadny iný jazyk, ktorý by mal takú vyjadrovaciu schopnosť čo do typov [*2] A od typovej bezpečnosti sa potom odvíja veľa ďalších vecí.

Statický typing v TS je fajn, sám ho obľubujem, avšak funguje len v compile-time, naopak runtime typescriptovým typom nerozumie nedá sa s typescriptovými typmi pracovať za behu napr pomocou reflexie, takže pri programovaní cítim , že ten strong typing je len umelo dolepený na inak veľmi weak typed jazyk. Ešte som sa nestretol v inom jazyku s takou veľkou schyzofréniou ako pri TS. A toto je obrovský nedostatok. Aj keď uznávam že iná možnosť ako dolepiť typy na JS ani nebola. Dnes už naštastie existujú technológie ako Blazor a Bolero postavené nad WASM a tam už je prítomný plnohodnotný staticko-dynamický typing.

Čo sa týka vyjadrovacej schopnosti také C++ 23 je ešte dalej (aj keď uznávam že tu trošku porovnávam hrušky s jablkami). C++ má ďaleko pokročilejší typový systém. TS generics sú oproti C++ templatom (halvne v oblasti metaprogramovania) len vtip, ale pre širokú komunitu vývojárov sú na druhej strane generics ľahšie na pochopenie a naučenie. Takže všetko má svoje pre a proti.

25

Bazar / Prodám klávesnici ZSA Moonlader

« Poslední příspěvek od kidal5 kdy 02. 02. 2025, 22:01:18 »

Dobrý den,

prodávám kvalitní split klávesnici ZSA Moonlander s Cherry MX Brown spínači. Klávesnici jsem zakoupil v říjnu 2024 a téměř ji nepoužíval, takže je jako nová, bez jakýchkoliv známek opotřebení. Více na oficiálních stránkách výrobku - https://www.zsa.io/moonlander.

Hlavní výhody této klávesnice:

• Ergonomický design, který vám pomůže předejít bolestem zápěstí a zvýšit produktivitu
• Split konstrukce umožňující přizpůsobení rozložení rukou podle vašich potřeb
• Cherry MX Brown spínače – tiché, s hmatovou odezvou, ideální pro kombinaci práce a hraní
• Podpora široké škály přizpůsobení a nastavení přes open-source software

Kromě klávesnice přidávám testovací sadu 19 různých spínačů, díky které můžete vyzkoušet různé typy a najít ten, který vám bude vyhovovat nejlépe.

Původní cena včetně CLA a DPH byla 10980 Kč, nabízím ji nyní za 8500 Kč.

Předání možné buďto v Praze nebo posílám pomocí Zásilkovny.

26

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« Poslední příspěvek od googler2 kdy 02. 02. 2025, 20:44:22 »

Musim si nastudovat ako zmonitorovat komunikaciu. Ked som to pravidlo prepisal len na established, related tak sa obnovil predchadzajuci nefunkcny stav.

27

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« Poslední příspěvek od Michal Šmucr kdy 02. 02. 2025, 19:49:25 »

tak mal si pravdu, ked som povolil obojsmernu komunikaciu medzi tv vlan a pc vlan, tak uz funguje v podstate vsetko okrem castingu priamo cez Windows, ten stale TV nevyhlada ako zariadenie dostupne na castovanie, ale ako tu uz niekto spomenul, ten problem asi nebude vo VLAN (MDNS).
Dost mi ale vadi, ze aby bol chromecast plne funkcny, tak musi byt povolena obojsmerna komunikacia, to potom pouzitie VLAN straca zmysel, no myslim si, ze z bezpecnostneho hladiska je dobre mat srandicky typu smart TV a ine multimedia boxy izolovane od zbytku siete. Takze asi budem musiet ozeliet funkciu castingu v prospech bezpecnosti.
PS: Vobec nerozumiem tomu preco by mala TV ako receiver spatne komunikovat so sender zariadenim. Ved sender posiela video do TV, ktora ho uz nema posielat spet do siete sendera, ale ma ho len zobrazit.

Hmm.. mám tu bohužel spíš Apple věci, žádný Chromecast ani televizi, abych to ozkoušel. Spíš jsem to nastavoval tak různě po známých, naposled někde na Ubiquity FW.
Ale podle mě by receiver sám o sobě komunikovat se senderem neměl. Proto jsem zmiňoval, že by měla být povolená existující spojení - established, related. (neměla by být potřeba nová spojení založená z izolované VLANy)

Jestli si to pamatuju dobře, tak Chromecast casting jede zhruba takhle.
Po objevení zařízení a zvolení k posílání se vytvoří obousměrný websocket kanál ze senderu na receiver.

Pak to streamuje v podstatě dvěma způsoby.
- casting z nějaké podporované aplikace (která má odpovídající appku na receiveru). Např. YouTube. Předá se odkaz s pozicí, stream už si pak tahá dál receiver a sám pokračuje v přehrávání.
- mirroring, kdy se použije RTP/UDP s nějakou kompresí jako H.264, VP9 a aktivně ty pakety posílá zas sender

Všechny věci ohledně přehrávání (ovládání, pozice, nějaké řízení toku atp.) se odehrává jen přes ten už existující websocket kanál.

Případně to zkusit nějak dál zmonitorovat..

28

Hardware / Re:Akcelerace SSL - Intel QuickAssist - QAT

« Poslední příspěvek od Aleš Rygl kdy 02. 02. 2025, 19:37:00 »

Děkuji moc za pěkné shrnutí situace. To jsem asi potřeboval.

DoT jsme měli kvůli potížím s vydáním certifikátů dočasně vypnuté (ne každá CA umí certifikáty pro IPv4 natož IPv6 adresy a to nemluvím o tom, že se musí každá IP validovat zvlášť (a ne, nejde podstrčit tech validačních stringů víc na jednou)). No a mezitím toho provozu zase přibylo 

O asynchronním používání jsem se už také dočetl. Možnost fallbacku na OpenSSL 1.x ještě prozkoumám, ale jsem na Debianu.
Ještě jednou díky.

29

Hardware / Re:Akcelerace SSL - Intel QuickAssist - QAT

« Poslední příspěvek od Michal Šmucr kdy 02. 02. 2025, 19:18:19 »

Nemůžu teď přispět žádnou relativně novější konkrétní zkušeností s QAT, protože teď podobně jako vy nemám přístup k žádnému hardware, co to podporuje (tzn. buď EPYCy, nebo Xeony bez QATu).
Setkal jsem se s tím kdysi v jedné z prvních verzí, tak 10 let zpátky, a byl to spíš test slabším stroji s odlehčením úplně jiného workloadu (kryptování sym. AES, dlouhé bloky) navíc to řešil v detailu spíš kolega.

Nicméně pořád na to sem tam koukám, zvlášť když se objevují třeba novinky v release notes ohledně QAT v enterprise distribucích.

Co se týká těch materiálů od Intelu, tak je to občas trochu matoucí (as clear as mud:) ), ale v podstatě tam operují s generací QAT HW a verzí QAT HW.
Generací QAT HW je 5, přičemž poslední 4. a 5. je v podstatě jen integrovaná uvnitř nových Xeonů.
Akcelerační karty (PCIe x8 a x16) jsou dneska v podstatě 7 let staré a v 3. generaci. Ty integrované jednotky umí např. víc algoritmů a jsou výkonnější.

Pak to ještě dělí na verze (ne generace) hardware, legacy verze QAT1.x je cokoliv před čtvrtou generací (karty, moduly v čipsetech c62x). Verze QAT2.x pak od čtvrté dál.
Pokud se používají knihovny a ovladače od Intelu (out-of-tree), jsou to dvě oddělené věci.

https://www.intel.com/content/www/us/en/support/articles/000094285/technologies/intel-quickassist-technology-intel-qat.html
https://www.intel.com/content/www/us/en/support/articles/000093843/technologies/intel-quickassist-technology-intel-qat.html

Jinak k tomu OpenSSL. To by nemělo být potřeba patchovat. Minimálně RHEL/Oracle, SLES mají jak ovladače HW, firmware, qatlib (na QAT2.x HW) pro přístup z userspace, tak finálně i balíčky pro qatengine, což je knihovna, co se přidá jako další provider do systémového OpenSSL.
Stran té konkrétní aplikace potom, myslím že u těch věcí, kde se o tom rozepisovali v souvislosti s TLS (např. NGINX, HAProxy), tak v podstatě zásadní pro ty inzerované nárůsty výkonu bylo, že aplikace ten engine z OpenSSL používali asynchronně. Další zajímavá věc bylo to, že v rámci toho offloadování se pak ne všechno hrne na QAT hw engine, jsou části kde se používají "jen" specificky optimalizované algoritmy pro nové Xeony.

Nakonec, jak jsem zmínil, že máte problémy s výraznou výkonovou regresí u OpenSSL 3.x. Jestli jste už teď někde na stropě, nebyla by ještě šance to chvíli provozovat na OpenSSL 1.1.1, než se to dořeší. Upstream je sice oficiálně už mimo okno podpory, ale třeba Oracle/RHEL 8 to pořád má i s nějakými backportnutými CVEčky, podobně třeba SLES. RHEL9 je sestavený s 3.x, ale 1.1.1 je tam jen jako compat-openssl bez devel balíčků.
Jinak právě třeba u HAProxy se právě zmiňuje, že pokud se používá s 3.x, tak např. doporučují používat vnitřní lehčí zámky..
https://github.com/haproxy/haproxy/blob/0a28b1ea0c674f7bcc7ad386abdcf963f9176475/INSTALL#L362

30

Hardware / Re:Akcelerace SSL - Intel QuickAssist - QAT

« Poslední příspěvek od vcunat kdy 02. 02. 2025, 17:32:05 »

Za mě v takové situaci je efektivnější tu práci už udělat celou.