- Kormányok / autós szimulátorok topikja
- Mégsem lettek annyira pénztárcabarátok az új Intel CPU-k
- Vezetékes FEJhallgatók
- Windows 11: miért nem vált mindenki?
- OLED monitor topic
- Apple MacBook
- Milyen HASZNÁLT notebookot vegyek?
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Gaming notebook topik
- Mini PC
Új hozzászólás Aktív témák
-
#61
Alaaf Pi
őstag
E.Kaufmann
#46
Alaaf Pi
őstag
válasz
E.Kaufmann
#46
üzenetére
Az NT-t, 2000-et mint OS szerettem a maguk idejében. Nem voltak olyan bloatware-k, és eröforrászabálók, mint a mai 7, 10, 11 Pro-k.
-
Talán úgy értett, hogy több volt a hardverspecifikus, egyedi finomhangolás, ami miatt nem feltétlenül bonyolultabb, de optimálisabb volt - határozottan kisebb erőforrással is jól működtek komplex problémák megoldásai. Ami ugye fáradtságosabb feladat mint pl az éáY-t ráengedni a notepadra szvsz.
-
#59
hapakj
őstag
vérjancsika
#55
hapakj
őstag
válasz
vérjancsika
#55
üzenetére
mert azok bonyolultabb API-k voltak
- he? Hogy lenne már a DX9 meg DX8 bonyolultabb api, mint a 11? -
#57
pengwin
addikt
vérjancsika
#55
pengwin
addikt
válasz
vérjancsika
#55
üzenetére
Ez a "hack" téma egy jogos észrevétel... lenne, ha Windows-on nem ugyanígy menne a dolog. Minden játék-specifikus driver frissítés és "optimalizáció", meg "0 day support" igazából ugyanilyen hack-eket jelent.
Nekem az a tapasztalatom, hogy a DX9-től felfelé nagyon jól működik a Vulkan-ra épített köztes réteg. Talán nem véletlen, hogy pl. az Intel windows-os meghajtói is ugyanilyen módon oldották meg a kompatibilitási gondjaikat "régi" (értsd: DX12/Vulkan előtti) játékokkal.
Azt most hagyjuk is, hogy 2025-ben mennyire releváns a DX7 támogatás. Meg arról se beszéljünk, hogy az ilyen szintű visszafelé kompatibilitás a Windows-nak sem feltétlen erőssége, a lehetséges megoldások meg igazából ilyen 2012-es desktop linux-szintű buherálást jelentenek.
Egyébként meg nem vagyok hívő - csak elegem lett abból, hogy folyamatosan a megvásárolt OS-em ellen küzdjek, meg kifogásokat keressek a hülyeségeire, regresszióira, és felhasználó ellenességére. A desktop linuxnak is megvan a maga ezernyi baja, csak itt úgy érzem legalább egy irányba igyekeznek a fejlesztők és a felhasználók... meg látványos haladás történt. És nem varázslat, hanem hihetetlen mennyiségű fejlesztés, ahogy wasd is írta. Most kezd beérni az, ami annak idején az AMD Mantle távlati igérete volt: megcsinálták a technikai alapokat ahhoz, hogy más cégeknek (pl. Valve) reális alternatíva legyen a további fejlesztés.
-
#56
wasd.hu
senior tag
vérjancsika
#55
válasz
vérjancsika
#55
üzenetére
Nem igazán áll ez a hívő dolog. A hsz olvasásának végére arra jutottam, hogy régen tudtak programozni az m$ csapatában.
A Vulkan modern és alacsony szintű API. A Proton/DXVK nem egy átlagos wrapper, hanem komplett újraírása a graf veremnek. A GPU meg tényleg ugyanazt a munkát végzi, ez igaz.
TLDR
Ez nem a "Linux csodája". Ez teljesítmény kérdés amit a Valve és a közösség pénzelt és épített. Az érveid pont alátámasztják, hogy ez nem varázslat, hanem kemény munka – és pont emiatt olyan sikeres. Az, hogy ma már egyáltalán el tudjuk ezt a párbeszédet folytatni, az a sikerük legnagyobb bizonyítéka. Most pedig VM-ből kiixelem a 25H2-t, mert hemzseg a bugoktól és még ezt a pár percet is kár volt rászánni. Tökmindendegy mi volt az alap OS alatta. -
#55
vérjancsika
kezdő
pengwin
#54
vérjancsika
kezdő
Akárhányszor ezt hallom valamelyik hívőtől, mindig eszembe jut, hogy elfelejti hozzátenni, hogy
1) DX11-et igazából nem nehéz wrappelni, szoftveres frontend amúgy is elég vékony, a játékok többsége gpu-bound, ezért áll elő az a meglepő helyzet, hogy a gpu mindkét platformon ugyanakkora sebességgel fut (de persze ezt nem lehetett a hulladék OpenGL-lel megcsinálni, és a wined3d-fejlesztők sem éppen a legtehetségesebbek a világon, szóval csakis ezért tűnik ez most "csodának")
2) Ahogy megyünk lentebb, DX9, 8, egyre szarabb az implementáció és a kompatibilitás, mert azok bonyolultabb API-k voltak
3) DX7 és lentebb: ne is beszéljünk róla, ott már megáll a tudomány, az egyetlen mentsvár a 100 éve "fejlesztgetett" wined3d, de az is elég tré
4) Ennek ellenére tele vannak ezek a wrapperek mindenféle hack-ekkel, nem az API-implementáció pontossága a fontos, csak hogy az ismertebb címek fussanak valahogy
5) Hack alatt értem azt is, hogy az adott API-ból implementációs részletek hiányoznak, ebből következően gyorsabb is lehet, ha a rendering cpu-bound
-
#54
pengwin
addikt
Hieronymus
#52
pengwin
addikt
válasz
Hieronymus
#52
üzenetére
& #53 E.Kaufmann
DXVK nagyon is jól működik, köszöni szépen. Elég "fullos" DX játékok futnak rajta hibátlanul, a Windows-on várható teljesítménnyel vagy akár még gyorsabban is. PL. Cyberpunk 2077.A windows-os kernel-szintű anti-cheat szemét nem működik Linuxon, ami sokkal nagyobb "probléma" a sok online játék miatt. Addig jó, amíg ilyet nem is lehet linuxon csinálni.
-
#53
E.Kaufmann
veterán
Hieronymus
#52
E.Kaufmann
veterán
válasz
Hieronymus
#52
üzenetére
Én úgy tudtam, hogy "csak" a DX12-vel vannak gondok, a 11-re van már gyors wrapper. Jó hát nem natív, de úgy tudtam, sok játék fut már akár jobban is, mint Windows alatt.
-
#52
Hieronymus
veterán
E.Kaufmann
#51
válasz
E.Kaufmann
#51
üzenetére
Megvannak azok a hibák, csak máshogy. A teljes DirectX támogatás hiánya Fájó pont lehet a játékosoknak.
-
#49
bambano
titán
E.Kaufmann
#46
bambano
titán
válasz
E.Kaufmann
#46
üzenetére
Azt látom, hogy újabb és újabb megoldásokat, workaroundokat találnak ki arra, hogy elfedjék a hibákat, ahelyett, hogy kijavítanák azokat.
-
#47
Pötyi
őstag
E.Kaufmann
#46
Pötyi
őstag
válasz
E.Kaufmann
#46
üzenetére
Nem csak "terv" volt, a NT 4.0 telepítő cédéjén rajta van a Digital Alpha-hoz való verzió is.
-
#46
E.Kaufmann
veterán
Alaaf Pi
#42
E.Kaufmann
veterán
Ahogy bambano írja, kompatibilitás, de ugyanakkor meg lehetne húzni egy határt, hogy minden régi alkalmazás valamilyen VM-ben vagy konténerben fusson, míg az újak meg már kapnak valami új direkt API-t. (csak ne olyat, mint a metró/modern app-ok
![;]](//cdn.rios.hu/dl/s/v1.gif)
)
Maga a WinNT amúgy egy rendkívül rugalmas alap volt annak idején, gondolom, még most is, csak kikopott alóla pár architektúra és felőle pár API (annak idején pl tervbe volt a Unix szerverek piaci részesedéséből lecsípés, és volt bennne hozzá API szintű támogatás) -
#44 Alaaf Pi #43 #30 bambano
Az a helyzet, hogy az m$ mindent megtesz. Jelenleg a világ lehatékonyabb marketing stratégiáját végzi a win. Már-már iparági best practice-ként kergetik a PC-játékosokat a Linux és Proton karjaiba. Számomra friss feature a Security - SmartctApp Control.CB2077 és Hitman3 helyre jön a kikapcsolásától. Természetesen a fanboyok majd elmagyarázzák, hogy nincs itt semmi látnivaló, mégis ez évek óta kitartó következetes rombolásnak hat. Éveken át ugyanaz a séma ismétlődik, az már nem véletlen — inkább egy üzleti modell
Steam és a Linux natív reklámjait akár „Powered by Win" logóval is elláthatnák.
-
#40
wasd.hu
senior tag
Hieronymus
#39
válasz
Hieronymus
#39
üzenetére
Mintha tényleg más lenne a háttérben. Van egy teóriám.
Három évtizednyi szabályozás, szigorítás, kriptográfiai előírás, fegyelmezés, bedurvulás után a Windows-ökoszisztéma stabilitása már tényleg csak egy karnyújtásnyira van -
#39
Hieronymus
veterán
A hitelesség kedvéért.
1996. A Windows 95 megjelenése után a Microsoft felismerte, hogy a hardvergyártók által írt driverek gyakran instabilak vagy inkompatibilisek voltak. Ennek kezelésére létrehozták a WHQL-t, amely tesztelte a drivereket, és a sikeresen megfelelők megkapták a Microsoft aláírását (digitális tanúsítványt). Ez biztosította, hogy a felhasználók megbízhatóbb, stabilabb rendszert kapjanak.
Digitális aláírás kötelezővé tétele.A Windows XP (2001) idején a Microsoft elkezdte erőteljesebben megkövetelni a digitális aláírást a drivereknél.
A Windows Vista (2007) hozta a nagy váltást: 64 bites rendszereken kötelezővé vált a Microsoft által aláírt driverek használata, különösen kernel-módú drivereknél.
2021-től a Microsoft lett az egyetlen hivatalos kiadója a kernel-módú driver aláírásoknak.
2023-tól további szigorításokat vezettek be: a kódaláírási kulcsokat FIPS 140-2 vagy Common Criteria EAL4+ szintű hardveren kell tárolni.
2025-ben új tanúsítványhatóságokra állnak át, mivel a korábbi 15 éves CA-k lejárnak.
(Kerekít) 35 év sem volt elegendő a megbízható Windows driverek kierőszakolására.
Bár azt nehéz elhinni, hogy mostanság a frissítési hibák, kizárólag a driver problémákra vezethetők vissza.
-
#36
bitblueduck
senior tag
Tamás88
#4
bitblueduck
senior tag
Remélem megszünteti azt a lehetőséget, hogy kernel szintű anticheatek működjenek
EZ.
nekem is egybőlez ugrott be.
-kernelbuherálás megszűntetése olyan baromságoknál mint drm meg anticheat
-lenovo, asus, stb gyártóknak a malware-jével is kéne kezdeni valamit, mert szörnyű amikor egy rgb szoftver telepitése kb nemzetbiztonsági kockázat
-saját házuk táján ne legyen tragédia hetente egy windows update
-utána lehet normál driverekkel foglalkozni -
#30
bambano
titán
E.Kaufmann
#29
bambano
titán
válasz
E.Kaufmann
#29
üzenetére
Nem az a baj, hogy ütemezik a javításokat, hanem az, hogy alig van olyan javítás, ami nem töri el a rendszer többi részét. Néha igen durván. A patch keddnek nem arról kellene szólnia, hogy alapanyagot rakunk a rendszerbe a jövő heti patch keddre.
lásd még: [link]
-
#28
noPublicFG
senior tag
Azt várom ettől a lépéstől, hogy nem kell többet a HP
sz@rnyomtató-drivereivel többet kínlódni! -
#25
E.Kaufmann
veterán
paljani
#23
E.Kaufmann
veterán
Előző munkahelyemen is jól működött a NT4, igaz csak HMI-t bíztak rá
De amíg nem volt hw gond vele, addig nem kellett piszkálni. Akkor meg jobb esetben hw csere rosszabb esetben mentésből visszatolni. Valahogy az NT4 még szerencsére nem volt annyira háklis a hw cserékre, mint az újabb Windows-ok, meg az aktiválás se volt még divat 
-
#24
vérjancsika
kezdő
bambano
#21
vérjancsika
kezdő
a kérdés nem az, hogy védelmi szintet váltani drága-e, mert azt muszáj megtenni. A valódi kérdés az, hogy 3-asról 0-sra váltani mennyivel drágább, mint 3-asról 1-esre. Szerintem semennyivel. Tehát simán lehetne érdemi teljesítményveszteség nélkül használni mind a 4 ringet.
User szempontból talán, mert ott csak a 3-as szintről váltasz valamelyik kernelszintre. De ha kernelen belül vagy, és ott kell pl. driverbe hívásoknál szintet váltani oda-vissza, az már drága. Tehát nem 1 darab váltás lenne, hanem potenciálisan sokkal több. Még így, 2 szint mellett is arra megy ki az optimalizáció, hogy lehetőleg mindent usermódban csináljon a user kód, és a lehető legkevesebb kernelbehívás kelljen. (erre vannak pl. az io_uring-féle megoldások input-outputra, de megemlíthetjük akár a user módú graphics command list submitálását is, vagy a sima "futex" koncepciót, ami csak tényleges blokkolás esetén hív bele a kernelbe)
Amúgy sem látom értelmét a kernel szintezésének, mert adott szinten belül több független komponens is fut. Mi van akkor, ha valamelyik korrumpálja a többit mondjuk az 1-es szinten? Oké, a kernel nem omlik össze, de mit csinál ilyenkor? Kilövi a teljes 1-es szintet? Mert csakis egy adott komponenst nem tud kilőni, ahogy user szinten sem tudsz egy csakis 1 dll-t vagy thread-et force-olva kilőni úgy, hogy a teljes processz állapota biztosan konzisztens maradjon.
Az eredeti mikrokerneles elképzelés az, hogy minden driver és ilyen-olyan komponens teljesen el van szeparálva egymástól, külön címterekkel, ahogy a user módú processzek is. Na, ez lenne csak az igazán drága implementáció.
#20-ra akartam válaszolni -
paljani
senior tag
"...erősen véleményes, mert a vms rendesen működött, az nt meg nem. meg azóta se egy windows szerver se..."
Emmelyik VMS? A monolitikus kerneles?
Amúgy amikor látok ilyen "avindózszerverSOSEMműködöttrendesen" típusú kommentet, akkor a szakmaiság megy a mosoly/popkorn.meg gyün mert garantált a jó szórakozás. -
#20
bambano
titán
vérjancsika
#19
bambano
titán
válasz
vérjancsika
#19
üzenetére
"a különböző szintek közti váltogatás hardveresen amúgy is drága": a kérdés nem az, hogy védelmi szintet váltani drága-e, mert azt muszáj megtenni. A valódi kérdés az, hogy 3-asról 0-sra váltani mennyivel drágább, mint 3-asról 1-esre. Szerintem semennyivel. Tehát simán lehetne érdemi teljesítményveszteség nélkül használni mind a 4 ringet.
"szoftveresen is csak bonyolítja az API-kat.": kb. semmilyen magasabb szintű apit nem bonyolít, merthogy ott már láthatatlan az, hogy melyik szinten fut a kernelnek az a darabja.
"a 4 szintes VMS amúgy sem hozott akkora előnyt, amiért cserébe megérte volna a komplexitása": ez erősen véleményes, mert a vms rendesen működött, az nt meg nem. meg azóta se egy windows szerver se. A vms-t még system jelszóval sem volt egyszerű felborítani. És persze az is kérdés, hogy azért volt a vms kernele bonyolult, mert 4 védelmi szintet használt, vagy azért, mert olyan szolgáltatásai is voltak, amikkel vagy 20-30 évvel megelőzött minden mást.
"abból nem lehetne 4 szintű rendszert varázsolni": miért ne lehetne? Másrészt meg az teljes tévedés, hogy abból indulunk ki, hogy a kernel fejlesztők kényelme a cél. Ha a világban látható helyzet, különös tekintettel az információbiztonság körüli dolgokra, igényli a biztonságosabb kernelt, akkor azt meg kell(ene) csinálni. 4 szintű rendszert csinálni bonyolult, de mindenféle marhaságokkal (selinux, apparmor, rust, stb.) próbálkozni a biztonság javítására, az nem bonyolult?
Emellett az is egy kérdés, hogy minek mennyi a valós hardver költsége. Ha egy mikrokerneles átállás azt jelenti, hogy ezentúl nem 95% idle a proci, hanem csak 90%, és a hálózati stackje nem 800Gbps-es elvi sebességet tud, hanem csak 650Gbps-t, akkor kit izgat?
Különben meg van mikrokerneles linux, ki lehet próbálni.
-
#19
vérjancsika
kezdő
pengwin
#15
vérjancsika
kezdő
Egyébként szeretném megkérdezni, hogy miért kernel meg user mód van?
Mert az NT kernelben a hardver (a cpu-val együtt) absztrakt, és a legtöbb cpu nem is támogatott csak user/kernel-t. Ha jól emlékszem az NT-be az x86 támogatás nem is az elsők között került be, más kérdés, hogy mára csak az maradt meg. Ja, meg most az ARM64.
Az NT-vel a portabilitás meg a teljesítmény volt a fő szempont, a különböző szintek közti váltogatás hardveresen amúgy is drága (x86-on 64 bites módban külön utasítások vannak a 0-3 közti váltogatásra), és szoftveresen is csak bonyolítja az API-kat. Valahol Cutler azt mondta, hogy a 4 szintes VMS amúgy sem hozott akkora előnyt, amiért cserébe megérte volna a komplexitása, szóval tanult belőle.
Az OS/2 sem állt a szuperstabil rendszerek hírében, pedig az mind a 4 szintet használta.A linuxot meg hagyjuk, az egy nagy monolitikus kőtömb, amit a fél világ farigcsál, abból nem lehetne 4 szintű rendszert varázsolni. Bár elméleti szempontból a mikrokernel a legjobb architektúra, és hardveresen még mindig nagy lenne a költsége egy ilyen implementációnak, ez a Torvalds-féle monolitikus megközelítés mint érv szerintem tarthatatlan. '92-ben még nem volt az, Tannenbaummal szemben, de ma már igen.
-
bambano
titán
A cikk arról szól, hogy az ms pr eseményt kreál abból, hogy akkor most már biztonságos lesz a driver.
Ami vicc, mert egyrészt eddig miért nem volt az, másrészt ami alapértelmezett kellene, hogy legyen, hogy nem gyártanak szemét programot, az miért pr esemény? Nem a technológiai kérdésekkel van itt a baj, hanem a parasztvakítással.Egyébként szeretném megkérdezni, hogy miért kernel meg user mód van? Az x86-os architektúra 4 védelmi szintet ismer, miért nem használják ki? (Mellesleg ezt a butaságot a linux is elköveti). Ha Cuttler bácsi meg tudott írni egy olyan oprendszert, ami képes volt 4 védelmi szinten futni, akkor az ms-nél miért nem?
-
paljani
senior tag
Ez nem technológia hanem elv (ami mentén az adott technológia fel/megépül) és nem láttam sehol, hogy bárminek is beállították volna magukat... ugyanis a kernelmódban futó drivereket nem (csak) maguk írják, hanem 3rd party fejlesztők a hardvereikhez hence a tanúsítványok szigorítása meg ezek "usertérbe" pakolása. Erről szól a cikk, esetleg olvastad?
-
bambano
titán
Az ms fő fejlesztője korábbi életében már letett egy rendes operációs rendszert az asztalra. Az ms utána átcsábította, de hogy miért nem használta fel a tudását, az, számomra, kérdés.
Ettől még igaz, hogy az ms már megint "feltalálta a spanyolviaszt", úgy állítja be magát, mint a nép megmentője, egy legalább 30-40 éves technológiára hivatkozva.
-
Azt lehetne, hogy ugy "durvuljanak be" ezek a redmondi idiotak, hogy legalabb egyszer lesz egy olyan honap, amikor a "frissiteseik" nem busznak el valamit? Vagy esetleg ne legyen kernelszintu privilege escalation ebben a sz.rban?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
:
Külön vicces, hogy más is félreértette.
Új hozzászólás Aktív témák
Hirdetés
- Kormányok / autós szimulátorok topikja
- Filmvilág
- Samsung Galaxy Felhasználók OFF topicja
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- PlayStation 5
- Autós topik
- Mégsem lettek annyira pénztárcabarátok az új Intel CPU-k
- Disney+
- Fűnyíró topik
- Samsung Galaxy Watch6 Classic - tekerd!
- További aktív témák...
- Samsung 870 QVO 8TB Sata 2.5 SSD
- Samsung Galaxy S25 Ultra 5G 12/256GB Titanium Black használt, szép állapot 6 hónap garancia
- GYÖNYÖRŰ iPhone 13 Pro 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS4414
- Magyarország piacvezető szoftver webáruháza
- Bomba ár! Lenovo ThinkPad L380 i3-8G I 8GB I 128SSD I 13,3" FHD I Cam I W11 I Garancia!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest