Příspěvky

1

Hardware / Re:Vícenásobný passthrough hardwaru (GPU)

« kdy: 29. 01. 2025, 11:33:52 »

Vite nekdo jak je to s pristupem k GPU(pres CUDA) z LXC kontejneru?
Diky.

CUDA z LXC je jednoduchá, pretože je to len kontajner. Takže na hostovi treba mať kernel driver, bind mountnúť všetky `/dev/nv*` do kontajnera.

2

Hardware / Re:Vícenásobný passthrough hardwaru (GPU)

« kdy: 29. 01. 2025, 11:19:13 »

A sitovka skrze SR-IOV bude mit ruznou mac v ruznych VM?
Takze je to vlastne neco jako "hw switch" zdarma (ve srovnani s klasicky resenim hw nic - sw bridge - virt nic ) ?

Áno. A nielen mac, ale jednotliví guesti môžu byť aj v rozličných VLAN. Na fyzický port môže ísť trunk a jednotlivé VM dostanú access pre im patriace VLAN.

3

Hardware / Re:Vícenásobný passthrough hardwaru (GPU)

« kdy: 29. 01. 2025, 10:34:34 »

Na fyzickém HW který má jednu grafickou kartu(konkrétně iGPU) . Je možné při virtualizaci  dosáhnout toho, aby více běžících systému mělo přístup k GPU (a tedy vyššímu výkonu)? současně. Například proxmox. pokud ano, kolik je limit, nebo co určuje limit ( plnost grafické VRAM)

Záleží od toho, o akú iGPU ide. Intel 12-14th gen zvláda (nepíšem podporuje, kvôli stavu, v akom to je) SR-IOV, kde je možné vytvoriť virtuálnu funkciu a túto sprístupniť vovnútri VM. Je to pomerne tŕnistá cesta, treba vlastný modul na hostovi aj guestoch, Intel to len pomaly upstreamuje, zjavne to nie je priorita: https://github.com/strongtz/i915-sriov-dkms

Karty s diskrétnymi GPU v consumer segment (vrátane Intel Arc) toto nevedia, úmyselne. Je to vyhradené pre drahšie modely.

-Když to zobecním, i k jinému HW, třeba USB, nebo NPU? (Jak je to řešeno, musí být na to v host os nějaký dríver nebo přímo podpora v HW)
-liší se to model od modelu? (jak tento parametr je nazvaný)?

Podpora SR-IOV je častá pri lepších sieťových adaptéroch. V podstate to môže implementovať každé PCIe zariadenie, akurát väčšina to nerobí.

4

Windows a jiné systémy / Re:Koupě levných Windows 11 a legalita

« kdy: 25. 01. 2025, 18:43:02 »

Potíž současných druhotných licencí je především v tom, že k nim nemáte poskytnutý ten "rodokmen" - tedy, kdo danou licenci koupil, jaký typ licence to byl, jak přecházela přes další osoby až k Vám. Kdyby - čistě hypoteticky - došlo k nějakému sporu, bylo by na Vás prokázat, že je licence v souladu se zákonem.

