Názory k článku
Fedora 44 ještě 32bit x86 neodstaví, diskuse byla velmi výživná
-
Ondřej KolínZlatý podporovatelOno nejde jenom o steam, tam to valve někdy opraví. Ale problém budou ty hry, co spustit nepůjdou :)
Na to bude muset být asi nějaká kontejnerizace. Tak snad i tam nám valve pomůže.
-
KateStříbrný podporovatel
Osobně mi na Fedoře stejně Steam fungoval nejlíp ve Flatpaku, což by fungovalo nadále. Některé hry předpokládají knihovny v systému na specifických místech, flatpak runtime který to řeší je fajn.
-
A co je na flatpaku humus? To, ze vytvori separatne namespace pre aplikaciu? Alebo to, ze kniznice vovnutri mozu byt ine ako v systeme? Za mna je to prudke pozitivum, ze aplikacie nie su viazane natvrdo na system a oba si mozu ist svojim tempom; uz ziadne praveke verzie v repozitaroch, lebo cely svet musi skonvergovat na jednej konkretnej verzii kazdej kniznice.
-
-
V krajnich pripadech i to je lepsi nez si tahat do systemu flatpak humus s pulkou binarek kterou uz v systemu mam nejasneho obsahu a puvodu o kterem nic nevim.
A pokud si to do systemu pritahnu tak nechci jednu po druhe analyzovat,scannovat a znova to cely opakovat po update.Jinak co linuxoveho desktopu tyce. I ve widlich musite obcas delat oplne stejne skopiciny.
"Rock prasackych progrosu".Proste aby nam ten entrprajz solusn bezel u Fsech (letici flus na stul od PM...) zakosu kde jediny schopnejsi admin je mrtvy brouk v racku.
-
Na linux, resp. typických linuxových distribucích, je hezké to, že se pro instalaci programů používají repozitáře s balíčky, u kterých se dá alespoň do určité míry předpokládat, že procházejí nějakým testováním a kontrolou. U nějakého humusu z flatpaků sotva - nejsem si jist, jestli se tímto chceme přibližovat stavu panujícímu na windows, kde kdokoliv instaluje cokoliv, co kdekoliv najde (ne že by to technicky byl problém flatpaku, ale jeho zacílení a způsob použití si o to prostě říká).
-
Vyvíjel jste nějaký komplexnější software, který by se pak distribuoval přes repozitáře?
Jako vývojář nemáte prakticky kontrolu nad ničím. Pokud chcete aby měli uživatelé aktuální verzi, musíte si dělat balíky sám. Takže s každým release balíky pro Ubuntu/Debian/Fedoru a možná i další. Nikoho v distribuci nezajímá, že jste vydal novou verzi. Do repozitáře se dostane až s další verzí distribuce. Takže uživatel může klidně dva roky čekat na novou verzi. Pokud se aplikace týká věcí, které se často mění, jsou uživatelé v pasti. Flatpak je požehnání. Jeden balíček, X distribucí. Dokud sám nechcete, nemění se podvozek. Aplikace prostě funguje a máte čas udělat v klidu upgrade na novější verzi runtime.
Ano, pokud je aplikace hodně populární, balíčky udělá někdo jiný a taky se o ně do jisté míry zvládne starat. Pokud vyvíjíte něco méně populárního, je vše na vás jako vývojáři. Z vlastní zkušenosti mohu říct, že je to dost náročné. -
Ondřej KolínZlatý podporovatel
Zbavit se bordelu pri instalaci treba KDE aplikace do GNOME je s flatpakem daleko jednodussi + mate daleko vetsi sanci, ze aplikace se bude spravne ukazovat. To samy aplikace pro Elementary, atd. atd.
Chapu, ze spouste lidem "stav" linuxoveho desktopu vyhovoval, ale doba uz se trochu posunula :)
-
To je feature, nie bug.
Za systemove kniznice si je zodpovedny system, za aplikacne aplikacia. Tym padom system moze byt minimalny, nemusi obsahovat kazdu jednu kniznicu pod slnkom a aplikacia podobne, tiez len to co potrebuje. A to, ze sa nemusia zhodnut na verzii znamena, ze ani jeden nie je obmedzovany tym druhym. Nenastavaju dnes bezne situacie, ze aplikacia na Linuxe nemoze nieco pouzit, lebo nejaky LTS system udrziava 7 rokov staru verziu a nema nove ficury, ktore pouzivatelia ziadaju.
-
nargStříbrný podporovatel
Ano, nicméně ona appka tu knihovnu asi potřebuje v nějaké verzi.
Samozřejmně, můžete být purista a říct že když ta appka potřebuje děravou knihovnu, nebudete používat tu appku.
Otázka je kolik pak strávíte smysluplnou prací a kolik migracemi mezi software (protože autor nemá zrovna čas se zabývat upgradem).
To že u close-source nepochodíte vůbec Vám je přepokládám jasné.
A prakticky ve světě go, rustu, nodejs, javy, php a dalších jazyků které mají svůj package managment jste asi skončil (protože to sebou "tahá" všechny knihovny (jsou prostě prikompilovaný)). -
To je sice teoreticky pekne, ze su symlinky (ktore sluzia na zlinkovanie pri buildovani, resp. soname -> real file name), ale:
1) neriesi to transitivne zavislosti, len priame. Ked sa nazbiera poziadavka mat v ramci procesu rozlicne verzie kniznic, tak to je dost problem. Preto to baliky v ramci distribucie nerobia a konverguju na jednu verziu.
2) neriesi to konflikty v assetoch jednotlivych verzii kniznic (kniznica pouziva pre svoj subor v /usr/share/foo/bar vo verzii 1 format X a vo verzii 2 nekompatibilny format Y)
3) neriesi to problem, ze aplikacia vyzaduje vyrazne novsiu kniznicu, nez je pribalena k distribucii (lebo do LTS novsie verzie z principu nedavame, vsak, to si setrime o 5 rokov neskor).
Toto je skutocny problem; ono casto trva 5-10 rokov, kym nieco, co Fedora a Arch uz davno maju, prebubla do Ubuntu / Debianu / RHEL (aj ked v10 je uz celkom fajn). Plus potom niektori vyvojari si tiez davaju na cas, ved kym nieco nie je odstranene, tak neriesime ze je to deprecated niekolko rokov, ved LTS distibucie tu s nami budu este dlho... a potom su prekvapeni, ked sa deprecated naozaj odstrani, ved to "potrebuju". Napriklad, kolko rokov tu mame pipewire (ktory riesi aj x11!), ze sa nema grabovat x11 root window a kolki pouzivatelia sa stazuju, ze vo waylande im nejde zdielat obrazovka?
-
ad 3: https://www.reddit.com/r/linux_gaming/comments/1h1lz4n/easy_setup_of_gamescope_on_steam_flatpak/
Sice nie velmi user friendly, ale (vraj) funguje.
-
nargStříbrný podporovatel
Vážně? Valve už cca. 13 let opravuje podporu IPv6 takže bych tomu moc nefandil... Myslím že si to ve své distribuci zachovají a tím to pro ně skončí
-
On to problem je - programatori jsou lini programovat spravne multiplatformne.
Tady nejde i486, tam nejde i586, hentam nejde 32bit.. protoze linost nejlinejsi je pouzit int, a problem sverit prekladaci, at z toho neco vymysli. Stejne jako pagesize.. 4K je mantra a trvalo dve dekady nez nekdo zjistil ze existuje neco jineho.
Uz jen takova cicovina jako ze size_t je 32-bit tady a 64-bit tam - kdyz se jedna o system, ktery muze bezt na 32 i 64 bitech. To melo byt definovano vzdy jako max(possible).. a ne ze budu delat magicke #define zaklinadla aby se v libc zpristupnila gnu extension pro dlouhe soubory.
Jestli nekde je malinkost potreba, at definuji treba PURE32, a pak si muzeme stavet mini veci se starymi cpu v aplikacich co nepouzivaji nic vic.
A alokovat souvislou fyzickou pamet (na zadost userspace) pokud vim taky porad nejde.. - a proto nvme firmware update dela cunarny ze v tom i samotni autori maj gulas... ale budem se hadat o zariznuti 32-bitu a vyhazovani neperspektivniho kodu.
-
Alokacia suvislej pamate moze byt problem, podobny ako kedysi potreba alokovat pod fyzickymi 16M alebo 4G: jednoducho nemusi byt ziadny blok volny v pozadovanej velkosti. Alebo moze, podla toho, ako skoro po boote pride poziadavka. Potom jedna a ta ista vec raz funguje a raz nefunguje a pouzivatel je z toho blbec.
GPU to riesia tak, ze maju svoju vlastnu pamat a tu si namapuju do pamatoveho priestoru procesov. Takze je suvisla, akurat vsetko co ide do nej tecie potom cez PCIe. Takze ja by som skor uvital vseobecne dostupny GPUDirect (priamy transfer medzi NVMe a GPU, resp. inymi PCIe zariadeniami)
-
Ale tak OS muze s beznymi strankami delat co chce - treba je swapovat nebo persouvat - a defragmentovat pametovy prostor.
Manipulace je zakazana pouze pro specialni (zamcene) stranky, ktere uz nekdo aktivoval pro DMA. Ale techto stranek je objemem par MB, nikdy ne tolik aby to zaplnilo byt jen spodnich 4GiB.
Desktopove GPU to zacali resit az nedavno (skrze resizable BAR), coz je dalsi WTF - proc takova technologie vubec vznikla, kdyz serverove GPU/Akceleratory meli mapovanou celou pamet - a jediny pozadavek na system bylo "Enable above 4G" - zas jenom umela marketingova segmentace a potreba vnucovat lidem "novy" hw.
GPU direct je nyni dostupnejsi (samozrejme jak kde), ale nedavno jsem si prave hral s userspace nvme driverem, ktery pak dokaze pouzivat gpu buffery (samozrejme - zas CUDA only).
V OS (asi vsech) celkove chybi podpora pro mmap-reference pro file io - napr. jak delam zarizeni ktere komprimuje video a pada to z nejakeho "akcelaratoru na pcie", tak by me mega pomohlo ze bych mohl do souboru zapsat nejake hlavicky z OS (systemove/aplikacni ram), ale zbytek obsahu si nechat stahnout z one akceleracni karty primo. Pak by totiz mohl byt CPU pripojen jen uzkym hrdlem k nejakemu PCIe switchi.
Jine featury co by se hodili - spojovani souboru (jen upravou alokacnich tabulek) - generuji stream, ale na konci je potreba pridat index - radeji na pocatek souboru (protoze pak se nedokoncena kopie da pouzit, kdezto s indexem na konci je potreba ho slozite rekonstruovat)
-
V OS (asi vsech) celkove chybi podpora pro mmap-reference pro file io - napr. jak delam zarizeni ktere komprimuje video a pada to z nejakeho "akcelaratoru na pcie", tak by me mega pomohlo ze bych mohl do souboru zapsat nejake hlavicky z OS (systemove/aplikacni ram), ale zbytek obsahu si nechat stahnout z one akceleracni karty primo.
Todle umi Linux uz od 2.6.17. Proste udelam mmap na zarizeni preprezentujici dany HW, pripadne na genericky devmem a pak zavolam vmsplice()
1. 7. 2025, 15:13 editováno autorem komentáře
-
No vida.. a ted si to nekdo prosim vemte na semestralku/bakalarku/diplomku - pro vfat/exfat/ext4 :D
(ale tohle je klonovani bloku - jako kopie bez kopie, v CoW svete .. ja chci spis neco jako move - transplantovat jeden soubor do druheho.. prvni pak o dany range treba prijde)
1. 7. 2025, 15:52 editováno autorem komentáře
-
Ale klon se neda vytvorit tam, kde neni nativne podporovan, jinak to bude strasnej hack a poskozeni konzistence FS.
Nejbliz k tomu co chci provest ma z tech funkci pak FALLOC_FL_INSERT_RANGE (ext4+xfs), ze to vlozi novou diru pred soubor.
Takze potrebuji kombinaci INSERT+CLONE+COLLAPSE ... "SHIFT", primarne na ExFAT.
Ale velke dik za nasmerovani - neco z tech callu upravime k obrazu svemu a pridame co je treba :)
-
Manipulace je zakazana pouze pro specialni (zamcene) stranky, ktere uz nekdo aktivoval pro DMA. Ale techto stranek je objemem par MB, nikdy ne tolik aby to zaplnilo byt jen spodnich 4GiB.
S tím si dovolím nesouhlasit. Např. vědecké kamery připojené přes PCIe běžně hrnou data přes DMA přímo do user-space paměti, v mém případě naprosté minimum 2-4 GB, hlavně zero-copy, což mnohdy nestačí ani na 1s záznamu. Zákazníci běžně žádají nastreamování desítek GB do RAM, aby nemuseli ukládat na disk (čti jako: mám 128GB RAM, 28GB stačí systému tak do zbytku chci data). Někteří mají 128GB, jiní i 256GB RAM, taky ne zřídka mají 2 nebo i 4 kamery...
Desktopove GPU to zacali resit az nedavno (skrze resizable BAR), coz je dalsi WTF - proc takova technologie vubec vznikla, kdyz serverove GPU/Akceleratory meli mapovanou celou pamet - a jediny pozadavek na system bylo "Enable above 4G" - zas jenom umela marketingova segmentace a potreba vnucovat lidem "novy" hw.
S tíhle naopak souhlasím. Bylo by fajn si namapovat většinu GPU paměti pro DMA z kamery a nad daty hned spustit CUDA processing bez zdouhavého kopírování tam a zpět. GPUDirect RDMA je fajn, ale dost omezuje výběr HW pokud člověku nestačí 256MB DMA buffer. Navíc vývojáři jádra stále utahují šrouby a je jen otázkou času, kdy propojení GPL a nVidia driveru přestane fungovat...
-
To jste to ale nepochopil :)
Kontinualni region fyzicke pameti je opravdu orisek v OS alokatoru, ale chapu ze se jim do toho nechce - protoze by to pak nekdo zacal nedejboze vyuzivat. Takze se omezuje na obskurni HW, ktery opravdu vyzaduje CMA.
Vsichni ostatni dokazali v HW implementovat Scatter-Gather (SGDMA), tj. na libovolne adresy, jenom si to sebou nese vetsi naroky - jak hw tak provozni - ten seznam adres musite dodat do zarizeni a vznikaji vyssi latence pripadne to muze hladovatet - takze ve vysledku je to reseni pomalejsi. Tohle jsme prave resili taky a vyresili to celkem slusne - nase PCIe jadro taky umi SG a nema ty extra latence jako konkurencni jadra.
Pouzivame to taky do kamer.. a samozrejme to dokaze zapisovat i do zarizeni vedle, nejen do systemove pameti. Staci kdyz dodate patricny pointer (resp. seznam fyzickych stranek). A zda ho ziskate dostatecne veliky - zavisi opravdu na vyberu grafiky. V dnesni dobe s RDMA pres Ethernet se ta svolnost vyrobcu grafik snad trocha pohla, a neni to az tak umele omezovany jako kdysi.
Btw i s 256M poolem by se dalo zit, pokud vase drivery ke gpu zvladnou nejake mensi mapovane oblasti prehazovat rychleji. Pokud totiz uvazuji o fronte na 4 snimky z duvodu minimalni latence (prakticke minimum je u nas ale 3, provozni pak 2 - ale to potrebujete opravdu predikovatelny skoro RT system), tak buffer pro frame muze byt 64MB - nevim co za rozliseni pouzivate.. ale typicky mate mensi snimek nez 32MP/16bit resp 42MP/12bit. To bych spis cekal ze to GPU neda po vykonove strance RT zpracovani takoveho objemu dat, nez aby byl problem s DMA do nej, byt pres mensi okno.
-
Já reagoval hlavně na ten počet uzamčených stránek "v objemu pár MB", o CMA jsem se nezmínil...
Náš driver taky používá SG tabulky. Ono po pár hodinách od zapnutí kompu je občas problém dostat i 4MB blok fyzicky souvislé paměti. U nás nejde ani tak o náročné nebo real-time zpracování obrazu. Zákazník buď chce vše uložit na disk a analyzovat offline, jenže tak rychlé disky ani v raidu ještě nevyrobili, proto je potřeba co největší vyrovnávací RAM buffer, nebo datový tok uměle zpomalovat, aby to stihali analyzovat online. V obou případech je jakákoliv kopie dat navíc nežádoucí, takže ani "přehazování" z bounce bufferu v jádře. Běžně už narážíme na limity DDR4 se čtyřkanálovým řadičem, když se třeba občas udělá kopie pro účely zobrazení.
Zpracování na GPU je zatím jen taková bokovka, která kvůli všem omezením situaci spíš zhoršuje...
-
Jako necekal bych, ze se bude delat firmware upgrade na NVMe zatimco na stejne stroji streamuje PCIe kamera do 90% objemu pameti.
Zminuji prave ten fw upgrade, kde me pozadavek na CMA nedavno potkal - a panove z nvme-cli toolu to resi stylem - hod na to THP, protoze alespon ty 2M budou pak kontinualni :D
Ten objem zamcenych stranek byl minem v IDLE.
Zákazník buď chce vše uložit na disk a analyzovat offline, jenže tak rychlé disky ani v raidu ještě nevyrobili, proto je potřeba co největší vyrovnávací RAM buffer...
+ se zminkou o 4ch DDR4.. pouzivate zastaralou platformu / nevhodnou architekturu - I kdyby jste pouzily stary (rozumej: 2nd gen) EPYC, tak s 4ch/8ch a Gen4 PCIe to NVMe RAID da z kamery na wirespeed.
Podle kvality disku (kontinualni zapis na 50% resp 25% konektivity) potrebujes bud 2x nebo 4x vice diskove BW nez kamerove (tj. pro Gen3x8 kameru je to bud 2*Gen4x4, nebo 4*Gen3x4 disky pro ten 2x faktor, nebo dvojnasobek pro 4x faktor). Pripojit to na tom Epycu je kam.. u starych socket 2011/2066 based systemu to nebylo takto pohodlne mozne (vyzadoval se hba/raid, taky s 2x sirsim kanalem), hlavne z duvodu ze to umi jen Gen3.
A pak existuji pro extremni reseni i veci jako DELL VK911 ... 20x Gen3x4 do Gen3x16 slotu .. resi BW i kapacitu zaroven.
512G/1TB ram jsem taky zkousel - na 2S systemu (LGA2011-3).. a tam je neskutecne uzke hrdlo to QPI, takze se to hodi leda pro reseni s vice kamerama a kazda nahrava do bufferu ze sveho numa regionu.
