Új hozzászólás Aktív témák
-
Spec
őstag
Oh, hát én nem is akarok tenni ellene, nem is tudnék. Kis hal vagyok én ebben az óceánban. Csak arra lennék kíváncsi milyen szabályozás vonatkozik ilyen esetekre, amikor valami rejtett hardveres hibát tartalmaz.
Igaz hogy lesz rá javítás, de az csak szoftveres megoldás, ami egyes esetekben teljesítmény romláshoz vezet(het). Ez meg egyértelműen a korábbi állapothoz képesti minőség romlás, vagyis fennáll a gyártói felelősség kérdése. Ha tudnák úgy javítani, hogy az semmilyen működésbeli eltérést nem okoz, pusztán a biztonsági rést "foltozza be", akkor szó se eshetne a kártérítésről, na de itt más a helyzet.
Ez kicsit olyan, mintha hibásan terveztetsz meg egy házat, ami miután megépült, kiderül hogy statikailag hibás, és mondjuk az egyik szoba megsüllyed, és ezáltal a ház azon része lakhatatlanná válik. Buksz az eredeti 100 m2-ből, mondjuk 20 m2-t. A kivitelező úgy orvosolja a problémát, hogy lefalazza neked a ház azon részét, hogy oda ne menj, mondván, hogy az nem biztonságos. A többit persze gond nélkül használhatod
"They were the only species to offer true resistance to the Borg." – Seven of Nine
-
sb
veterán
Ez azé' hülyeség mert ha valóban nem érinti a probléma az AMD-t akkor egy felesleges - és a számok szerint nagy, érezhető - lassulás.
Túlzó példa, de hátha leesik: A javításig kapcsoljunk ki minden gépet. MS, Amazon... otthon is minden felhasználó... és igaz, hogy azokat nem érinti, de az AMD-ket is kapcsoljuk ki... meg a hűtőket is húzzuk ki a konnektorból 2 hétre.
És hívjuk vissza az összes 5-ös BMW-t, hegesszünk a tetejükre egy T idomot nehogy kettétörjenek. Biztos ami biztos.Ennyi értelme van egységes patchet rálőni valamire ami nem volt hibás.
[ Szerkesztve ]
-
sb
veterán
Ez hibafüggő melyiket egyszerűbb és gyorsabb megoldani.
Ez a patch is valami hw-ben/mikrokódban létező funkció helyettesítésére jön ki. Tehát egy már létező megoldást helyettesít kvázi "kézi vezérléssel". Erről szvsz eldönthető, hogy vmi megoldja-e a háttérben vagy nem. Nem egy nagynyomozós, rejtélyes sztori első tippre kód szinten.Olyasmi mintha most azt mondanánk, hogy a Totalcmd file másolásra mindent másoljon át 3x mert tutiamibiztos. (flaming: mivel bizonyos Samsung SSD-kről eltűnik néha az adat
). De ettől még elég jól látható, hogy ilyesmi megoldás:
1. 1000%-ig megállapítható, hogy más, normális meghajtóra totál felesleges.
2. Tök könnyen szétválasztható, vélhetően semmivel nem egyszerűbb/gyorsabb megírni egységesen mint - durván leegyszerűsítve - két darab IF-fel.Nyilván os kódot nem ismerek, ha bonyolult szétszedni akkor jogos lehet, de ezt most innen nehéz elképzelni.
A garantálást nem érzem jó érvnek, mert ilyen alapon semmi sem garantált. Csak ha tényleg kihúzzuk a konnektorból. Azért ne fordítsuk ki a dolgot: attól, hogy kiderült egy súlyos hiba minden modellről és minden funkciójukról nem gondolhatjuk azt, hogy hibás.
-
sb
veterán
Még mindig nem értem mit nem értesz.
1. Most lett egy OS/kernel ahol a kernel-userspace szét lesz bontva OS szinten.
2. Eddig 10+ évig nem volt, mert volt rá hw-közeli megoldás, ami biztosította, hogy nem lehet átpiszkálni a másikba.Most kiderült bizonyos prociknál, hogy a 2. pont nem igaz. Megcsinálták a workaround-ot az 1. pont alapján.
- De minek mást csinálni? Ha másik procin nem jön elő?
- Vagy ennyi erővel van még 62 másik hw-s védelmi cucc: azt is iktassák ki egyúttal, mer' hátha hibás minden?
Lehet, hogy osztani se tud a proci? Láttunk már ilyet is.Érdem mire gondolsz, de totál nem logikus amit írsz ha behatárolható a hiba és annak tűnik.
Ha egy gyártó hibás implementációja okoz gondot akkor hiába biztonságos, totál felesleges lehet más gyártónál is ugyanazt a hibát keresni... vagy tök más hibát minden gyártónál.
Lásd a fent említett fdiv bugot. De egy rossz fékvezetéknél se hívják vissza a világ összes autómárkájának összes autómodelljét. Pedig lehetne, mert ez a fékezés k*va veszélyes dolog. Ha nem áll meg a kocsi kés a baleset. Ha meg az egyik szériában rossz a fék, ki tudja... biztosabb lenne előbb betiltani az összes autót és csak alapos fékvizsgálat után újra kiengedni őket az útra. -
MaUser
addikt
Már ne haragudj, de ekkora oltári baromságot hogy írhattál le? Most nem olyan apróságokról beszélek, hogy a részesedéses számaiddal is teljesen el vagy tévedve, hanem arról, hogy hogyan javítasz bármilyen függőségi hibát.
Ilyenkor szépen beleraksz a kódba egy statikus vagy jobb esetben dinamikus kapcsolót (lásd AMD releváns commitjára a reviewer első kérdését, hogy dinamikusan lehet-e így váltani), hogy csak ott javítsd a hibát, ahol tudod, hogy kárt nem csinálsz vele. Ellenkező esetben állhatnál neki a létező összes többi konfignál megnézni, hogy a javításod nem csesz-e szét valamit. Jó hogy nem már random register-t akarsz irkálni anélkül, hogy megnéznéd milyen procin fut a kódod, mert hát cpu-cpu hal-hal...
Remélem nem programozol...
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
MaUser
addikt
(sóhaj) - na pontosan ez a gond az IT piaccal.
Itt inkább alapvető logikával vannak gondok. Szóval te ha tudod, hogy valahol valami hibás, akkor nem azt javítod, hanem mindent(!) ami ahhoz hasonló, s aztán reméled, hogy nem teszel ezzel tönkre semmit? Ez a remek stratégia hol működik?
mesélj nekem a következőkről:
1. "a részesedéses számaiddal is teljesen el vagy tévedve" igen. amd alapú szerverek, laptopok, vállalati munkaállomások, asztali gépek száma az elmúlt 10 évből. nem a most kapható arányról beszélek, hanem a jelenleg létező összes gépről.Segítenél abban, hogy neked hogy jött ki a erre is a 95%+-os Intel részesedés, amikor pc prociknál 20% volt az AMD alja (lásd AMD üzleti jelentések)? Vagy szerinted szerver frontra legalább négyszer több procit adnak el, mint desktop/notebook/ultrabook/x86 tablet vonalra? Honnan vannak ehhez számaid, amikor még az Intel sem hajlandó ezeket közölni?
2. egy plusz biztonsági layer az oprendszerben (gondolom elolvastad a módosítás természetét) miben okozna gondot, amikor teljesen kompatibilis a mostani megoldással, csak sokkal konzervatívabb, túlbiztosított megoldás?
Honnan veszed azt, hogy a "módosítás teljesen kompatibilis a mostani megoldással", ha pl. azt az AMD nem is használ olyasmi ami a hibát okozza? Honnan veszed, hogy egy kikényszerített kódfuttatás az ő porcijaikon nem okoz gondot? Btw. az már bizonyított, hogy gondot okoz lassulásként...
3. mi köze ennek a processzorhoz (hogy okozhat kárt), ha ez eleve egy magasabb szintű, a processzor utasításkészletének megfelelő megoldás?
Minden amit egy procin futtatsz megfelel a proci utasításkészletének (ha a fordító is úgy akarja), aztán simán tudsz olyan kódot írni akarva-akaratlanul, hogy kékhalál/segfault legyen belőle.
4. miből látod biztosítottnak, hogy az AMD tuti 100%-ra nem érintett? ha nem így, máshogy? miből olyan biztos ez? ezt mindenki adottnak veszi, de volt feljebb egy részlet, miszerint az AMD-nél egy másik bug miatt van szükség erre.
Talán onnan, hogy egyelőre csak Intel és ARM esetén van érintettség kimutatva.
Mi a fenének javítanál valamit ami nincs és esetleg csak elrontasz vele valamit?amúgy nem, nem programozok. nekiesel te helyettem az egyik végéről a problémának, regiszterezel egyet, és hülyét is csinálsz magadból ingyér.
Milyen másik végéről beszélsz? Van egy technikai probléma, te meg hitvitát akarsz belőle csinálni minden áron...
intel, nvidia, amd, apple, android - ha bármelyik csoport ütközik bármelyikkel, felrobbannak a topikok. hiába na, a vallás kemény dolog.
Lásd előző pont...
Btw, logikád követve, kérlek, a biztonságotok érdekében dobjatok ki minden matracot a lakásotokból, hiszen nem rég volt egy hír, hogy néhány hónapig nem megfelelő matrac alapanyagot gyártottak. Bár elérhető, hogy milyen termékekbe került ez az alapanyag bele, de ne kockáztass. Égesd el a matracodat, hiszen a logikád ezt mondja, minek törődni a részletekkel, hogy érintett-e a matracod ez ügyben vagy sem. A földön alvás amúgy is jót tesz a gerincnek.
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
ribizly
veterán
Az egyértelmű, hogy az Intel uralja a szerverpiac jelentős részét. Ez az EPYC-el változhat, de még egyik gyártó szállít új AMD-vel szerelt szervert.
Azért a bigdata korában komoly gond lesz ez az akár "csak" 5%-os degradáció.
[ Szerkesztve ]
|•| https://hardverapro.hu/tag/ribizly |•|
-
MaUser
addikt
Gyönyörű terelés már megint, írsz butaságokat, aztán meg terelsz.
részesedés: meghagyom neked, hogy megkeresd, hogy a piacon lévő összes asztali és szervergép hány százaléka amd processzoros. ha több mint 5, akkor 6.
Értem, tehát beírsz egy sületlenséget, aztán meg nem tudod igazolni.
2. onnan, hogy az összes request arra irányul, hogy az amd-s megoldás a régi kódot futtassa. innen valószínűsíthető, hogy az új kód általános.
WOW, tehát "valószínűsíthető". Előbb még tényként közölted.
3. ezeket a hangzatos, egymás után írt szavakat lődd el egy házibulin.
Bocsánat hogy próbálom megértetni veled már sokadszorra miért mondasz butaságokat.
4. inkább olvass utána. még az AMD sem meri azt állítani, hogy nem sérülékeny, csak azt, hogy nem volt tesztelve, és "near zero" risk van. aha. az intel 10 éven át nem volt sérülékeny.
Honnan veszed ezeket? Link?
nem akarod megérteni, hogy több security problémára született egy "tuti" megoldás, ami biztonságos. ez az első szint: hiba elhárítva, van egy stabil, de lassabb megoldás, mehet ki a patch "élesbe", és után újrapriorizálni a feladatokat, és foglalkozni a kevésbé lényeges dolgokkal, pl. a gamer gépek ryzen teljesítménycsökkenésével. az általánosító hasonlataid nem ülnek az adott szitura.
Értesd már meg, hogy ez nem így megy. Pont abból van a "balhé", hogy hw specifikus problémát konfigurációtól függetlenül akarnak a kernelekbe berakni. Ilyet nem szoktak csinálni, a már általam ezerszer leírt okok miatt, amiket valami miatt nem nagyon akarsz megérteni.
amúgy meg, feljebb is írtam már, nem a programozók döntik el, hogy mi kerül egy patch-be, és mi nem. ők hibát keresnek, megoldásokat javasolnak, és fejlesztenek le. majd az architect vagy vezető eldönti, technikailag mi legyen a megoldás, az erőforrásokat prioritás és rendelkezésre állás alapján osztják ki a fejlesztéshez, és az üzlet mondja ki a végső szót. megértem, hogy programozóként nekiugranál, és millió ötleted van, de ez nem így működik.
Köszönöm, hogy leírod elképzeléseidet arról, hogy az az ipar amiben dolgozom, hogyan működik. Segítek, nem így, max. szappanopera álomvilágában.
Szerk: Közben Linus merge-elte az AMD által kért módosítást, erről ennyit.
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
Spec
őstag
Tök jó! És akkor én meg húzzak el a francba a Q2'12-es i5 3470-emmel? Meg még sok millió ember is akik ennél is régebbi processzorokat használnak a mai napig a gépeikben? Nem elég ez a blama az Intelnek, még szemközt is köpik a usereket, akik nem az újabb méregdrága processzoraikat használják? Nevetséges!
"They were the only species to offer true resistance to the Borg." – Seven of Nine
-
azbest
félisten
"nagyon itt lenne az ideje Android fronton annak a változásnak, hogy az oprendszert érintő frissítéseket a Google kötelezően teríti a készülékre"
Nem vagyok benne biztos, hogy az ilyen szintű hardver hibáknál lehetséges lenne-e bármilyen android oldali javítás az újabb rend szerint, ahol elkülönül a hardverkezelő rétegtől az android. A linux kernel és hardver driverek továbbra is az alsó, gyártió szintű részen vannak. A hardverfüggetlen alkalmazásoknál persze az android rész érvényesülhet, de a natív binárisra fordított alkalmazások valószínűleg ki tudnák használni a hardveres sérülékenységet. Max a store-os terjesztéssel, digitális aláírással lehetne ellenőrizni, hogy a hibát megoldó fordítóval készült -e az alkalmazás, de ez sem járható, mert mások is fordíthatnak rá.
-
Spec
őstag
Amúgy én megesküdnék rá, hogy magyarországi viszonylatban a PC-k több mint 60-70%-a 5 évnél régebbi processzorral üzemel jelenleg is. És ebbe beleértem az otthoni, az üzleti, és a közszféra IT infrastruktúráját is.
Konkrétan belelátok egy elektronikai hulladék hasznosító társaság mindennapjaiba, és látom, hogy selejtezésekkor milyen hardvereket visznek be hozzájuk. Jelenleg is még az esetek 80-90%-ban Win XP-s Pentium 4, és Celeron gépek mennek, itt-ott néha előfordul pár Dual Core, vagy Core 2 is már, de ez elenyésző. Egyébként még most is akad a horogra időnként pár PIII, PII, sőt még látok P1-es 486-os eszközöket is, persze ezek már kuriózum számba mennek.
Világviszonylatban lehet, hogy jobba a helyzet, de ott is csodálkoznék, ha a PC felénél többen lenne 5 évnél újabb CPU.
"They were the only species to offer true resistance to the Borg." – Seven of Nine
-
Spec
őstag
Ebben nem értünk egyet. Egész egyszerűen a mindennapi átlagos használatra, az esetek túlnyomó hányadában nincs szüksége modernebb, gyorsabb, erősebb vasakra. A hétköznapi mezei irodai dolgozónak, ahhoz, hogy a Word/Excelljét futtassa jó hatásfokkal, még egy jobb Core 2 Duo, vagy Quad CPU is bőven elég, 4 giga rammal, semmi szükség 7.-8. generációs sokmagos erőművekre.
Otthoni multimédiás, játékos téren is még bőven elegendőek a 3.-4. generációs Core i processzorok, akinek újabb van, az örülhet, de igazából aki nem multiplayer FPS vadász, annak nincs érdemben szüksége ennél erősebb gépekre.
Arról nem is beszélve, hogy mondjuk egy azonos órajelen futó 3. generációs és 7. generációs Core i processzor között jó esetben van kb. 10-15% teljesítménybeli különbség, ami azért nem mindenkinek éri meg egy teljes rendszer cseréjét 2-300k-ért. És ezt folyamatosan 4-5 évente meg főleg nem, bár értem én hogy a piac ezt diktálná, de azért nem árt az ésszerűség se.
Nyilván az Inteltől nem elvárható, hogy nyúljon vissza egészen a P4-ekig support terén, de azért egy 2010-12-es CPU esetében még elvárható lenne, ha egy súlyos sebezhetőség kerül napvilágra, akkor kiadnak valami foltot. Ha mégsem, akkor az óriási csalódás lesz az Intel-ben.
[ Szerkesztve ]
"They were the only species to offer true resistance to the Borg." – Seven of Nine
-
Wyco
tag
Persze csak normalis gepeket nehez venni, leginkabb ha az ember nem epiti hanem mondjuk nem ert hozza es vesz egybe. i3-as szintu gepeket sokszor csak keves memoriaval es sima HDD-vel lehet kapni, magyarul van egy passziv arukapcsolas, ha SSD-t akarsz ami mondjuk 500 GB korul van, (erre ne mondd h ez ordogtol valo igeny), ahhoz sokszor i7 szintu gepet kell venni, mert azt ugy aruljak. Persze epiteni egyszerubb de az atlag felh. nem fog epiteni. A laptopok eseteben a fenti allitasok duplan igazak. Aki ert annyira hozza h osszedobjon maganak egy gepet az meg vagy tudja mire van igenye, vagy legalabb azt hiszi h tudja.
BackToTheUKBlog:[backtotheukblog.wordpress.com] 2019/09/05: Brexitgráf IV — őrültek és csirkék háza
). De ettől még elég jól látható, hogy ilyesmi megoldás:
Mi a fenének javítanál valamit ami nincs és esetleg csak elrontasz vele valamit?
Új hozzászólás Aktív témák
ph A sebezhetőség miatt át kell alakítani az operációs rendszereket, ez 5-30%-kal is ronthat az eddigi tempón.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Politika
- Trollok komolyan
- EAFC 24
- Samsung Galaxy A54 - türelemjáték
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Vicces képek
- gban: Ingyen kellene, de tegnapra
- Übergyors Samsungnak próbál látszani egy hamisított NVMe SSD
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- Garanciális Intel Core i5-13600K
- Beszámítás! Intel Core i9-11900 Processzor - Garancia & Számla - Utolsó Darabok
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 88.000.-
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-