No to ale nemáte nikdy. Bez ohľadu kde ju kúpite, ten rodokmeň nemáte. Aj keď som si ju kúpil v Alze, tak neviem, akými rukami putovala. To, že som dostal kartónovú krabičku a v nej stierateľný kód nepreukazuje jej legálnosť ((keby som ich teda po tých rokoch ešte mal,  sú už dávno skartované) , len mám o trochu silnejšiu pozíciu v tom, keď argumentujem o konaní v dobrej viere. Tiež to nič nedokazuje.

5

Software / Re:Linux mi nepřehraje nic z Canal+

« kdy: 27. 11. 2024, 16:42:00 »

Me by zajimalo, proc by nekdo v roce 2024 graboval vystup grafarny (coz mimochodem samozrejme jde a samozrejme ze system muze nafejkovat podporu naprosto cehokoli), kdyz si totez muze grabnout treba rovnou z http(s) streamu.

A i kdyz si pred ten monitor postavi mobil, poridi rozhodne nasobne kvalitnejsi cam nez nekde v kine.

Uz vubec nemluve o tom, ze ti cely hdcp rozbiju jednou redukci za pet korun padesat.

Pretože ten http(s) stream je zašifrovaný a kľúč k nemu nemáte. Ten je schovaný v hlbinách hardvéru, ktorý ho nechce dať von. Nemusí ísť nutne o grabovanie výstupu grafiky, aj keď to môže byť relatívne jednoduché (svojho času sa predávali framegrabbery, ktoré mali FHD HDMI vstup a USB UVC výstup, a popri svojej činnosti akosi ignorovali HDCP).

Hovorí sa, že určitú dobu sa streamy grabovali tak, že existoval TEE exploit na Nvidia Shield, ako dostať už dekomprimovaný stream z VRAM. Bohužiaľ, v tom streame bol vodoznak, ktorý jednoznačne identifikoval ktorý konkrétny Shield môže za únik a licenciu (kľúč na dešifrovanie streamu, zašifrovaný kľúčom zariadenia) na ďalšie streamy po zaradení na blacklist už nedostal. To znamenalo obetovať jeden shield na jeden release, čo je dosť drahé hobby. Dnes už bude situácia iná, ale tí, čo to vedia, si svoje know-how dosť prísne strážia.

6

Software / Re:Linux mi nepřehraje nic z Canal+

« kdy: 27. 11. 2024, 00:54:05 »

U Linux desktopů (resp. kompletně otevřených systémů) je spousta těch věcí obecně DRM blbě realizovatelná. HDCP tam třeba není vůbec, nebo je nedotažené (viděl jsem možná kdysi pár patchů pro Intel grafiky, ale myslím že nic z userspace s tím nepracuje). A nejde jen o to, že se s HDCP kryptuje obraz, který jde ven z grafické karty do ověřeného zobrazovače, ale i že se např. nastaví nějaký flag kompozitoru, aby ty dekomprimované snímky nemohla jednoduše zachytávat jiná aplikace. I kdyby tohle nakrásně v Linuxu bylo podporované a třeba zapnuté v nějaké distribuční binárce konkrétního kompozitoru, tak to půjde velmi jednoduše vypnout a nahradit nějakým jiným buildem. Tohle je u jiných platforem prakticky mnohem složitější.
Finálně bude určitě mezi uživateli linuxového desktopu nemalý podíl těch, co jakoukoliv formu DRM odmítají úplně. Takže třeba idea, že by se třeba udělala pracovní skupina se zástupci od výrobců grafických čipů, Google (Widevine) a FreeDesktopu, resp. velkých distribucí a řekli si s čím je potřeba pohnout a jak to vyřešit , mi přijde velmi nereálná.

V linuxe je u Intelu implementovaná Protected Xe Path (PXP, od Gen12). AMD má zase svoje Trusted Memory Zone (TMZ). Oboje je implementované až po userspace driver (t.j. Mesa) a je na aplikáciach, či to použijú alebo nie.

V prípade kompozitora ani ten nevidí, čo tam je. Táto oblasť pamäte je zašifrovaná a keby ju kompozítor grabol, tak v lepšom prípade získa iba farebný šum. Čo môže byť problém, pokiaľ skladá framebuffer do jedného globálneho (čo asi robia dnes skoro všetky) a nepoužije overlay, kde grafika sama zabezpečí korektný výstup pre scanout. Vypnúť sa to dá ako celý subsystém, ale to príslušná aplikácia zistí ako nedostupnú funkčnosť; nejde fejkovať podporu a takto grabovať chránený surface.

Táto funkčnosť nevznikla kvôli stretnutiu Google, výrobcov gpu a freedesktopu. Vznikla kvôli Chromebookom, ich výrobcovia z nejakého dôvodu chceli byť konkurencieschopní a výrobcovia gpu mali pre nich pochopenie. Desktopový linux sa tu vezie s nimi, len musí doklepnúť tú časť, kde to má hrať s kompozítormi.

7

Distribuce / Re:Automatická aktualizace Fedora

« kdy: 26. 11. 2024, 23:21:56 »

Discover by sa nemal priamo baviť s dnf, ale cez packagekit.

V konzole vyskúšať:

Kód: [Vybrat]

$ pkcon refresh --force
$ pkcon update
či nevypíše nejakú chybovú hlášku, ktorú treba riešiť a ktorú GUI potichu zhltlo.

8

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

« kdy: 26. 11. 2024, 13:53:01 »

Samba (tux vs tux nebo tux vs widle) vpohode saturuje 10Gbit. Je to ciste o tom, co ti server da z pohledu disku pripadne cpu. Nemam aktualne dost velkej soubor, ale 8GB iso a rychlost vyskoci nekam k 1TB/s

Na gigu to vpohode da nejakych 110MB/s.

Pricemz v tomhle pripade se bavime o enforced encrypt smb3. Tzn obe strany tu komunikaci sifrujou a desifrujou.

Se 4ma diskama v R5 se dostanes na nejakych +- 600MB/s linear (tuxi raid z mechanickych 7k disku).

Áno, ale... To ale je, že nie v GUI (kio, gvfs). Smbclient cez CLI to dá, ale grafické nadstavby robia psie kusy a výkon ide radikálne dole. (Pri skúmaní vo wiresharku: Windows, mac - a aj smbclient - majú naraz niekoľko, 3-4, async requestov, každý vo veľkosti 0,5-1 MB. Gvfs má jeden, 64kB, a čaká na jeho dokončenie, až potom pošle ďalší, teda v podstate synchrónny. A to len preto, aby prekreslil progress bar. Gvfs používa ako backend smbclient, ale to, že rozseká všetko na malé segmenty bráni backendu, aby použil optimalizáciu).

Čím sa dostávame k  60-70 MB/s a gvfs cez gigabit a pri zhoršenej situácií pri 10 gigabite: z malého NAS (Synology, 4 disky v dmraid RAID5+ssd cache, D-ckovy Xeon), kde Windows dá 800 MB/s, dá Ubuntu+Gnome nejakých slabých 260-280.

9

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

« kdy: 21. 11. 2024, 20:36:39 »

Ako tu už bolo spomenuté, libsmbclient (súčasť samby) nepodporuje multichannel. Multichannel podporuje samba iba na strane serveru.

Modul z jadra možno áno, ale to nie je to, čo Ubuntu (gvfs, kio) používajú.

Multichannel samozrejme môžu podporovať aj klienti a to je presne to, čo robí napríklad Windows alebo MacOS. Viacero sieťových rozhraní je pritom len jedna alternatíva, ďalšou je použitie sieťových rozhraní s asymetrickou kapacitou (napr. klient má 2.5 GbE a server niekoľko 1 GbE rozhraní; keď klient vytvorí 2-3 spojenia multichannel, pôjde mu to rýchlejšie aj s jedným rozhraním), alebo ďalšou alternatívou je použitie iných transportov ako tcp (RoCE/RDMA, ktoré sú z pohľadu protokolu ďalší kanál). Ďalšia možnosť je teaming/bonding, keď klient chce vyťažiť jeho kapacitu, tak nutne potrebuje viacero tcp spojení. Dokonca aj keď má zariadenie len jednu sieťovku, ktorej bandwidth je menší ako naproti na serveri, môže multichannel priniesť zrýchlenie, pretože RSS.

No ale presne toto je to, čo libsmbclient používaný v linuxových DE nevie. Niektoré, nebudem teraz ukazovať prstom, jeden dokonca robí kontraproduktívne veci, ako je rozsekanie trafficu na 64kB segmenty, čím spoľahlivo zabije možnosť mať viacero paralelných async requestov (ktoré libsmbclient vie).

10

Sítě / Re:Horší WiFi na MikroTik hAP ax3

« kdy: 15. 11. 2024, 21:36:25 »

Problemy s dosahem a rychlosti wifi:
Je potreba spravne nastavit wifi. Nekde na fore psali, ze kdyz ho prepnete jen do rezimu vyhradne WIFI N tak muzes mit ruzne potize. Zkuste pouzit nastaveni wifi dle https://blog.darrennathanael.com/posts/mikrotik-hap-ax3-wifi-config/

Zabočím do offtopic, toto vyzerá byť nejaká novinka, bloggeri vykrádajúci komentáre na reddite. Originál tu: https://www.reddit.com/r/mikrotik/comments/17r03mn/wifi_setup_on_hap_ax3/k8hl1bh/

11

Windows a jiné systémy / Re:Mac UTF-8 a Samba s vfs_fruit

« kdy: 23. 10. 2024, 21:09:41 »

Tohle me vzdycky bavi, kdyz nekdo vubec nema paru vocogo, ale zacne blabolit uplny nesmysle.

Tak sa bav ďalej, keď riešiš nezmysly, ktoré všetkým ostatným cez 20 rokov bez problémov fungujú. Hlavne že najlepšie vieš, vocogo.

ten vi vo co go stejne jako Jirsak vi o vsem vse... prihlasovani domenovym uctem do webovych aplikaci na macos normalne funguje, ze to junior jirsak a jeho dodavatel neumi je jeho problem...

Asi tak nejak, majú tam nejakú zlátaninu, ktorá funguje len keď je v správnom svetle zo správneho uhla.

Preboha, vypĺňať aký webový formulár? Veď HTTP Negotiate s SPNEGO (aka Integrated Windows Authentication) je to pre používateľov úplne transparentné, žiadny prihlasovací formulár nemusia nikdy vidieť ani vyplňovať.

12

Windows a jiné systémy / Re:Mac UTF-8 a Samba s vfs_fruit

« kdy: 23. 10. 2024, 15:59:08 »

Tohle me vzdycky bavi, kdyz nekdo vubec nema paru vocogo, ale zacne blabolit uplny nesmysle.

Tak sa bav ďalej, keď riešiš nezmysly, ktoré všetkým ostatným cez 20 rokov bez problémov fungujú. Hlavne že najlepšie vieš, vocogo.

13

Windows a jiné systémy / Re:Mac UTF-8 a Samba s vfs_fruit

« kdy: 22. 10. 2024, 19:56:31 »

Ste si istí, že nefungujú práve zložené UTF-8 znaky?

Ano, velmi jistý.

Dekódoval jsem název mizejících souborů nějakým UTF-8 HEX konvertorem a porovnal s funkčním názvem jiných souborů a téhož souboru po přejmenování, výsledek byl jednoznačný. Proto jsem zkusil použít vfs_fruit

Z mých dřívějších poznámek:
Když bylo ů = 0xc5 0xaf tak se soubor ve finderu zobrazil, když bylo ů = 0x75 0xcc 0x8a tak nikoli. Podobně s č = 0xc4 0x8d vs č =  0x63 0xcc 0x8c atd...

Tyto soubory, které uživatel MACku neviděl, byly vytvořené a pojmenované uživatelem Windows.

Jako nejsem si jistý, jestli vfs_fruit nepřináší víc problémů než užitku, ale problém s nezobrazenými soubory se tím nějak vyřešil. Doufám, pokud za to nemohou volby unix charset a display charset, které jsem měl tu a tam zakomentované a ztratil jsem přehled, kdy a za jakých okolností.

Fakt je, že jinde jsem vfs_fruit na Sambě použít nemusel (Na Gentoo se Sambou 4.19) a na jiných Debianech nebyl problém nejšpíš proto, že těch MACkařů tam není dost a ne všichni uživatelé píší diakritiku do názvů souborů...

Zaujímavé:

keď vytvorím súbor (tri pokusy: pomenovať cez finder, pomenovať v shelli na serveri cez ssh, pomenovať cez windows explorer), tak na serveri bol vyvorený názov denormalizovaný:

0000000  c4  8d  65  72  76  65  6e  c3  a1  2e  74  78  74  0a
          D  cr   e   r   v   e   n   C   !   .   t   x   t  nl
0000016  c4  8d  65  72  76  65  6e  c3  a9  2e  74  78  74  0a
          D  cr   e   r   v   e   n   C   )   .   t   x   t  nl
