Keresés

Új hozzászólás Aktív témák

  • Frawly

    veterán

    válasz totron #19127 üzenetére

    Szerintem fejezd abba az értetlenkedést. Még lassabban írom: nem lehet konkrétumot írni, mert ahány SSD, ahány modell, ahány gyártó, annyiféle optimalizáció van firmware szinten, ami a vezérlő low level működését érinti, ahogy a NAND lapokat, és benne a cellákat kezeli, meg a NAND és DRAM cache-t. De ugyanez van sokszor prociknál is a mikrokóddal. Nem, nem írok konkrétumot, mert általános jelenségről van szó, ami mögött az elvek számítanak, nem a mm-re pontos, konkrét példás fingreszelés, hogy azon vitatkozzál, hogy nem is 4 hanem csak 2% javulást hozna átlagosan teljesítményben, azt is csak bizonyos workloadoknál.

    Ez kb. olyan, mint ha a Windowsnál is azért vitatkoznál, hogy nem is annyiba kerül a licenc, hanem x ezressel kevesebbe, és különben is jól megyen rajta az Adobe szoftverpakk meg az AAA játékcímek, meg különben is SSD + kicsivel több RAM alatt ugyanolyan jól fut. Ki nem sz4rja le, nem a pénz, meg a Photoshop, meg a +5 fps játékok alatt, ez elvi kérdés, hogy általánosságban zárt forráskódú, vagy egyébként nem nyílt szabványos szutykot ne erőltessen senki, és ne támogassa kizárólagosan, ha nem muszáj.

    Ugyanez van a bloatnál, ezt nem értette múltkor ubyegon, hogy nem az számít, hogy x alkalmazás minimalizmusa szempontjból, hogy a 16 GB RAM-ból 1-10-100 MB-tot használ-e, vagy 10-100 csomag függősége van, vagy 10 vagy 100 MB terjedelmben, a lényeg, hogy ha valami megoldható egyszerűbben, hatékonyabban, kevesebb kódsor, kevesebb erőforrás felhasználásával, akkor az legyen használva lehetőleg, mert a végén a sok kicsi sokra megy, ha valakinek az a hozzáállása, hogy á kicsi, úgyse számít.

    Hardveres satnyaság sok van Linux alatt, igaz ezek túlnyomó részét nem annyira a hardveroptimalizációk okozzák, hanem a driveroptimalizációk, ez rányomja a bélyegét az energiagazdálkodásra, GPU drivereknél, játékoknál a futási teljesítményre a windowsos megoldáshoz képest.

    De ha akarsz, akkor rugózzál rajta még konkrétumokon, hátha megsajnálnak. Hidd el, ha konkrét példa kell, tudnék azt is írni, mint pl. régebbi Samsung és Crucial SATA SSD-k esetén firmwarebug (ami nem bug egyáltaláns, szándékos feature a Windowsra optimalizálás miatt) miatt a Linux kernel a queued TRIM feature-t feketelistára teszi, meg néhány régi gép SATA vezérlője inkompatibilis lesz vele. Biztosan lehetne még több ilyen példát találni, hogy pl. X Intel procira, Y dántumkor kiadott Z verziójú mikrokódfrissítés után Linuxon jelentősebben esik vissza a teljesítmény W alkalmazás vagy benchmark alatt, de mint írom már milliószor, nem a konkrétum számít itt, hanem a pofátlan, zárt rendszerre való optimalizálás, amit elvből nem kéne csinálniuk. Nem azért mert a 2% részedeséként mért szűk linuxos felhasználói tábor hőbörög, hanem szerveren, mikrokontrollerek nagy részén is linuxos rendszer fut már, ez kellően elég ok szerintem.

    Ez nem bizonygatás kérdése, ha nem vagy fogyatékos, akkor általánosságban belegondolva látnod kéne neked is, hogy ez egy gáz folyamat, amit nem kéne sem támogatni, sem erőltetni.

Új hozzászólás Aktív témák