0000034  c4  8d  65  72  76  65  6e  c3  bd  2e  74  78  74  0a
          D  cr   e   r   v   e   n   C   =   .   t   x   t  nl

Ale macos klient ho videl normalizovaný:

0000000    63  cc  8c  65  72  76  65  6e  61  cc  81  2e  74  78  74  0a
           c   �  8c   e   r   v   e   n   a   �  81   .   t   x   t  nl
0000020    63  cc  8c  65  72  76  65  6e  65  cc  81  2e  74  78  74  0a
           c   �  8c   e   r   v   e   n   e   �  81   .   t   x   t  nl
0000040    63  cc  8c  65  72  76  65  6e  79  cc  81  2e  74  78  74  0a
           c   �  8c   e   r   v   e   n   y   �  81   .   t   x   t  nl

V rámci rýchlych pokusov sa mi nepodarilo vytvoriť normalizovaný názov na serveri, bude treba ďalšie pokusy.

14

Hardware / Re:Jaký hardware na domácí Asterisk?

« kdy: 22. 10. 2024, 19:05:43 »

asi nebude Jaruna z infa volat Maruně na kasu č. 10 na její soukromý mobil :-)

Kľudne jej môže volať na firemný mobil, hovory v rámci CUG sú v mesačnom paušáli za sim kartu.

15

Windows a jiné systémy / Re:Mac UTF-8 a Samba s vfs_fruit

« kdy: 22. 10. 2024, 19:01:06 »

resim s dodavatelem, ze jablecny kramy se neumej prihlasit domenovym uctem k firemnimu webu, cokoli jinyho funguje

Ale vedia, SPNEGO s Kerberom aj NTML. Niektoré browsery však majú by default vypnuté SPNEGO (rovnako to je aj v Linuxe) a treba im whitelistnúť hostname alebo celú doménu, kde majú na SPNEGO reagovať.