A Spectre/Meltdown javítások mellőzése

Security-all

Bizonyára minden fórumozó hallott már a Spectre és Meltdown sebezhetőségekről és a belőlük kialakult botrányról, melynek középpontjában jelenleg a processzoripar egyik éllovasa, az Intel áll. Az az Intel, amely úgy akart versenyelőnyhöz jutni a processzorai teljesítményét illetően, hogy átgondolatlan, biztonsági szempontból silány architekturális megoldásokat alkalmazott. Az elkövetett hibákat csak szoftveresen lehet orvosolni, és mert a hiba és javításának jellege is megkívánja, csak jelentős hátrányokkal és előnytelen kompromisszumokkal. Elképzelhető, hogy az Intel sales-esei és marketingesei ebből a slamasztikából végül új processzorok eladásával szeretnének kimászni, ahogy az is egyre inkább körvonalazódik, hogy az amerikai processzorpolip a tervezési és gyári hibás termékeinek köszönhető járulékos költségeket is igyekszik minden esetben a felhasználókra áthárítani, kiemelten gondolok itt az akár 30%-os lassulás anyagi következményeire.

Léteznek azonban olyan használati esetek, melyekben semmi szükség nincs a javításra, ahogy arra sem, hogy a lassulás miatt esetleg időelőtt új processzort (és vele együtt természetesen új számítógépet) kelljen vásárolni. Előfordulhat olyan is, hogy egy, a szakmájához és a biztonsághoz alapszinten értő informatikus, ha akarja, a javításnál sokkal erősebb védelmekkel is körbe tudja bástyázni rendszereit ahelyett, hogy ezt az operációs rendszertől várná el, kényelmi alapon. Ebben a témában folyamatosan frissítve összegyűjtöm azokat a megoldásokat különböző operációs rendszerekre, melyek a szóban forgó javításokat eltávolítják, azokat a rendszertől tartósan távol tartják.

Linux

Mivel az egyes disztribúciók alatt ugyanúgy Linux kernel fut, annak paraméterezésével könnyedén kikapcsolható bármely javítás. Mielőtt azonban átkonfiguráljuk a rendszert, tájékozódjunk arról, hogy az épp használt disztribúcióba bekerült-e már valamennyi javítás. Ehhez itt egy hasznos oldal.

  1. sudo vi /etc/default/grub
  2. Keresd meg a GRUB_CMDLINE_LINUX_DEFAULT kezdetű sort, ha nincs, csinálj egyet!
  3. Add hozzá a noibrs noibpb nopti nospectre_v2 nospec_store_bypass_disable paramétereket!
    GRUB_CMDLINE_LINUX_DEFAULT="noibrs noibpb nopti nospectre_v2 nospec_store_bypass_disable"

    5.1.13 kerneltől elég a mitigations=off paramétert megadni, de ez nem csak a Spectre/Meltdown javításokat tiltja, hanem az összes potenciálisan CPU-belassító szoftveres hardverhiba-tűzoltást. Ami desktop környezetben szintén jó ötlet és megtehető mindenféle reális biztonsági kockázat nélkül.

    noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off
  4. sudo grub-mkconfig -o /boot/grub/grub.cfg
  5. Indítsd újra a rendszert!

Windows

  • Windows XP / Windows Vista / Windows Server 2003
    • Mivel ezen verziók már nem támogatottak, így nem érkeznek rájuk sem biztonsági, sem egyéb más frissítések.
      Nincs teendő a Windows XP (32 vagy 64 bit) rendszereken.
  • POSReady 2009 / Windows Embedded Standard 2009
  • Windows 7-10 / Windows Server 2008-2016
    1. Start -> cmd.exe -> [Ctrl+Shift+Enter] (adminként indul)
    2. Add ki az alábbi parancsokat!
      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
    3. Indítsd újra a gépet!

BSD

  • FreeBSD
    1. vi /etc/loader.conf
    2. Írjuk be az alábbiakat!
      
hw.ibrs_disable="0"
vm.pmap.pti="0"

A topiknak nem célja a javítások szükségességének vitatása. Ide kizárólag gyakorlati megoldásokat és praktikus ötleteket várok, amik minél egyszerűbbé teszik azt, hogy a Spectre és a Meltdown javítások mellőzhetőek legyenek egy rendszeren, megőrizve a többi rendszerkomponens frissített állapotát és stabilitását.

  • 25979 megtekintés

Azért nem teljesen. Bár a lényeg valóban kimaradt. Azaz milyen célcsoportot, célterületet érint a téma.
Valóban léteznek azonban olyan használati esetek, melyekben semmi szükség nincs a javításra. Például egy videóvágásra szerkesztésre beállított pc-nél. Videózásra és zenehallgatásra használt HTPC-n szintén kérdéses a haszna. Vagy egy gamer pc-nél. A gamerek különben is roppant érzékenyek a pc teljesítménycsökkenésére. A lassulás pedig kár 13% fps csökkenést is jelenthet Ha pedig csak játékra használják azt a pc-t vagy a pc-n van egy külön gamer partíció dual-bootban akkor valóban felmerülnek kérdések a javító patchek hasznosságával kapcsolatban. A webböngészést azért nem árt hanyagolni ilyen esetben.

Normális HUP-ot használok!

A webböngészést azért nem árt hanyagolni ilyen esetben.

Ez is egy orbitálisan idealista kijelentés. Ha ismert, megbízható oldalakat látogat, az onnét jövő fenyegetések száma és esélye erősen konvergál a nullához. Ha kártevőkkel teletűzdelt random pornó, warezoldalakat nézeget, akkor pedig sokkal nagyobb az esélye, hogy egy 0-day böngészősebezhetőségen át lesznek ellopva az adatai. És még annál is nagyobb az esélye annak, hogy bitcoin bánya lesz a processzoraiból az oldal látogatásának idejére. Érdemes tisztában lenni a trendekkel és nem orrba-szájba riogatni mindenféle elvi lehetőségek alapján.

> Érdemes tisztában lenni a trendekkel és nem orrba-szájba riogatni mindenféle elvi lehetőségek alapján.

ezt magyarázd el az ötven éves szomszéd vízgázszerelőnek, akit kurvára nem érdekelnek a trendek, hanem egy erős best-effort, s hosszútávon érvényes tudást akar felszedni. vagy a kisiskolás diáknak, akiből ugyanúgy vízgázszerelő lesz, ha felnő.

mint ahogy engem sem érdekelnek az aktuális lakás-betörési trendek - erős zár, bezárt ajtó, biztosítás, riasztó. lehetne _optimálisabban_, mert a héten éppen nem törtek be senkihez az utcában? lehetne. ez bloat? igen, ez feleslegesen bloat. de nem érdekel, s nincs rá kapacitásom se, hogy folyamatosan a szomszéd utcák betörési statisztikáit figyeljem, s az ezzel járó kockázatot felvállaljam.

A praktikáiddal minimum az alábbi, marketing-bullshit által nem ismertetett kockázatokat vállalod fel.

  • Ha véletlenül kizárod magad az erős™ ajtóddal, sokkal drágább lesz kinyittatni és eredeti állapotára visszacsináltatni. Persze, tudom, nem zárod ki magad. Azonban egyértelműen többségben vannak az olyan régiói ennek az országnak, ahol sokkal többen zárják ki magukat, minthogy betörnének hozzájuk.
  • Ha betörnek és bejelented a káreseményt a biztosítónak, elképzelhető, hogy egy tisztességes biztosítási ügynök helyett egy profitfarkassal találkozol majd, aki elintézi neked, hogy a felét se kapd meg annak a pénznek, ami anyagi kár ért.
  • A riasztóval felvállalod azt a kockázatot, hogy a technikai fejlődésnek tervezett elavulásnak és a silány kínai minőségnek köszönhetően meghibásodik, és fals riasztásokat produkál, netán az őrületbe kergeti a környéken lakókat. Kisebb probléma, ha javítgatni kell (nyilván azért is te fizetsz). Nagyobb probléma, ha feljelentenek csendháborításért (azért már többet fizetsz).
  • Mivel a biztonsági ajtókból általában a legkorszerűbbet szerelik fel, és csak az tesz ilyet a házára/lakására, aki megengedheti magának, így felhívod a betörők figyelmét a lakásodra, akik, ha egy kicsit is profik a "szakmájukat" illetően, sokkal inkább tisztában lesznek az újabb, erősebb ajtók kinyitásával, mintsem állnak neki feszítővassal Mariska szomszéd néni 30 éves, egy záras faajtójának. Az oka ennek rendkívül egyszerű. Aki megengedheti magának a biztonsági ajtót, annak jóeséllyel van is mit "védenie" vele. Magyarul, ezzel megnövelted a saját lakásodba való betörés kockázatát. Gratulálok!

Persze, sokkal jobban megéri százezreket költeni erős™ ajtóra, biztosítást fizetni, riasztót beköttetni (+ villanyszámlát fizetni, javíttatni), mint békés környékre költözni, vagy a környéken élőkkel közösen összefogva, civil kezdeményezéssel polgárőrséget, társasházban portaszolgálatot üzemeltetni. Ezzel csak annyi a baj, hogy a fentieket szolgáltató nagyvállalatok (biztonságiajtó-multiék, riasztómultiék, biztosítóék) csak a kényelmes illúzióját adják meg a biztonságodnak. Gyakorlatilag pedig ugyanolyan sebezhető maradtál.

A betöréses hasonlatod pedig az alábbi szempontok miatt szélsőségesen idealista, irreális, csúsztató, egyszóval szar.

  • Nem kell naponta vagy hetente megerősítened az ajtót (= frissítés), néha akadályozva ezzel eredeti funkcióját is, a saját lakásodba való bejárást (= frissítés után elhaló rendszerek, bőven van belőlük).
  • Nem kell 5 évente új házat építened (= gépcsere az éppen biztonságosnak™ kikiáltott operációs rendszer egyre növekvő igényei miatt). Persze, ha a házépítést kínai, román, bolgár stb. vendégmunkások, vagy egyéb gazdasági rabszolgák megcsinálnák neked olcsón, akkor gondolom, ebből sem lenne probléma.
  • A házadat nem tudod le-backup-olni és visszállítani egy betörés után.
  • A rendőrség nagyságrendekkel könnyebben lenyomoz és elkap egy betörőt, mint egy kiberbűnözőt (még).

A frissítés-idealizmus nem más, mint a hardver- és szoftvergyártók kölcsönös piaci húzóerejére felépített FUD marketingkampány, melynek füstje és lángja kb. 10:1 aránylik egymáshoz. Egyértelmű célja a felhasználók félelmére alapozva, azok függővé tétele a frissítésektől, az új rendszerektől, ezáltal pedig az új rendszerek folyamatos vásárlásától. A tech-média szenzációhajhászata pedig csak erősít ezen, nem beszélve a fizetett lakájmédiákról, akik mindent megtesznek annak érdekében, hogy az őket eltartó tech-cégek érdekeihez fűződő megoldásokat villantgassák előnyös pozícióban, minden mást pedig legyalázzanak.

Abban is biztos vagyok, ha fair árat kellene fizetni a hardverekért (Európában élő, dolgozó, európai bérszínvonalon fizetett munkások állítanák elő, itt elérhető nyersanyagokat feldolgozva), nem párszázezer Ft lenne egy számítógép, hanem úgy 1-2 millió. Ami azért lenne jó, mert a csak pénzben gondolkodó, veddmegdobdki itteni fősodratú mérnökségnek, a nagytöbbséget alkotó birkatársadalomnak, illetve a szakmabéli IT-üzemeltetőknek és infrastruktúrával rendelkező cégeknek se érné meg kidobálni a gépet és felfognák, hogy mennyire fenntarthatatlan pazarlás lenne, ha ezt valamelyik hardver- vagy szoftveróriás a felelőtlen vagy vadkapitalista működésével kierőltetné (inkompatíbilis, azonos hardveren folyamatosan lassuló szoftverek).

Na látod! Még biztonsági frissítésekkel ellátott rendszeren is be lehet szopni de ahhoz kell a tisztelt user személyes közreműködése is. Biztonsági frissítések nélkül viszont mindezt megkaphatja egy távoli kódfuttatást lehetővé tevő exploit által. Ami böngészőn keresztül is betalál a gépre. Miután a malware megszerezte a kontrollt letölti a kövérebb ransomwaret és egy idő után jön fizetési felszólítás. Ha kellenek még a gépen levő adatok lehet vakarni a buksit.
A betörős ajtós példádnál van jobb ami szemlélteti sajátos álláspontodat.
Olyan mintha azt állítanád, hogy az autóban a biztonsági öv használata felesleges, "a biztonság hamis látszatát kelti". Még arra is találhatsz bőven példát amikor a bekapcsolt biztonsági öv okozta az autós halálát. DE a statisztikák azt mutatják, hogy nagyságrendi különbség van a biztonsági öv által megelőzött vagy megelőzhető halálos balesetek és a biztonsági öv által okozott halálos balesetek száma között. A számok azt mutatják, bekapcsolt biztonsági övvel sokkal nagyobb biztonságban van az autóban ülő személy mint nélküle. Természetesen a bekapcsolt biztonsági öv sem jelent 100% biztonságot. De ez nem érv ellene.

Normális HUP-ot használok!

Még biztonsági frissítésekkel ellátott rendszeren is be lehet szopni de ahhoz kell a tisztelt user személyes közreműködése is. Biztonsági frissítések nélkül viszont mindezt megkaphatja egy távoli kódfuttatást lehetővé tevő exploit által.

http://a.te.ervelesi.hibad.hu/hamis-okozat

Az igazság ezzel szemben az, hogy a biztonsági frissítésekkel ellátott rendszeren is be lehet szopni a távoli kódfuttatást lehetővé tevő exploit által terjesztett kártevőt. Úgy hívják: 0-day exploit. A frissítés után megjelenő zöld pipa által éreztetett biztonság illúziója hamis.

Ne hidd azt, hogy a fekete kalapos hackerek, vagy a bitcoin bányákat és DDoS farmokat üzemeltető botmesterek annyira el vannak kényelmesedve, mint néhány, errefelé elitkedő fősodratú mérnök úr. Ez nem úgy szokott menni, hogy kijön a sebezhetőségre a PoC, szoftverfejlesztőék kijavítják, de mivel a procedúra által open source lett, hackerék StackOverflow alapon lekoppintják, hogy aztán betámadják vele a rendszerüket nem frissítő hájbazereket. Ellenben, úgy megy, hogy megírják a 0-day exploitot birkáék frissített™, biztonságos™ rendszerére, megfertőznek vele elég gépet ahhoz, hogy elég nagyra hízzon a botnet, utána eladják a feketepiacon a sebezhetőséget és előbb-utóbb eljut fehér kalaposékhoz is, amikor is elkezdik majd foltozni.

Ha kellenek még a gépen levő adatok lehet vakarni a buksit.

Hájblézernek nem kell vakarnia a buksit, helyette stresszmentesen, nyugiban válaszolgathat hupuék kommentjeire. Azért van ez így, mert Hájblézer gondosan ügyel arra, hogy ne futtatgasson ismeretlen, megbízhatatlan kódokat. Ha pedig meg is kapná remote exploit alapon, pillanatok alatt visszaállítja backup-ból a számítógépét egy korábbi állapotra. Hájblézer elismeri, hogy frissítés nélkül használni egy rendszrt nem a legbiztonságosabb állapot, de sokkal többet megtesz emellett a biztonságáért, mint egy, a frissített operációs rendszerétől biztonságot elváró r=1 user, átlagbirka, vagy fősodratú mérnök úr.

A biztonsági öv használata nem felesleges, bár valóban haltak már meg miatta emberek. Az ő életüket sajnos nem lehetett backup-ból visszaállítani. Azokét sem, akik nem használtak és úgy haltak meg. Ámde, a biztonsági övet nem kell 5 évente cserélni százezrekért. A biztonsági övet nem próbálják meg úton-útfélen kikapcsolni, csak hogy leszívják a benzint az autódból. A biztonsági övről nem derül ki X év után, hogy nem biztonságos és csak az autó lelassításával lehetsz mellette biztonságban. Ha mégis, ezen a téren már van olyan jól bejáratott fogyasztóvédelem, hogy gyártói költségen cseréljék.

Természetesen a bekapcsolt biztonsági öv sem jelent 100% biztonságot. De ez nem érv ellene.

Sőt, attól még, hogy a biztonsági öv életeket ment, nem leszel vele nagyobb biztonságban akkor, ha hátradőlve kényelmeskedve, okostelefonozva, az utat nem 100%-osan figyelve hétvégi sofőrködsz, esetleg száguldozol, mint egy baromállat, mert neked nincs időd™ a vezetési kultúrára, a sebességkorlátozásra, vagy a biztonságos veztésre koncentrálni, ahogy bizonyos fősodratú mérnök uraknak sincs a betörési statisztikákra, vagy az informatikai biztonságra. Mindeközben pedig azt gondolod, hogy mivel úgyis bekötötted, nem érhet baj. Hát de. És itt a kör bezárul, visszaértünk az elejére, a hamis illúzióhoz, amit a frissítés megad.

Ott hibádzik a gondolatmeneted, hogy exploitot írni nem annyira egyszerű dolog. A gazdaságos megoldás a biztonsági frissítések elemzése, majd visszakövetkeztetés az eredeti hibára ha egyébként nem mellékel világos magyarázatot a fejlesztő mire is kell az sec update. Ha részletesen le van írva milyen hibát foltoz az update annál könnyebb. Innen azért jó pár day egy életképes exploit megírása. Na azokat lehet utána bevetni a biztonsági frissítést _nem_ telepítő userek gépei ellen.
A drágább és nehezen járható út sérülékenység vásárlása és elhalászása az eredeti fejlesztő orra elől. Ez már egyáltalán nem egyszerű művelet. Az ilyen infók alapján írt 0-day exploitok ellen pont annyira védtelenek a frissítéseket rendszeresen időben telepítő userek mint a frissítéseket nem telepítők.
Mit gondolsz, mégis miért szeretik pont patch kedd után terjeszteni a 0-day exploitokat?!
Elven az exploit írója is felfedezheti előbb maga a sérülékenységet. Ehhez szerencse is kell, elég nagy.
A zöld pipa nem jelent 100% biztonságot csak nagyobb biztonságot mint a pipa előtt volt.

"Ha pedig meg is kapná remote exploit alapon, pillanatok alatt visszaállítja backup-ból a számítógépét egy korábbi állapotra."
Pillanatok alatt? Ugye nem valami turbo streamert használsz a backaup pillanatok alatti visszaállítására (irónia) hanem snapshotot. Vagy esetleg virtuális géppel kombinált snapshotot?
A mostan elhíresült sebezhetőség történetesen pont lehetővé teszi a virtuális gépből való kitörést. Ha pedig csak sima snapshot van, akkor adminisztrátor jogok megszerzésével azok felett is megvan a kontroll.

Normális HUP-ot használok!

Én nem jelentettem ki, hogy nincsenek frissítésekben közölt hibákra vadászó hackerek. Annyit állítottam, hogy a 0-day exploitok esetében nem úgy működik, ahogy a frissítés-idealisták elképzelik és amivel birkáékat terelgetik ezügyben tech-lakájmédiáék.

Ráadásul, a frissítések alapján megírt exploitok definíció szerint nem is 0-day exploitok.

"A nulladik napi támadás (zero-day vagy zero-hour támadás) egy biztonsági fenyegetés, ami valamely számítógépes alkalmazás olyan sebezhetőségét használja ki, ami még nem került publikálásra, a szoftver fejlesztője nem tud róla, vagy nem érhető még el azt foltozó biztonsági javítás." - Wikipédia

Azt sem jelentettem ki, hogy egyszerű dolog lenne 0-day exploitot írni, azonban annyira bonyolult sem lehet, amennyiben az évente megrendezett hackerversenyeken (Pwn2Own, CTF stb.) 1-3 nap alatt képesek gyakorlatilag bármi közéjük odavetett, frissített™ hardvert és szoftvert darabokra szedni, az esetek többségében sikeresen. A fekete kalapos hacker ugyanezt megcsinálja otthon a sufnijában, amit vagy rögtön elad a feketepiacon, vagy előtte azért épít egy bitcoin-bányász vagy DDoS-ra bérbe adható botnetet, amiből megszedi magát. Amint kikerül a piacra, természetesen előbb-utóbb ismert lesz a cucc. Sőt, az is elég, ha egy lokálisan futó vírusirtó beküldi a gyanúsan viselkedő, kártékony kódot elemzésre. Ekkor elindul az a folyamat, ami a hiba feltárásához és javításához vezet. Amíg viszont ez nem indul el, ugyanúgy sebezhető vagy a frissített rendszereden. A 0-day fogalommal tehát azért nem célravezető dobálózni, mert pont hogy a frissített rendszereket is ugyanúgy támadhatod vele, mint a nem frissítetteket. Ha pedig ez nem igaz, az már nem 0-day.

Ehhez szerencse is kell, elég nagy.

Ahogy ahhoz is elég nagy szerencse kell, hogy a lejárt támogatású Chrome 49-em lejárt támogatású Windows XP-n futva pont az egyik megbízható oldalon botoljon bele injektált kártékony JavaScript kódba, amit még se malware listára nem tettek se nem fedezett fel senki. Pláne, hogy magát az injektált kódot se biztos, hogy az oldalt feltörő hacker írja, lehet hogy csak másolja valahonnan, ami jelentősen megnöveli az esélyét, hogy valamely víruskereső már ismeri. Ha pedig a megbízható oldalt valaki már megnézte egy víruskeresővel, akkor valamelyik malware-listán már ott csücsül a megbízható oldal címe, tehát Hájblézernél már nem fog betöltődni az általa használt uBlock-nak köszönhetően, ami malware listák alapján is blokkol.

Megjegyzem, én nem vagyok mindenáron a frissítések ellen. Még azt sem állítom, hogy frissítés nélkül azonos, vagy nagyobb biztonságban vagy, mint frissítéssel. Ebben még akár egyet is érthetünk. Viszont messze nem gondolom annyira veszélyesnek frissítés nélküli rendszert használni, mint ahogy a tech-lakájmédia és az azonos véleményen lévő, helyi hivatásos rettegők és fősodratú mérnök urak azt beállítják. Pláne, ha mellette sokkal lényegesebb dolgokat megteszel a biztonságod érdekében - utóbbiakat már említettem.

Ugye nem valami turbo streamert használsz a backaup pillanatok alatti visszaállítására (irónia) hanem snapshotot. Vagy esetleg virtuális géppel kombinált snapshotot?

Túlbonyolítod. Van egy 40 GB-os Windows XP boot és egy 460 GB-os adat partícióm, amit egy Macrium Reflect-tel differenciálisan hetente leimidzselek egy külső adathordozóra. Ez csak a különbségeket menti le és szükség esetén csak azokat állítja vissza, fájrendszerszinten. Utóbbi akkor járható út, ha észreveszek egy vírust a gépen és inkább szeretném visszaállítani korábbi állapotra, mintsem disinfect-elni a fertőzött fájlokat. Tíz perc alatt megvan a mentés. A visszaállítás se lehet sokkal több, bár még nem kellett élesben. Persze, ha jön a ransomware™, akkor vissza kell állítani az egészet, nulláról, az sokáig fog tartani. Erre viszont a fent ismertetett metodika miatt igen kicsi az esély. Az elmúlt évek nagy ransomware-viharait is rendre sikerült megúsznom, és nem gondolom, hogy ennek okai között a szerencse dominált volna.

"Viszont messze nem gondolom annyira veszélyesnek frissítés nélküli rendszert használni"

Azért azt tegyük hozzá, nem mindegy milyen filozófiával fejlesztett rendszerről van szó, Mert ha eleve halászháló mennyiségű lyukkal, 125 ezer trójai modullal, backdoor-al, szándékosan belefejlesztett hardveres hátsó kapukkal választasz rendszert magadnak, ott az update-k nagy része abból adódik, hogy a telemetria révén felfedezi az oprendszerfejlesztő csapat, hogy felfedezték és aktívan használják kiberháborus vagy egyébb célokra idegnek a saját bejáratukat. Innentől kezdve zárják a megismert ajtót, és nyitnak saját maguknak biztonságosabb még nem ismert módon működőtt. (A frissítés megjelenése után ez a kör persze indul újra.)

Na itt, - nyilvánvaló W10-ről beszélek, - nem nagyon jó ötlet kizárni a "frissítőket" mert a gépeden sokkal nagyobb erők találkoznak, mint amivel Te valaha is tudnál valamit kezdeni. Max, amit megtehetsz szurkolsz a "jó" csapatnak, amely gőzerővel és folyamatosan dolgozik a "belépő kapuk" tisztán tartásán.

Az általad favorizált XP még a "mindenek feletti telemetria koncepció" előtt jött létre, és a rendszer "keresztbe áll" egy kisebb kiberháborús "csorda" keresztül vonulásán, nem elég stabilan fut rajta a "botnet" vezérlőszoftver, gyakran lefagy a böngésző, ha rosszindulatú script indul a meglátogatott weblapról, stb...

(Ezért hát, mindkét oldalnak van oka sóval felhinteni a gépedet, és "felszántani" az ótvar öreg, még egy rendes "Meltdown"-hack-re sem alkalmas processzorodat. Eszükbe sem jut egy ilyen instabil rendszert a botnetbe illeszteni, mert ugye a leggyengébb láncszem lesz a hálózatban, a borulások miatt gyorsabban felfedezik a CC-t.)

Ritka eset az ilyen, de a hozzászólásod első felével (Win10 említéséig) egyetértek.

nem nagyon jó ötlet kizárni a "frissítőket" mert a gépeden sokkal nagyobb erők találkoznak, mint amivel Te valaha is tudnál valamit kezdeni. Max, amit megtehetsz szurkolsz a "jó" csapatnak, amely gőzerővel és folyamatosan dolgozik a "belépő kapuk" tisztán tartásán.

De, tudok vele valamit kezdeni. Például elzárom a lehetséges technikai útjait a betolakodóknak. Nem hagyok nyitva TCP/UDP portot a gépen, nem indítok el ismeretlen EXE fájlt, minimalizálom az ismeretlen forrásból származó futtatható (JS) webtartalmak megnyitását. Mindennek eredményét pedig periodikusan visszaellenőrzöm, akár több víruskeresővel egyszerre. Azt pedig remélem tudod, hogy a vallások hittérítésre használatos tanai is többnyire "sokkal nagyobb erőktől" való félelem felébresztésén alapszanak. Kezded megütni ezt a szintet, a többi fősodratú kollégáddal karöltve.

és a rendszer "keresztbe áll" egy kisebb kiberháborús "csorda" keresztül vonulásán

A rendszeremen nem vonult még keresztül ilyen csorda. Láttam azonban többször olyat, hogy Windows 10-ek a saját frissítéseiktől "álltak keresztbe".

gyakran lefagy a böngésző, ha rosszindulatú script indul a meglátogatott weblapról

Nem fagy le a böngésző. Nem is tudom felidézni azt a legutóbbi esetet, amikor ki kellett lőnöm Feladatkezelőből a Chrome-ot, mert lefagyott. Mondanom sem kell, most is arról írok.

Ezért hát, mindkét oldalnak van oka sóval felhinteni a gépedet

Oka lehet, hogy van. Esélye azonban már jóval kevesebb.

"Ráadásul, a frissítések alapján megírt exploitok definíció szerint nem is 0-day exploitok."

Hol írtam olyat, hogy ezek 0-day exploitok?!
Azért kezdtem ezzel, mert a frissítetlen rendszereket ezek a könnyű úton fejleszthető és nagy számban jelenlevő exploitok _is_ fenyegetik.
Később tértem rá a 0-day exploitokra. Olvasd végig újra amit írtam! Felesleges idézgetned a wikipediát pontosan ismerem a fogalmat.

" Pláne, hogy magát az injektált kódot se biztos, hogy az oldalt feltörő hacker írja, lehet hogy csak másolja valahonnan, ami jelentősen megnöveli az esélyét, hogy valamely víruskereső már ismeri. "

Fura, hogy ennyire megbízol a folyamatosan frissülő víruskeresődben, még az operációs rendszered minimális frissítésétől is ennyire tartasz.

Normális HUP-ot használok!

"Ez is egy orbitálisan idealista kijelentés. Ha ismert, megbízható oldalakat látogat, az onnét jövő fenyegetések száma és esélye erősen konvergál a nullához"

A szó amit keresel: pesszimista
s/idealista/pesszimista/g

Csak, hogy ne kerülj ellentmondásba saját következő mondatoddal. De nincs igazad.
Arról még nem hallottál, hogy teljesen tisztességes webportálokat törnek fel és injektálnak kártékony kódot oda a tartalom piszkálása nélkül?
Man in the Middle mond valamit?

Normális HUP-ot használok!

Persze, hogy hallottam.

Ahogy arról is hallottam, hogy Linux mirror-okat törnek fel és raknak rá backdoor-os csomagokat, amik pont a frissítéssel együtt jönnek le.

Arról is hallottam, hogy a tisztességes weboldalaknak van egy tisztességes webmesterük, aki eltávolítja a kártékony kódot.

Arról is hallottam, hogy amennyiben az előbbi nem történik meg, számos blokklista várja szeretettel a weboldal címét (MDL, Disconnect, Spam404 stb.).

Arról is hallottam, hogy Man In The Middle támadásnak sokkal kevesebb köze van a támadott rendszer frissítési állapotához, mint a használt hálózati megoldás biztonságához vagy az áldozat viselkedéséhez.

Bízom abban, hogy akik pont annyira tudják definiálni az "ismert, megbízható oldalakat" terminusz nemtechnikuszt, de pont annyira hiszik azt, hogy tudják, minél kevesebben fognak a neten keringve rátalálni erre a topicra, mert különben a net még annál is több szemetet fog okádni ezentúl, mint eddig.

Ja igen... ami itt még talán nem hangzott el, bár 20 éve hajtogatják/juk: ahogy a kanyaró ellen nem oltatás ("apám se kapta el!") sem tisztán magánügy, úgy a gép sebezhetően hagyása sem - az ezekre agitálás meg pláne nem.

A Windows XP felhasználása sokkal inkább késztet biztonságtudatos viselkedésre az Interneten és a számítógépem megfelelő karbantartására, mintsem karosszékben való hátradőlésre és a frissített™ = biztonságos™ rendszerembe való belekényelmeskedésre.

ahogy a kanyaró ellen nem oltatás ("apám se kapta el!") sem tisztán magánügy, úgy a gép sebezhetően hagyása sem - az ezekre agitálás meg pláne nem

Gratulálok, sikerült a ZDNet lakájmédia szélsőségesen idealista, demagóg és szenzációhajhász szintjére süllyedned.

A veled való vitát én itt ezennel befejeztem.

" Ha ismert, megbízható oldalakat látogat, az onnét jövő fenyegetések száma és esélye erősen konvergál a nullához"

Ismert és megbízható oldalak is tele vannak olyan külső forrásból származó komponensekkel (reklám, tracking) amik bőven kihasználhatják a hibát.
Ismert, és megbízhatónak vélt oldalak fejlesztői is lehetnek rosszindulatúak
Ismert, és megbízható oldalak is lehetnek megtörve úgy, hogy az üzemeltetőnek fogalma sincs arról, hogy a weboldalukba van ágyazva egy ismeretlen komponens. Erre konkrétan a napokban volt példa, egy futárszolgálat weboldalába volt ágyazva némi cryptovalutát bányászó kód, amiről az üzemeltető elmondása szerint nem tudott semmit.

Csak egy ilyenbe kell belefutni, hogy kompromittálódj. Aztán ha szerinted ez csak riogatás, hát gratulálok :)

( SzBlackY | 2018. 01. 11., cs – 08:38 )

Ebben a témában folyamatosan frissítve összegyűjtöm azokat a megoldásokat különböző operációs rendszerekre, melyek a szóban forgó javításokat eltávolítják, azokat a rendszertől tartósan távol tartják.

Ide kizárólag gyakorlati megoldásokat és praktikus ötleteket várok

Kezdésnek posztolhatnád azokat a különböző megoldásokat, amikhez nem kell OS frissítés.

Amíg ezt nem teszed meg, felelőtlen vagy, hogy bárkit az OS patchek eltávolítására bátorítasz.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Kezdésnek posztolhatnád azokat a különböző megoldásokat, amikhez nem kell OS frissítés.

Látom, sikerült elolvasnod többek között a Linux szekciót is.

felelőtlen vagy

Ha ebben a történetben bárki felelőtlen, az az Intel és a Microsoft. Akik se normális processzort, se stabilan működő OS patch-et nem voltak képesek kiadni. Hozzájuk nyugodtan mehetsz sírni, rólam viszont szálljál le az idealista hangulatkeltéseddel, és próbálj meg a témára koncentrálni!

Ha tudsz Windows-ra olyan megoldást, ami patch eltávolítása nélkül hatástalanítja a Spectre/Meltdown javítást, kérlek írd meg és frissítem a leírás megfelelő részét. Például egy Registry hack-et vagy egy BOOT.INI paraméterezést én is szívesebben látnék, csak sajnos ilyet még nem találtam.

Látom, sikerült elolvasnod többek között a Linux szekciót is.

Amiben leírod, hogy hogyan lehet kikapcsolni a KPTI-t. Akkor minek tetted fel az új kernelt?

próbálj meg a témára koncentrálni!

PONT ezt teszem, veled ellentétben minimális felelősségérzettel. Ha ugyanis a Linuxon kikapcsolod a KPTI-t, akkor ugyanúgy ott vagy, hogy a böngésződben lefutó JavaScript (tudod, amit bármelyik weboldal futtathat) képes kihasználni a sebezhetőséget. A kikapcsolás lehetőségét szvsz. leginkább azoknak tették be, akik szerveren futtatnak csak megbízható kódot és a teljesítmény-vesztést észre is veszik (vagy kompatibilitási gondot okoz vagy...).

ami patch eltávolítása nélkül hatástalanítja a Spectre/Meltdown javítást,

Ha egy bank széfjéről kiderül, hogy az egyik falán üvegablak van, amit egy téglával be lehet törni, arra nem az a megoldás, hogy ha megjön az acél védőelem, hogy inkább visszaküldöd a gyártóhoz. Használod az acél védőelemet és reménykedsz, hogy valaki kitalál egy ugyanilyen védelmet nyújtó, de mondjuk áttetsző fólia formájában használható védelmi eszközt.

És akkor vissza a Linuxos részre: nem kell hatástalanítani a Meltdown javítást (legyen az Windows/Linux/MINIX/akármi), mert az egy fontos védelmi vonalat (user process nem olvas kernel memóriát) próbál visszahozni. Ezért kérdeztem, hogy ha _helyette_ tudsz valami mást, azt oszd meg velünk is.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A Spectre PDF-ben adtak JavaScript mintakódot, ami processzen belül olvasgatja a memóriát (az se túl jó, mondjuk...), de ugyanezen az elven nem látom akadályát, hogy adott böngésző JIT-jére adjanak Meltdown exploitot is.

As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). The portion of the JavaScript code used to perform the leakage is as follows, where the constant TABLE1 STRIDE = 4096 and TABLE1 BYTES = 225

(ill. Firefoxék pontatlanabbá tették az órájukat, hogy ne lehessen kódból annyira jól mérni, de a PDF-ben arra is van "megoldás" (WebWorker))

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

nem kell hatástalanítani a Meltdown javítást (legyen az Windows/Linux/MINIX/akármi), mert az egy fontos védelmi vonalat (user process nem olvas kernel memóriát) próbál visszahozni

.. vs ..

A topiknak nem célja a javítások szükségességének vitatása.

Köszönöm szépen, hogy elolvastad a témanyitót. Másodszorra is.

Nem igazán értem azt se, milyen "védelmi vonalat" akarsz visszahozni, hiszen régen se volt ott védelmi vonal, csak hardvermultiék hót lyukas processzora.

Ha a bankok széfjeinek többségéről kiderül, hogy törhető üvegből van, nem saját költségen fog Mr. Rotschild acélt rendelni hozzá, hanem beperli a beszállítóját és garanciális cserét vagy kártérítést követel tőle. Habár, az első perek már megindultak és a részvényárfolyam is szépen esik lefelé, ahogy kell neki, mégse fog az ügy elszámoltatás része nagy méreteket ölteni, a fogyasztók veddmegdobdki birka hozzáállása miatt. Ezzel tehát csak arra akartam célozni, mennyire messzemenőkig szar a hasonlatod.

Bocs, itt ellentmondást vélek felfedezni:

"Ha tudsz Windows-ra olyan megoldást, ami patch eltávolítása nélkül hatástalanítja a Spectre/Meltdown javítást, kérlek írd meg"

Mivel a felvezetőben ezt írtad:

"a szakmájához és a biztonsághoz alapszinten értő informatikus, ha akarja, a javításnál sokkal erősebb védelmekkel is körbe tudja bástyázni rendszereit"

A fogalmazás nyelvtanilag azt sugallja hogy te a birtokában vagy ennek a tudásnak,
SzBlackY helyett neked kellene megosztani ezt velünk!

Nem értek a lovakhoz :) Éppen ezért nem is akarom letesztelni a sebezhetőség javítását. Így bízok azokban, akik értenek.
De nem is bíztatok senkit arra, hogy eltávolítsanak patch-eket, utána próbálgassák, hogy megborul-e a rendszer (megsúgom: nem fog), arra meg végképp nem, hogy sebezhetőséget teszteljenek a saját gépükön. Ráadásul virtuális gépen, ami azért nem ugyanaz, mint a natív.

Senki nem tart vissza, hogy írj egyet. Ha viszont annak is az lesz a végkifejlete, hogy nyeld be hardvermultiék nemtörődömségének rádhátékázását, a lassulás okozta többletköltségeket, meg hogy vegyél új gépet, akkor csak az idődet fogod pocsékolni. Mivel ezzel már tele van fősodratú tech-média.

amíg meg nem láttam az íróját

http://a.te.ervelesi.hibad.hu/szemelyeskedes

Más kérdés, ha csak biztosítási ügynököket megszégyenítő bullshit-generátorra, általánosítgatásra és üres szólamokkal való okoskodásra futja.

Komolyra fordítva, ha szerinted nem elég igazi™ vagy szakmai™ ez az összefoglaló, várom az ötleteid, hogyan lehetne az.

btw volt már olyan eset hogy ezt a a.te.ervelesi.hiba* -ot esetleg MAGADRA alkalmaztad ?

Mert kíváncsi lennék rá. Ha nem volt ilyen, akkor Te tévedhetetlen vagy mindenben és csak neked lehet igazad. Jól látom?

Ez miért van? Nincs benned olyan amire ezt a fenti szarURLt magadra húzhatnád? :)

(függetlenül mindentől, totál offtopic).

Te tévedhetetlen vagy mindenben és csak neked lehet igazad. Jól látom?

Rosszul látod.

Nincs benned olyan amire ezt a fenti szarURLt magadra húzhatnád? :)

Nos, amint a mélyen tisztelt fősodratú mérnök urak ..

  • nem a topiknyitó személye alapján ítélik meg egy téma komolyságát,
  • nem lassítják be a rendszerüket KPTI javításokkal,
  • nem játsszák a hivatásos rettegőt a biztonsági hibákkal kapcsolatban,
  • nem az operációs rendszertől várják kényelmeskedve és lustálkodva, a parasztvakító cloud-szolgáltatásokon csüngve-élvezkedve, hogy biztonságban™ legyenek,
  • nem vesznek 5 évente új gépet a fejlődés™ nevében,
  • nem mindent pénzben, költségben és megtérülési időben mérnek,
  • nem szarozzák, elavultazzák le a régi hardvereket, csak mert nincs rájuk megfelelő, hatékony szoftver,
  • nem keresnek önigazolásokat a Kínában gazdasági rabszolgákkal és gyerekmunkával előállított okostelefonjaik feltétlen szükségességére,
  • nem próbálják megmagyarázni, hogy minden jó ahogy van és ha megkérdőjelezem, akkor én vagyok az ostoba, mert nem vagyok egyszerre processzortervező-mérnök, informatikai-biztonsági guru és assembly-programozó,

.. akkor majd én is alkalmazom magamra az említett URL-eket.

Amíg ez nem történik meg, addig kiállok büszkén vállalt véleményemért és az igazamért, amibe semmilyen módon nem fér bele az, hogy saját magamat támadjam. Megteszik ezt amúgy is a fősodratú mérnök urak.

Tévedhetetlenséget sem az előző, sem az az előtti hozzászólásomban nem állítottam magamról, ez csak a te kényszerképzeted.

Az igazság a kritikával kapcsolatban pedig az, hogy magammal szemben is kritikus vagyok, csak nem pont úgy, ahogy Te vagy a fősodratú mérnök urak szeretnék. Például nagyon rossz véleménnyel lennék magamról, ha most bemennék a Media Markt-ba és vennék egy új laptopot.

Igen a tévedhetetlenség* jogos. lapoz.

Én csak arra akartam utalni, hogy neked itt _mindig_ igazad van. Azaz nem vagy kritikus saját magaddal szemben. Pedig lehetséges, hogy egy-két dologban tévedsz, nem ? És ehhez nem kell a MediaMartkba menni.

btw van egy IBM T42-es laptop eladó, érdekel? :P :)

Én csak arra akartam utalni, hogy neked itt _mindig_ igazad van.

Ezt sem mondtam. Ne próbálj meg olyat rám olvasni, amit nem állítottam. Én leírom a véleményemet, mások pedig eldöntik, hogy igazam van-e. Vannak olyanok is, akik szerint nincs igazam és kényszert éreznek arra, hogy a véleményem megtámadják, elhiteltelenítsék, vagy épp közelebb húzzák fősodratú copy-paste gondolataikhoz.

Azaz nem vagy kritikus saját magaddal szemben.

Az vagyok, csak nem kötöm az orrotokra. Felsoroltam, milyen esetekben fog ez megváltozni.

Pedig lehetséges, hogy egy-két dologban tévedsz, nem ?

De igen, lehetséges.

És ehhez nem kell a MediaMartkba menni.

Oda egyáltalán nem kell menni.

A laptopot köszönöm, de megtarthatod.

"nem az operációs rendszertől várják kényelmeskedve és lustálkodva, a parasztvakító cloud-szolgáltatásokon csüngve-élvezkedve, hogy biztonságban™ legyenek,"

Te bolond... KITŐL VÁROD? Adott egy hiba. Már megvan a baj. Mi a francot tennél? Vagy szoftveresen javítod, vagy hardveresen. Utóbbi pedig cserét jelent, ami miatt folyton sír a szád. Jót nem lehet ezek szerint tenni. Számodra az az egy elképzelhető jó, ha mindenki elsőre hibátlanul készít el mindent.

Te bolond... KITŐL VÁROD?

A saját tudatos felhasználói viselkedésedtől. A leggyengébb láncszem az emberi tényező. Akkor is, ha éles a KPTI javítás, akkor is, ha nem.

Nem én mondtam. Nálam és fősodratú mérnök uraságodnál is sokkal okosabb, tapasztaltabb és elismertebb ember mondta.

Számodra az az egy elképzelhető jó, ha mindenki elsőre hibátlanul készít el mindent.

Hízelgő, mikor helyettem akarod tudni, mi a jó. Részben talált, leszámítva az "az az egy"-et. A mondat helyesen: Számomra az a jó, ha mindenki elsőre hibátlanul készít el mindent. Ha ez nem sikerül (lévén, hogy nem vagyunk tökéletesek), akkor vállalja érte a felelősséget. Mondjuk az Intel a processzoraiért és a lassulásért.

Konkrétumokat, légyszi. Hogy oldod meg tudatosan, hogy ezt a hibát egy rosszindulatú fél nem használhatja ki nálad? Mert amit eddig mondtál az mind bullshit, és a jószerencsén múlik az, hogy még nem kaptad be a legyet (hacsak meg nem történt úgy, hogy nem tudsz róla), nem a saját tudatosságodon..

Nem akarok tudni helyetted semmit. Levontam egy következtetést abból, amit előadsz.

És ha az illető vállalja a felelősséget, akkor mi van? A hiba ennek ellenére létezik, a gond adott.

Sajnos nem fogunk úgy dűlőre jutni, ha neked minden, ami nem hivatalos™, valamelyik hardver- vagy szoftvermulti által eszközölt javítás, az bullshit. Így nem látom értelmét újra leírni, amit már eddig leírtam. Az pedig semmi esetre sem bullshit, hogy a uBlock/ScriptBlock szépen kiszűri nekem a JS kártevőt, ami egyébként is csak kétes oldalakon fordul elő. Az pedig - bármennyire is szeretnéd te, vagy a lakájmédia multiék profitját félelemkeltéssel és manipulációval biztosítani igyekvő bértollnoka - nem mindennapos eset, hogy egy megbízhatónak jelölt netbankot, facebook-ot, gmail-t feltörnek a hekkerek™, aztán onnan kapom meg. Ha mégis megkapom és sikeres a támadás, még mindig ott van a backup, ami offline, tehát nem igazán támadható. Ha ezt te bullshit-nek nevezed, akkor élj a gyártók által hivatalosnak kijelölt úton, fizess, fogyassz, vedd meg az újat, dobd ki a régit, mikor erre a reklámok és a fizetett tech-cikkek felhívást intéznek. Ha a saját biztonságodra való odafigyelés kimerül annyiban, hogy felrakod a frissítéseket, meg a hivatalos™ biztonsági™ megoldást™ (pl. Windows Defender), akkor valóban ez neked az egyetlen járható út.

Oké, de te meg legyél szíves beírni az OP-ba, hogy ezeket csak és kizárólag akkor ajánlott végrehajtani, ha
* van napi szintű, visszaellenőrzött, megfelelő biztonsági mentésed olyan adathordozón/formában, amit kártevő nem ér el (pl.: sima hálózati megosztásra felesleges felmásolni, mert amit te tudsz írni azt, azt a nevedben futó malware is fogja)
* együtt tudsz élni azzal a funkcióvesztéssel, hogy nincs JavaScript az oldalakon. (ez a megbízható oldalas izét meg légyszi pontosítsd, láttunk már olyat, hogy ad networkön keresztül a New York Times fertőzött: https://www.theguardian.com/technology/2016/mar/16/major-sites-new-york…)
* az alkalmazásaid, amik képesek 3rd party kód futtatására (böngésző, szövegszerkesztő [de, az], ...) megfelelően védettek (pl. olyan verziójú Firefox-ot használsz, amiben már a high precision timert visszarontották, Chrome-ban használod a laponkénti processzre bontást stb.)
* ...
Vagy gyakorlatilag air gapeled a gépet.

Ezen feltételek teljesülése nélkül kőkemény szerencsejáték, amit mondasz, és ha a "lakájmédia" által generált félelem miatt valaki nekiáll keresgetni és megtalálja a topicodat, ahol ezek nem szerepelnek (és nincsenek meg a usernél) és leszedi a javítást, ami ezek hiányában megvédte volna, azért Te vagy a felelős.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem leszek szíves beírni, mert itt nem téma a riogatás, másfelől jópár fősodratú beírta már kommentben.

Köszönöm szépen, hogy megosztottad velem és a nagyérdeművel a kisarkított, pesszimista, a hivatalos megoldást félelemkeltéssel az olvasók tudatába erőltető felhívásod. Aki akarja, úgyis elolvassa és tudomásul veszi (vagy nem).

ami ezek hiányában megvédte volna, azért Te vagy a felelős.

Az egyetlen felelős az Intel, aki döntési csapdába hajszolta a vásárlóit.

"ha neked minden, ami nem hivatalos™, valamelyik hardver- vagy szoftvermulti által eszközölt javítás, az bullshit"

Nem mondtam ilyet

"a saját biztonságodra való odafigyelés kimerül annyiban, hogy felrakod a frissítéseket"

Ilyet sem mondtam

Konkrétan azt szerettem volna látni, hogy hozol olyan épkézláb, támadhatatlan megoldási javaslatot a problémára, ami jobb mint az, ami jelenleg létezik, és komoly kompromisszum nélkül alkalmazható is egy átlag felhasználó számára.

Mert amiket korábban mondtál, azok nem ilyenek, vagy nem oldják meg a problémát, vagy téged is a biztonság hamis illúziójába ringatnak, vagy szimplán nem valósítható meg ésszerűen átlag felhasználás közben.

Ezért mondtam azt, hogy bullshit, nem azért, mert olyan nagyon támogatnám a multikat.

De tudod, könnyebb terelni. Könnyebb eljátszani, behazudni, hogy nem a te állításaiddal van probléma, hanem velem, mert én csak a csúnya gonosz cégekben bízom. Nevetséges.

Minden alternatív megoldás támadható, amíg mindenki a kisebb ellenállás felé kényelmeskedik és a nagy biztonság™ letudható egy frissítéssel.

Ezért mondtam azt, hogy bullshit, nem azért, mert olyan nagyon támogatnám a multikat.

A bullshit-ezéssel és az itt leírtak démonizálásával automatikusan támogatod a multikat.

"Azt hittem, komoly cikk"

A vicces az, hogy talán még az is lehetne. Nyilván a megfelelő vastagon szedett figyelmeztetésekkel, stb.

A baj, kedves Hajbazer, hogy a személyeddel, amit bemutattál itt az elmúlt egy évben a folyamatos kötözködő, beszólogató, arrogáns, önfejű, szakmailag kérdőjeles hozzászólásaiddal, elérted, hogy hogy nem vesznek komolyan, és ha valami hasznosat is próbálnál összeírni, kapni fogod az áldást.

Hát gratulálok :)

Nyilván a megfelelő vastagon szedett figyelmeztetésekkel, stb.

Szerencsére még semmilyen szabvány vagy szakmai kézikönyv nem írja elő a szélsőségesen idealista pesszimista, szándékosan riadalmat keltő, felelőtlen gigavállalatokat mosdató, döntési csapdákba hajszoló figyelmeztetések vagy üres előrevetítések kötelező feltüntetését. Ahogy azt sem sikerült még senkinek bebizonyítania, hogy ezek eszöközölésével lehet csak komoly témát kiírni egy fórumra.

A baj, Tisztelt Manfréd Fősodratú Mérnök Úr, hogy a hangadó kolomposok kötözködésnek, beszólásnak, arroganciának, önfejűségnek, szakmailag megkérdőjelezhetőnek tekintik azt, ha valaki a fősodratú véleményvonaltól szignifikánsan eltér és igyekszik a saját útját járni, a birkacsordához való csatlakozás helyett.

http://a.te.ervelesi.hibad.hu/kozvelekedesre-hivatkozas

Ami persze még csak nem is igaz, mert a "mindenki más" hozzászóló nem több, mint ~10 hasonló véleményen lévő hupu. Nyisd ki a szemed és olvasd el a többi hozzászólást is. Lehet velem normálisan beszélgetni, ha akarsz. Te nem akartál.

Általában normálisakat írok, normálisakkal indítok. Ezekre kapok normális válaszokat, azokat normális válaszokkal reagálom le. Kapok rá fősodratú, idealista, elitista, néhol megalázó, vádaskodó és szélsőségesen korporatokrata válaszokat is. Azokra másképp reagálok, nyilván nem véletlenül. Szerintem az utóbbiakkal van bajod.

A gyakorlatom azonban nem fog változni, amíg ilyen válaszokkal estek nekem. Alternatív opció, hogy ignorálom a fősodratú hozzászólásokat, a konfliktust elkerülendő. Csak akkkor meg azzal van bajotok, hogy hát erre meg miért nem válaszol a hájbazer, biztos azért mert nem tud rá választ, vagy mert nem ért hozzá, kerüli a kínos™ kérdéseket, netán el kéne ismernie, hogy tévedett.

A legnagyobb bajotok az, hogy képtelenek vagytok elfogadni, hogy másképp gondolkodom, és hogy nem csak a hivatalos vagy a hivatalosan elfogadott megoldás az egyetlen létező működő megoldás.

Te szánalmas gyökér, hagyd abba ezt a csúfolkodó mérnökurazós debil és gyerekes megnyilvánulásodat. Vagy tudsz értelmesen válaszolni, személyeskedés és szurkálódás nélkül, vagy ne tedd...

@trey, kitiltanád végleg ezt az oldalt mérgező szennyet innen?

+1

Barna, nagyon nincs itt helyed, megállás nélkül személyeskedsz és gyalázod az itteni közönséget - vedd észre végre, hogy nincs itt helyed, nem érnek célt a próbálkozásaid és keress egy másik helyet, ahol másokat gyötörhetsz a hülyeségeiddel.

Nos, páran idejöttek, elmondták a véleményüket megbélyegzés, személyeskedés, felelőtlenezés, gyalázás nélkül. Őket nagyon szívesen láttam, még ha az enyémtől eltérő véleményük is volt.

Aztán jöttek a fősodratú mérnök urak és elkezdtek személyeskedni, kötekedni, debilezni, gyökerezni, közhelyekkel dobálózni, riogatni, tech-lakájmédiában is fellelhető, copy-paste véleményükkel észt osztani. Én meg reagáltam rájuk. Olyan stílusban, amilyen stílusban jöttek, sőt, néha lájtosabban. Gondolom az megvan, hogy én nem hülyéztem le senkit, nem káromkodtam másokra és nem használtam szélsőségesen megalázó jelzőket valakinek a jellemzésére. A "fősodratú mérnök úr" sem ilyen.

Nem folytatok hadjáratot. Nyitottam egy szakmai témát valamiről, nevezetesen a Spectre/Meltdown javítások kikapcsolásáról. Külön kikötöttem, hogy nem vita tárgya, vagy legalább is nem itt (van 5 másik topik a témában). Hadsereg módjára ti, fősodratúak vonultatok ide, téríteni, felelőtlenezni, riogatni, hivatásos rettegőt játszani, szánalmasozni, gyökerezni. Nehogy véletlenül valaki ne lassuljon be 30%-ot.....

1. Nem én kezdtem a személyeskedést.
2. Most is te szánalmasozol, gyökerezel, debilezel.
3. Válaszoltam a kérdésedre.
4. Ne itt hősködj a kitiltásra való felhívással!
5. A "szánalmas, gyökér, debil, mérgező szenny" és a "fősodratú mérnök úr" között van egy árnyalatnyi különbség.

1. De te kezdted. Ne ezt a témát nézd, hanem a több hónapos hadjáratodat, amit folytatsz az oldalon
2. Most, igen. Bicskanyitogató a stílusod, és kinyílt a bicska.
3. Nem válaszoltál, tereltél
4. Nem hősködtem, illetve mégis miért te szabod meg, hogy hol tegyem? Egyébként megtettem a megfelelő csatornákon is.
5. Van. Vedd hozzá amit itt hónapok óta csinálsz, és máris megfordul az arány.

Pontosan tudod, hogy nem úgy kezdődik a történet, hogy én belekötök valakibe, elküldöm a fenébe, aztán az illető viszontszemélyeskedik. Ez most is úgy kezdődött, kedves manfreed, hogy idejöttél kötekedni. Csak nekem nem az az első dolgom, ha offolsz, vagy személyeskedsz, hogy rohanok apucihoz a "megfelelő csatornákon", aztán meg a feljelentgetett illetőt óvodásozom, meg debilezem le.

Egyébként is, ki a fene kérte, hogy gyere/gyertek ide okoskodni? Direkt leírtam a témanyitóban, hogy A topiknak nem célja a javítások szükségességének vitatása. Erre megjelensz te, a többi fősodratú kollégáddal együtt, és elkezded osztani az észt a felelőtlenségről, a szakmaiságról, nekiállsz offolni, régi állítólagos tőlem elszenvedett sérelmeid sebeit nyalogatni. Ha annyira kényszert érzel arra, hogy megmentsd hupuékat a gonosz hajbazer Spectre/Meltdown javításkikapcsolás-összeesküvésétől, akkor írjál cikket valamelyik mainstream újságba, amit jóval többen olvasnak majd, mint ezt a topikot. Alapvetően, ez a téma azoknak nyílt, akik szeretnének összegyűjtve, röviden tájékozódni arról, mit kell tenniük, ha ki akarják kapcsolni a javításokat, elejét véve a 30%-os lassulásnak. Én pedig ehhez is tartottam magam, az általam indított thread-ekben. Az, hogy reagálok, más kérdés. De már kezdem bánni, hogy reagáltam bármire is.

Úgy kezdődött, hogy idejöttem kötekedni? Valami gond lehet a hosszútávú memóriáddal :)

Rohanok apucihoz? Tényleg ez a szint, ahol megragadtál? Természetesen, ha van valami az oldalon, ami annak az élvezeti értékét rombolja, azt jelentem. Neked is szíved joga.

Szerk, erre még szeretnék reagálni:

"Egyébként is, ki a fene kérte, hogy gyere/gyertek ide okoskodni?"

Azt ki kérte, hogy te odamenj akármelyik másik topicba okoskodni, az igédet terjeszteni, aminek épp hogy csak marginálisan van köze ahhoz, amiről te beszélsz??? Nehogy már felhúzd magad olyanokon, és számonkérj olyasmit, amit az elmúlt közel EGY ÉVBEN te magad csinálsz folyamatosan?

Úgy kezdődött, hogy idejöttem kötekedni? Valami gond lehet a hosszútávú memóriáddal :)

Vagy épp a tieddel, bár nem volt az olyan régen. Idéznék az első hozzászólásodból, ami ebbe a topikba érkezett.

"Azt hittem, komoly cikk"

Nyilván a megfelelő vastagon szedett figyelmeztetésekkel, stb.

Az még oké, hogy beállsz a cikkemet komolytalannak nevezők sorába. Bár tény, hogy nem kérdezett senki és érdemben nem tettél hozzá a témához, a vélemény az akkor is vélemény.

A baj, kedves Hajbazer, hogy a személyeddel, amit bemutattál itt az elmúlt egy évben a folyamatos kötözködő, beszólogató, arrogáns, önfejű, szakmailag kérdőjeles hozzászólásaiddal, elérted, hogy hogy nem vesznek komolyan, és ha valami hasznosat is próbálnál összeírni, kapni fogod az áldást.

Az viszont már nagyon nem oké, hogy múltbéli dolgokat hánytorgatsz fel a sérelmeid alapján, a személyemmel dobálózol, azt hitelteleníteni igyekezel, egyoldalúan vádaskodsz, arrogánsnak, önfejűnek, szakmailag kérdőjelesnek nevezel és értelmetlennek ítéled bármiféle hasznos "összeírását" a részemről.

Ez simán kimeríti a kötekedés fogalmát. Pláne, hogy sem a múltbéli sérelmeid, sem az én személyes tulajdonságaim nem kapcsolódnak a Spectre/Meltdown témakörhöz.

Nehogy már felhúzd magad olyanokon, és számonkérj olyasmit, amit az elmúlt közel EGY ÉVBEN te magad csinálsz folyamatosan?

Ami pedig szintén nem igaz, ugyanis sokkal többet írok a saját témáimba, mint másokéba. Mellesleg, neked se kéne, hogy fájjon az ilyesmi, hiszen te ebbe a témába pont érdemi hozzászólás nélkül (lásd fent) jöttél ide, engem gyalázni. Most meg te játszod itt az álszentet, meg a feljelentgető hőst. Hát gratulálok.

Miért, az teljesen okés dolog, ha írok egy howto-t a Biztosítékok százas szöggel való helyettesítése címmel, beleírom, hogy "A topiknak nem célje a biztosítékok szükségességének a vitatása"?

Függetlenül attól, hogy valami fősodratú-e (ha van ilyen szó), vagy balmenetes, ne várd el, hogy senki ne írja le egy nyilvános fórumon, ha szerinte életveszélyes, amit javasolsz. Ez itt egy nyilvános fórum, ha valaki le akarja írni a véleményét, azt az oldal szabályai adta kereteken belül megteheti, legfeljebb lesz, akinek véleménye lesz róla. Ha valaki sokszor ír le olyat, amit a többség hülyeségnek tart, akkor előfordulhat, hogy a százegyedik alkalommal már csak annyit írnak oda, hogy "ez tuti hülyeség, mert az a fickó írta, akinek már az előző 100 írása is hülyeség volt". (Néha tényleg van olyan, hogy mindenki szembemegy a forgalommal, csak egyvalaki nem, de ez azért elég ritka.)

Más: a 30 % lassulásra van valami hihető mérésed? Az első javítás már kijött ubuntura, a számomra tipikus felhasználást elég jól modellező Mathematica Benchmark nem mutatott változást a gépen (i7-3770). 30 százalék lassulás már elég ok lenne utánanézni, hogy ez tényleg okoz-e ez az egész reális veszélyt az én gépemen; ha igen, akkor azért felraknám a javítást, de beírnék az intelnek egy nagy fekete pontot.

A biztosítékos hasonlatod amellett, hogy szar, túlzó, szenzációhajhász, riadalom- és hangulatkeltő. Nade erről ennyit, nem ez most a lényeg.

ne várd el, hogy senki ne írja le egy nyilvános fórumon, ha szerinte életveszélyes, amit javasolsz

A témakiírás nem az én véleményemről szólt, hanem a javítások kikapcsolásáról. Amiről nem mondtam, hogy nem életveszélyes, de azt se, hogy igen. A kikapcsolás egyébként csak a fősodratúak FUD-marketingrémálomvilágában "életveszélyes", de ez most mellékes. Azzal pedig, hogy intéztem egy felhívást, hogy nem vita tárgya, kértem valamit a közösségtől, mégpedig azt, hogy tartsák tiszteletben azokat, akik valamilyen oknál fogva, saját felelősségre szeretnék kikapcsolni a javításokat és ne vitassák el tőlük a saját döntésüket. Lévén, hogy egy szakmai fórum vagyunk, tele Spectre/Meltdown témákkal, szerintem mindenki könnyedén eléri a szükséges információkat az ügyben, máshol, gyakorlatilag az egész Interneten, ugyanis az egész tech-sajtó a sebezhetőség okozta nagy életveszélyektől™ hangos. Még az is oké, ha valaki leírja a véleményét, mert a fórum az fórum. Ami nincs rendben, hogy mindezt abszolút igazságként írja le (szemben azzal, hogy én a témanyitóban nem is foglaltam állást a kikapcsolás mellett vagy ellen), ráadásul mindezt riogató, személyeskedő, megalázó, magas lóról beszélő, elitista, az alternatívákat magasról leszaró és a megoldást kizárólag az lassításban vagy új processzor vásárlásában látó kommentek formájában teszi. Ez túlmutat a szimpla véleménynyilvánításon. Dehát ilyenek ezek a fősodratú mérnök urak, számukra csak a hivatalos™, nagyvállalati állásfoglalások és a marketing-bullshit létezik, azon kívül élni, azt nem abszolút igaznak venni életveszély™.

ez tuti hülyeség, mert az a fickó írta, akinek már az előző 100 írása is hülyeség volt

Így van, előfordul az ilyesmi, és általában egységsugarú, előítéletes, primitív gondolkodású, fősodratú mérnök uraknál. Nekik jön visszakézből az alábbi válasz: http://a.te.ervelesi.hibad.hu/szemelyeskedes

a 30 % lassulásra van valami hihető mérésed?

Nekem saját mérésem nincs. Nézzél szét itt vagy a másik 5 témában. Találsz eleget. Persze csak akkor, ha leveszed a nem akarom látni a lassulást, mert nem akarom látni az Intel kezét a zsebemben szemellenződet.

a) A biztosítékos hasonlat talán valamennyit túloz, de nem annyit, mint gondolod. Te azt hiszed, hogy nagy a túlzás, mert a biztosíték esetében osztod a többségi véleményt, hogy az tényleg kell. De biztos lehetsz benne, hogy van, aki úgy gondolja, hogy nála nincs semmi zárlatos, mert gondosan szerelte a villanyt, és megválogatta a készülékeit. A két dologban az teljesen párhuzamos, hogy van egy többségi vélemény arról, hogy valami veszélyes, és hogy ha azt csinálod, akkor nem csak magadat veszélyezteted, hanem másokat is, ezért, ha úgy csinálod, akkor nem vagy rendes srác. Lehet, hogy ez téves, néha igen kitűnő többségi véleményekkel is megesik, csak nem gyakran. Az viszont teljesen legitim, hogy az emberek nem szeretik azt, aki szerintük nekik plusz kockázatot/plusz munkát okoz.

b) Ez nem hiszem, hogy FUD-marketing, amit mondok, éss nem vagyok sem fősodratú (sőt, még csak nem is hiszem, hogy van ilyen szó, innentől, ha rám alkalmazod, kérlek vegyél magadra a részemről három durva sértést cserébe), sem mérnök (ezt viszont nem veszem sértésnek, általános tapasztalatom, hogy a dolgokat a tudomány kitalálja, a mérnökök megcsinálják úgy, hogy működjön, és a dilettánsok meg elbarmolják). Viszont úgy látom, hogy van lehetősége annak, hogy a hiba miatt adat szivárog ki, és sajnos nem láttam másik meggyőző megoldást ennek elkerülésére, mint a javítás. Abban nem hiszek, ha a felhasználó óvatosságával akarod megoldani, az ipari katasztrófák szinte mindig emberi hiba miatt történnek.

c) Azoktól, akik az adataimat kezelik, azt várom el, hogy a "best practices" szerint járjanak el. Nincs se időm, se energiám, hogy ellenőrizzem, hogy okosabbak-e, mint mindenki más. Járjanak el az iparági konszenzusnak megfelelően. Ha te nem akarod így csinálni, nem baj, csak nem akarom, hogy nálad vagy a munkáltatódnál legyenek az adataim. Ha nélkülem is lesz elég ügyfeletek, okés. Csak tudjak róla, hogy ott vagy.

d) Az előzőnek megfelelően, ha terjeszted, ne lepődj meg, mások is szeretnének vigyázni az adataikra.

e) Előítélet az lenne, ha azt mondanám, hogy már volt hat olyan fickó, akinek a nickjében volt h,j,b,r, és hülyeséget beszélt, biztos Hajbazer is hülyeséget beszél. Az, ha Te mondtál valahol ötször olyat, amiről valaki úgy gondolta, hogy hülyeség, és utána a hatodiknál már élből ezt gondolja, az nem előítélet, csak megismert. Ez nem szól arról, hogy kinek van igaza, az simán csak tapasztalat, hogy ha két ember ötből ötször nem értett egyet, akkor általában a hatodik alkalommal sem fog.

f) A 30 %-ra nem láttam értelmes mérést, sem az elhanyagolhatóra, sem semmire. Ezért is tartom elhamarkodott, kockázatos dolognak már R=1 pistikéknek is követhető howtot kirakni arról, hogy hogy kerüljük el a felrakását. Szerintem először ki kellene próbálni, és utána esetleg leszedni, ha van vele baj. És akkor is csak profiknak.

Ezzel mi a gond?
Amikor dolgozni kezdtem, a hétfők azzal indultak, hogy a műszakis kollégák bakapcsolták a gépeket. Az egyik még elektroncsöves volt... :)
Nem tudom, egy mai mainframe milyen/mekkora, de ha abból indulok ki, hogy anno a VAX-ok hogyan alakultak át, simán el tudom képzelni, hogy ezek is bírják a ki-/bekapcsolgatást... :D

Szenilis vagy édesem.
Egyrészt azt Hungerrel később e-mailben megbeszéltük.
Másrészt az SHA1 volt, nem 256
Harmadrészt, nem sokkal később valakinek sikerült is produkálnia, bár akkor én csak heccnek szántam... :DDD
(konkrétan Hungerről azt hittem, hogy azonos egy hasonló nikkű hülyegyerekkel, amiről kiderült, hogy tévedés - viszont asszem, ő is összefutott már vele)

Szóval ez...
Egyébként imádom az olyan embereket, akik képtelenek megkülönböztetni az iróniát, szarkazmust, öniróniát, egyéb humornak szánt dolgokat a véresen komolyan vett hülyeségektől. Lásd fentebb, amire először beszóltál. :DDD

> Szenilis vagy édesem.

te ilyen buzerans lehetsz

> Másrészt az SHA1 volt, nem 256

nem, a topikban meg csak megemlitve sem volt sha1, te pedig vegig sha256-rol szolo threadekbe okadtad a baromsagaid
nemmintha szamitana, ugyanolyan hulyeseg lett volna azzal is

> Egyébként imádom az olyan embereket, akik képtelenek megkülönböztetni az iróniát, szarkazmust, öniróniát, egyéb humornak szánt dolgokat

kommentedben (szokas szerint) humornak csiraja* sem volt megtalalhato, a "véresen komolyan vett hülyeségek" meg akar az alairasodba is mehetnenek, szoval annyira nem erint erzekenyen, hogy ebben az esetben epp nem gondoltad annyira veresen komolyan

*brotip: a senkit sem erdeklo szemelyes sztorik abbol az idobol amikor meg szamitto kozelebe engedtek nem szamitanak poenosnak

yes 'printf \\r8==mm=D;sleep .3'|sed p\;s/=mm/mm=/|sh -s

Ne is haragudj, de egy magadfajta, IQhiányos, ostoba faszkalappal nincs mit kezdeni. Maradj meg magadnak, és légy oly kedves a szádon távozó fingodat ne az orrom alá fújd! (a magadfajta gyengeelméjűek kedvéért: légy oly kedves és ne ugass bele abba, hogy mit csinálok!)

Egyébként meg szaladj te is trey-hez panaszkodni, hogy mocskolódni kezdtél, én meg elküldtelek anyádba! :D

( SchTamas | 2018. 01. 11., cs – 09:36 )

Szerencsére engem nem érint ez a probléma, mert magamévá tettem az életfilozófiádat, miszerint a régi is jó és azóta csak egy Sharp zsebkalkulátort programozok. A Word és az Excel kicsit akad rajta, de cserébe 100%-os biztonságban vagyok. ezekben ráadásul alig van mikroprocesszor és az se nem intel, se nem amd.

( uid_1526 | 2018. 01. 11., cs – 10:04 )

A kifejezés, amit keresel: Air gap

( xc0m v | 2018. 01. 11., cs – 11:23 )

Amelyik gép neten van az mindenképpen sebezhető, nem ?

Ez így van, de a frissítések pl pont kockázatcsökkentő tényezők lennének. Törekedni kell a minél hatékonyabb és frissebb védelemre a kockázatok csökkentése érdekében, még ha így leírva lózungnak is hangzik. Pl nézd meg a repülést vagy akár a tömegközlekedést. Nincs 100% garancia arra, hogy épségben odaérsz, ahová szeretnél, de törekednek arra sokféle biztonsági előírásokkal és eljárásokkal.

( btami v | 2018. 01. 11., cs – 11:40 )

Kösz! Még hasznos lehet alkalmi használatra, ha kiderül, hogy egy program, amit csak ritkán kell futtatni, elfogadhatatlanul lassulna a javításoktól.
--
♙♘♗♖♕♔

( asch v | 2018. 01. 11., cs – 13:06 )

Azon goldolkodtam, hogy tulajdonképpen honnan is jönnek a fenyegetések, amik ellen ez a patch véd? Tegyük fel, hogy a telepített programjaimban megbízok. Mit futtatok, ami nincs telepítve? JavaScriptet a böngészőben. Leginkább az a rémisztő, hogy ha JavaScript-en keresztül is kihasználható a bug, akkor egy rosszindulatú weboldal kernel-memóriát tud leakelni.

Szerintem logikus lépés lehetne a JavaScript JIT-et kikapcsolni, és tiszta interpretált módban futtatni. Erre van lehetőség?

És ha ki lehet kapcsolna a JavaScript JIT-et, akkor marad a kérdés, hogy vajon interpretált módban ki lehet-e aknázni ezeket a bugokat, vagy úgy már biztonságosnak tekinthető lenne-e a JS futtatás böngészőben?

Nálam ezért (is) van Scriptblock amin gyárilag a JS ki van kapcsolva és csak olyan, gyakrabban látogatott oldalakon engedélyezem amiben megbízom (valamennyire).
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

"Tegyük fel, hogy a telepített programjaimban megbízok" - az alapvetés rossz, pontosabban hiányos. A telepített programokban _és_ az általuk fogadott és feldolgozott adatokban is megbízva még igazad is lehet, bár nem szándékos károkozás (hibás/nem tesztelt inputra hibás működés következményei) még így, teljesen zárt rendszerben is előfordulhat. Oké, ez a két hiba lehet, hogy így (általad "megbízható"-nak tekintett szoftvernek adott speciálisan formázott adatokkal) nem használható ki, de remélem érzed, hogy hol a hiba a gondolatmenetedben.

Pont arra akartam kilyukadni, hogy a legtöbb program adatként és nem interpretálandó programként dolgozza fel az inputot. Az interpreterek és JIT-ek veszélyesek csak.

Nyilván pl videófelirat-fájlban is lehet támadó kód, de az ugye eleve egy más típusú támadás, nem az amiről itt szó van.

( asch v | 2018. 01. 11., cs – 13:33 )

16.04-es Ubuntun a legújabb frissítéssel lefagyott a VirtualBox VM boot induláskor. Az általad adott módszerrel megpróbáltam letiltani a patch-et, de úgy is lefagyott ugyanott. "Megoldásként" az előző kernelre visszatértem grub menűből (nem lett autoremove-olva), és azzal már működött. ("sudo dkms autoinstall" után, ami a vbox kernel modul újraforgatása miatt kellett, mert az valamiért le lett törölve időközben.)

Igen, azóta láttam, és a másik topikba bele is írtam, hogy ez már a "javított" vmlinuz-4.4.0-109-generic -kel jön elő, tehát ez egy újabb bug valahol a kernel-vbox tájékán (ugye az sem biztos, hogy kernel bug, lehet a VM hibája is, ki tudja). De a patch-csel összefügghet, mert a dráma előttire visszaállva működik.

( lcsaszar v | 2018. 01. 11., cs – 15:18 )

"Előfordulhat olyan is, hogy egy, a szakmájához és a biztonsághoz alapszinten értő informatikus, ha akarja, a javításnál sokkal erősebb védelmekkel is körbe tudja bástyázni rendszereit ahelyett, hogy ezt az operációs rendszertől várná el, kényelmi alapon"

Kicsit röstelkedve kérdem: hogyan is kell? Kérlek adj egy közérthető leírást, legyen mondjuk Windows 10 Home 64-bit Intel CPU-ra. Ezek a javításnál "sokkal" erősebb védelmek (lehet az elvileg tökéletes javítást még überelni?) amiket itt várhatóan ismertetsz, nem fogják lelassítani a rendszert egyáltalán, ugye?

Így is lehet. ;)

Aztán van az a scenario, amikor az ember fia nem lusta utánanézni, hogyan működik, amit használ és ennek a működésnek milyen biztonsági aspektusai vannak. Mindezek után lehetségessé válik összetettebb szoftverek biztonságos használata is.

Megjegyzem, én nagyon szívesen léteznék egy olyan világban, ahol minden mai internetes szolgáltatáshoz lenne wget és lynx segítségével használható felület. Picit jobb hely lenne ez a világ.

Kérlek mondd el te hogy védekezel a fenti hibák ellen.

Ajánlom figyelmedbe: Frissítés nélkül, biztonságban

Windows XP-t használok, lejárt támogatású Chrome-mal (49.0.2623.112), mert a Google tett róla, hogy az új verziók már el se induljanak rajta. Azt hiszem elégszer, elég részletesen leírtam, hogyan védekezek, beleértve az ilyen jellegű hibákat is.

Egyszer tudnál egy rohadt kérdésre egyenesen válaszolni, és nem terelni?

Sajnálom, de most át kell tereljelek a fent linkelt topikba. Nem fogom ugyanis újra és újra mindenkinek pontról pontra leírni, hogyan védekezek Windows XP-n, hogy aztán a thread milliméteresre szűküléséig kötekedjél velem, totál értelmetlenül. Ráadásul egy olyan témában, amibe nem is illik, mert ez a Spectre/Meltdown javítások kikapcsolásáról szól, nem arról, hogyan legyél biztonságban a javítások nélkül.

>Windows XP-t használok, lejárt támogatású Chrome-mal

srácok, én most értettem meg valami nagyon, nagyon fontosat. hajbazer valójában egy remek szakember, aki ironikusan (bár biztos van erre pontosabb szó, mint az ironikus) "elköveti" az összes lehetséges iparági hibát, hogy tanuljunk belőle. nem létezik, hogy ez az ember hülye legyen, mert hogy ennyire pontosan mindig az ellenkezőjét csinálja, ismernie kell a helyes utat.

kicsit hasonlít egy régi angoltanárom kedvenc szórakozására: ha a teszten nulla pontot értél el, akkor ötöst kaptál, mert tudnod kellett mindegyik kérdésre, hogy mit NEM szabad bejelölnöd. (volt egy srác, aki erre rájátszott, és egy kérdésre véletlenül helyesen válaszolt. kurva nagy karót vésett be neki. istenem, régi szép idők! :D)

Netkapcsolat nélküli gép, minden adat pendriveon, usb vinyón érkezik vagy távozik. Nekem van egy ilyen gépem használatban. Külön jó hogy ki-be kapcsolható lesz a javítás, főleg nagyobb Blenderes projekt vagy vektorgrafikák készítése, főleg pedig renderelés esetén... kösz a linux leírást Hajbázer.

de elvi lehetőség van támadásra a felvázolt scenárióval is.

Ezért máris jössz, mint hivatásos rettegő és úgy állítod be, mintha mindennapi dolog lenne a Windows 95-ök feltörése.

Emlékeztetnélek még arra is, hogy az iráni uráncentrifugák meghibásodását (ha a Stuxnet-re gondolsz) az izraeli titkosszolgálat célzott kibertámadásainak köszönhetjük. Ha pedig frissített™, szuperbiztonságos™ Windows 10 lett volna rajtuk, ugyanúgy meg lettek volna hekkelve (sőt, szerintem még könnyebben).

A CIA/NSA és egyéb hárombetűsök játszva meghekkelik neked a legújabb™, frissített™ = biztonságos™ Windows 10-ed, Android-od, iOS-ed, ugyanis külön célszoftvereket fejlesztenek erre a célra és rengeteg erőforrást fordítanak a sebezhetőégek megtalálására. Amit persze maguktól nem fognak senkinek sem az orrára kötni. Maximum akkor van esélyed értesülni róluk, ha épp meghekkelik őket, és akkor sem biztos, hogy mindenre fény derül.

Bár, aki a frissített™ operációs rendszerétől várja a biztonságát, az nyilván nem is szándékozik értesülni ilyenekről és csak a gyártó által szavatolt biztonság™ illúziója által megteremtett komfort kell a kis lelkének.

"külön célszoftvereket fejlesztenek erre a célra és rengeteg erőforrást fordítanak a sebezhetőégek megtalálására."

Itten az a kérdés, hogy olykor a neten rendelő és fizető Kovácsnénak a végtelen zsetonnal játszó titkosszolgálatok ellen kell-e felkészülnie, vagy 274-day sebezhetőséget célzó netzsebes kiddie ellen, aki lakhat Soroksáron, Vlagyivoszokban vagy Csengdu-alsón.

A titkosszolgálatok ellen akkor kell felkészülnöd, ha az éppen aktuális állami berendezkedés ellen dolgozol, vagy azt szeretnéd megdönteni (észak-amerikai és európai demokráciákban). Ez viszonylag ritka eset errefelé, minekután a többség nagyon békésen tengődik a kis kényelmes, nagybevásárlós, okostelefonos, LED-tévénézős, alkoholizálós, CSOK-gyerekcsinálós komfortzónájában.

A kiddie-t meg előbb-utóbb elkapják, vagy a kiddie megunja. Olyan komplex kártevőt pedig nem fog lefejleszteni, amit ne lehetne egy eltávolítóprogrammal vagy víruskeresővel leirtani. Ha pedig pár alapszabályt betart a felhasználó, meg se fogja kapni. Én 6 éve elvagyok víruskereső nélkül egy lassan 4 éve nem támogatott rendszeren. Nem kaptam még soha vírust, amit havonta vissza is ellenőrzök víruskereső boot CD-vel, slave módban felcsatolva a Windows XP fájlrendszert.

"rengeteg erőforrást fordítanak a sebezhetőégek megtalálására"

Szerintem még ez is naívság, mert sokkal jobban megtérül az erőforrást inkább a sebezhetőségek beépítésére fordítani. És nem mellesleg biztosabb megközelítés is. Gondold el, ha véletlenül egy tehetséges mérnök megcsinálná a feltörhetetlen rendszert! Mekkora blama lenne évekig hiába fizetni egy fél hadsereget, hogy törje fel! Ennél sokkal ésszerűbb eleve megkorrumpálni minden fontos csapatban néhány embert.

( Adamyno | 2018. 01. 11., cs – 15:51 )

A Lenovo adott ki valami BIOS/UEFI patch-et, akkor most kell nekem az OS patch is?

Igen, a Microsoft kerek perec leírja, hogy SQL alatt komoly teljesítménybeli problémák adódhatnak. Ez ám a tuti helyzet! Az SQL sosem volt gyors, most legalább majd az Intel-re lehet fogni, hogy miért is lassú.

Ezen felül még az SSD-k is kellemetlenül megszívják, az IO-sebességük leesik. Így meg már halmozott az anyagi kár, mert az SSD-ket is pont azért veszi boldog-boldogtalan, mert sokkal gyorsabbak (is lehetnének).

--
robyboy

( Polesz v | 2018. 01. 11., cs – 18:45 )

Bazze hajbakap, én nem kérem, hogy vágjanak ki megint, de kiprovokálod szép öcsém...

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is! 


Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.14.12 #2 SMP Fri Jan 5 17:32:46 CST 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  UNKNOWN 
> STATUS:  UNKNOWN  (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

( st3v3 v | 2018. 01. 11., cs – 19:16 )

*grab popcorn, watch stupidity unfold*

( uid_16313 | 2018. 01. 11., cs – 19:25 )

Most nincs kedvem utána olvasni, de az Intel január 8-án mutatta be legújabb platformját, a méregdrága Kaby Lake G-t, ami gondolom tartalmazza a problémás technológiákat is. Ez ám az igazi Brute Force.

--
robyboy

"mert következetes sunyításos átverést jelen"

Nem. Ezt úgy hívják, hogy embargó. A problémáról régen tudnak, viszont a kihasználhatóság mérséklése miatt koordinált közlésben egyeztek meg az érintett cégek. Azért, hogy mindenki fel tudjon készülni a javításra.

--
trey @ gépház

Egy új CPU fejlesztése alsó hangon 3-5 év. Ha ezeket a most kiderült hibákat teljesen ki akarják pucolni a processzorokból, akkor optimista becslések alapján is kell néhány év(!), hogy az első, ilyen hibát nem tartalmazó lapka megérkezzen a gyártósor végére. És ez nagyjából az összes érintett gyártó processzoraira vonatkozik.
Az, hogy mikrokóddal+OS támogatással lehet bonyolultabb vagy épp egyszerűbb módszerekkel workaroundolni a problémát, az csak annyit jelent, hogy az újabb gyártású procik már alapból a workaroundhoz szükséges mikrokóddal esnek ki a gyártből, és a normális OS-ek ezt figyelembe véve tartalmazni fogják a szükséges módosításokat. Workaround tehát van/lesz, de teljesítményben mindenképp veszteséggel fog járni ez a móka. Igen, az újabb prociknál is, hiszen a jelenleg ismert teljesítményadatokat egy, a workaroundokat nem tartalamzó környetzetben mérték, illetve arra számolták.

És ki mondta, hogy ne lehetne várni 5 évet az új processzor piacra dobásával?

Ja, hogy befektetőéknek kellett a profit, így inkább sorozatgyártották és piacra dobták a hót lyukas szarjukat.

Ezt hívják inkorrekt üzleti magatartásnak, szebben mondva nagyvállalati arroganciának.

Nem kéne ennyit pörögnöd sem rajtam, sem a fekete lyukakon. Mert úgy látszik, nagy mértékben kitakarják az orrod elől a valóságot: Egy arrogáns nagyvállalat több hibás termékcsaládot dobott piacra, a régebbieket mulasztásból, az újabbakat szándékosan. Ezek hátrányos következményeit pedig teljes egészében a vásárlóira hárítja át. Mindeközben, Zeller Úr legnagyobb szívfájdalma az, hogy hájbazer fejében milyen lyukak vannak és melyik kommentjén lehet mekkorát facepalm-ozni.

( renee7 v | 2018. 01. 11., cs – 20:26 )

Tökikém! Mit akarsz ezzel erőltetni?

( szilard_ v | 2018. 01. 12., p – 00:54 )

OFF
Hogy a fenébe lehet/tudjátok követni, hogy ki, melyik hozzászólásra reagál!?
/OFF

( Raynes v | 2018. 01. 12., p – 04:38 )

Mesélj, milyen jelentős hátrányokkal és kompromisszumokkal javították a hibát? Mert most már egy ideje többen is tesztelték felhasználók közül a patcheket, és visszajelzések alapján senki nem vett észre teljesítményvesztést, illetve mérni sem tudott. Ahol tényleg mértek jelentősebb lassulást, az szerveren meg speciális feladatoknál volt, és elég kevés átlag felhasználó gépét érinti.

Amúgy meg ez a sérülékenység nem az Intel sara. Épp ezért érintettek más gyártók termékei is. Az viszont már az Intel görénysége, hogy 2017 júniusa óta tud a hibáról, és a titokban tartását arra használta fel, hogy kihozza a szintén sebezhető Kaby Lake családot, meg a javításon is rajta ült most január 8-ig, és még mindig csak az 5 évnél nem régebbi procik 90%-a kapott új mikrokódot, január végéig a maradék 10%, míg az 5 évnél régebbi procik egyáltalán nem fognak javítást kapni (pl. 2. gen. Core i procik már nem, amilyen mákom van, nekem is van, meg a még korábbi CPU-k sem). Szarjanak sünt.

A fizikailag a sérülékenységet nem tartalmazó Intel-procik majd csak évek múlva jönnek ki. Aki addig biztosra akar menni, vesz AMD-t, szerintem az új AMD-generációnál meg tudják oldani, hogy Spectre-sebezhetőség se legyen részben sem, de ha nem spéci kernelt használsz, akkor az AMD-k már most sem sebezhetőek, a te Turionod sem érinti.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Ezt nem tudom minek linkelted, külön kiemeltem, hogy nem szerverekről beszélek, hanem átlag felhasználók desktop PC-iről. Azokban default be van kapcsolva telepítés után a javítás, nem kell külön semmit engedélyezni.

Windows Servernél meg kit érdekel. Legfeljebb szerverekbe vesznek annyi %-kal erősebb procit, amennyit a patchcsel veszítenek.

A MS meg valóban riogat, hogy Win10-től régebbi desktop Windows alatt és régi architektúrás gépeken sokat fog lassítani a patch, de szerintem ez csak pánikkeltés.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum


Aki addig biztosra akar menni, vesz AMD-t, szerintem az új AMD-generációnál meg tudják oldani, hogy Spectre-sebezhetőség se legyen részben sem, de ha nem spéci kernelt használsz, akkor az AMD-k már most sem sebezhetőek, a te Turionod sem érinti.

Csak kár, hogy ez nem így van, hanem az exploitot könnyebb volt úgy megírni, hogy használta a BPF JIT-et, amúgy most néztem meg az N36L-es Turiont, az is sebezhető.

Nem tudom, mikor írogattam vaktában, de itt van:

https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

Én Linuxon fordítottam le, az N36L-es Microserveremen próbáltam, de mivel sima C + asm, Windowsra is le lehet.
Ja, FX-8320E-n is ugyanez az eredmény (mellesleg Xeonon is KAISER patch-el, szóval arra senki ne számítson, hogy elég a KPTI-s kernel a Spectre ellen). 


# cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II Neo N36L Dual-Core Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 800.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs            : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400
bogomips        : 2595.65
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II Neo N36L Dual-Core Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 1100.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs            : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400
bogomips        : 2595.72
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

# ./spectre 
Reading 40 bytes:
Reading at malicious_x = 0xffffffffffdfebb8... Success: 0x54=’T’ score=2 
Reading at malicious_x = 0xffffffffffdfebb9... Success: 0x68=’h’ score=7 (second best: 0xFB score=1)
Reading at malicious_x = 0xffffffffffdfebba... Success: 0x65=’e’ score=7 (second best: 0xFE score=1)
Reading at malicious_x = 0xffffffffffdfebbb... Success: 0x20=’ ’ score=7 (second best: 0x9F score=1)
Reading at malicious_x = 0xffffffffffdfebbc... Success: 0x4D=’M’ score=2 
Reading at malicious_x = 0xffffffffffdfebbd... Success: 0x61=’a’ score=2 
Reading at malicious_x = 0xffffffffffdfebbe... Success: 0x67=’g’ score=7 (second best: 0x5C score=1)
Reading at malicious_x = 0xffffffffffdfebbf... Success: 0x69=’i’ score=7 (second best: 0xE0 score=1)
Reading at malicious_x = 0xffffffffffdfebc0... Success: 0x63=’c’ score=7 (second best: 0xA6 score=1)
Reading at malicious_x = 0xffffffffffdfebc1... Success: 0x20=’ ’ score=9 (second best: 0x5B score=2)
Reading at malicious_x = 0xffffffffffdfebc2... Success: 0x57=’W’ score=9 (second best: 0xE3 score=2)
Reading at malicious_x = 0xffffffffffdfebc3... Success: 0x6F=’o’ score=9 (second best: 0xE5 score=2)
Reading at malicious_x = 0xffffffffffdfebc4... Success: 0x72=’r’ score=7 (second best: 0xA9 score=1)
Reading at malicious_x = 0xffffffffffdfebc5... Success: 0x64=’d’ score=9 (second best: 0x44 score=2)
Reading at malicious_x = 0xffffffffffdfebc6... Success: 0x73=’s’ score=9 (second best: 0xE2 score=2)
Reading at malicious_x = 0xffffffffffdfebc7... Success: 0x20=’ ’ score=7 (second best: 0xF6 score=1)
Reading at malicious_x = 0xffffffffffdfebc8... Success: 0x61=’a’ score=7 (second best: 0xFA score=1)
Reading at malicious_x = 0xffffffffffdfebc9... Success: 0x72=’r’ score=7 (second best: 0xF9 score=1)
Reading at malicious_x = 0xffffffffffdfebca... Unclear: 0x65=’e’ score=998 (second best: 0x15 score=821)
Reading at malicious_x = 0xffffffffffdfebcb... Success: 0x20=’ ’ score=9 (second best: 0x46 score=2)
Reading at malicious_x = 0xffffffffffdfebcc... Success: 0x53=’S’ score=9 (second best: 0x34 score=2)
Reading at malicious_x = 0xffffffffffdfebcd... Success: 0x71=’q’ score=11 (second best: 0x15 score=3)
Reading at malicious_x = 0xffffffffffdfebce... Success: 0x75=’u’ score=7 (second best: 0xFD score=1)
Reading at malicious_x = 0xffffffffffdfebcf... Success: 0x65=’e’ score=9 (second best: 0xB6 score=2)
Reading at malicious_x = 0xffffffffffdfebd0... Success: 0x61=’a’ score=9 (second best: 0x15 score=2)
Reading at malicious_x = 0xffffffffffdfebd1... Success: 0x6D=’m’ score=9 (second best: 0x97 score=2)
Reading at malicious_x = 0xffffffffffdfebd2... Success: 0x69=’i’ score=9 (second best: 0xF5 score=2)
Reading at malicious_x = 0xffffffffffdfebd3... Success: 0x73=’s’ score=9 (second best: 0x80 score=2)
Reading at malicious_x = 0xffffffffffdfebd4... Success: 0x68=’h’ score=9 (second best: 0xA7 score=2)
Reading at malicious_x = 0xffffffffffdfebd5... Success: 0x20=’ ’ score=7 (second best: 0xD9 score=1)
Reading at malicious_x = 0xffffffffffdfebd6... Success: 0x4F=’O’ score=9 (second best: 0xE1 score=2)
Reading at malicious_x = 0xffffffffffdfebd7... Success: 0x73=’s’ score=11 (second best: 0x15 score=3)
Reading at malicious_x = 0xffffffffffdfebd8... Success: 0x73=’s’ score=9 (second best: 0xC3 score=2)
Reading at malicious_x = 0xffffffffffdfebd9... Success: 0x69=’i’ score=9 (second best: 0xF1 score=2)
Reading at malicious_x = 0xffffffffffdfebda... Success: 0x66=’f’ score=7 (second best: 0xD4 score=1)
Reading at malicious_x = 0xffffffffffdfebdb... Success: 0x72=’r’ score=7 (second best: 0xF7 score=1)
Reading at malicious_x = 0xffffffffffdfebdc... Success: 0x61=’a’ score=7 (second best: 0xFD score=1)
Reading at malicious_x = 0xffffffffffdfebdd... Success: 0x67=’g’ score=7 (second best: 0xF4 score=1)
Reading at malicious_x = 0xffffffffffdfebde... Success: 0x65=’e’ score=11 (second best: 0x15 score=3)
Reading at malicious_x = 0xffffffffffdfebdf... Success: 0x2E=’.’ score=9 (second best: 0x14 score=2)

Attól még lehet sebezhető :)

Nem mondtam, hogy nem az.

Csak kissé öngól a Windows XP ellen kikelő szélsőséges idealistáknak, hivatásos rettegőknek és az errefelé elitkedő fősodratú mérnök uraknak, hogy pont az általuk a legveszélyeztetettebbnek™ kikiáltott rendszeren el se indul az exploit.

Itt az ideje, hogy én is pattogtassak egy kis popcorn-t. :P

Szélsőséges idealista te vagy, mert abban, hogy nem támogatom ..

  • az erőltetett növekedést,
  • a működő eszközök kidobását,
  • a szoftverek folyamatos lassulását,
  • a kínai rabszolgák termelő tevékenysége által kiszolgált hardverpiacot,
  • az ezek következtében fellépő túlfogyasztást, túltermelést és környezetszennyezést

.. azt látod, hogy "régi foshalom jó, mert minden, ami új, gyorsabb, kevesebbet fogyaszt, csakis az ördög műve, és mindenkinek árt", amit én speciel soha nem gondoltam és nem is írtam le. Konkrét megoldások lehetnek jobbak vagy rosszabbak, de általánosságban nem igaz sem az, hogy az újabb = jobb, sem az ellenkezője.

Azzal, hogy valamire egy példa nem működik, még nem jelenthető ki, hogy nincs.

Beakadt lemezre beakadt lemezzel válaszolok: Nem jelentettem ki, hogy nincs.

Ahogy mondani szokás, valaminek a létezése bizonyíthat, nemléte csak feltételezhető.

Így igaz.

viszont van csilliom+1 egyéb, ami igen

Ahogy a tieden is, csak nem tudsz róla. Én legalább tudom, mire kell figyelni, ezért nem is kapok sem vírust, sem kártevőt. Aki az operációs rendszer fejlesztőitől várja el, hogy helyette figyeljenek, az mindig nagyobb potenciállal lesz sebezhető.

Nem érdemes, de emlékeztetnélek, hogy ez az első gyakorlati példa ebben a topikban, amit Windows XP-n láttunk. Ez előtt csak elvi lehetőségeket és üres riogatást olvashattunk, azt viszont elég nagy számban.

Mindenesetre, még ha el is indul és működik is Windows XP-n a spectre.exe, az se jelent magasfokú veszélyeztetettséget. Az egyetlen, ami valós veszélyt jelent a biztonságra is odafigyelő Windows XP felhasználóknak, ha JavaScript-en keresztül garantáltan működik. Ám az is csak akkor, ha lefuttatja a böngésző (nincs kivédve a megfelelő bővítményekkel).

Te nézz már bele abba a programba, milyen XP (vagy bármilyen OS) specifikus dolog van benne. Amúgy neked vannak XP-id, miért nem próbálod ki te?

Az meg hogy oldjam meg, hát ez a demo kódot sem én írtam, mert annyira nem érdekel a dolog, hogy napokat öljek abba, hogy exploitokat írogassak, főleg olyan CPU-hoz, ami nekem nincs is. Amúgy a kód alatti hozzászólásokban vannak ötletek a módosításokra "ancient" processzorokra.

Egyébként most te azon vitatkozol, hogy szükség van-e a javításra minden esetben (mert ez végül is vitatható, mondjuk egy SQL szerver egy middleware mögött, ami előtt frontendek hada áll, nem valószínű, hogy kihasználható lenne), vagy azon, hogy létezik-e a sebezhetőség?

Nem tudom, feltűnt-e, hogy CPU hibáról van szó, ehhez nem kell atomtudósnak lenni, hogy belásd, az XP használata nem foltozza be. Nem is értem, minek szarakodnak itt az Intelnél, MS-nél, a Linux fejlesztők, annyit kéne mondaniuk, hogy mostantól álljon vissza mindenki az XP-re. És annyira hülyék, hogy már azt is elfelejtték, hogy az XP-n futó programokat miért nem érinti.

Az Intellel, amelynek a felelős magatartása legalább részben megkérdőjeleződött, itt nem érdemes példálózni.

Viszont elgondolkodtató kellene hogy legyen, hogy olyan cégek, mint a Google meg az Amazon, amelyek itt kivételesen nem vétkesek, hanem áldozatok, nem XP-hez és nem leszarom tablettához, meg "jaj, csak tudni kell okosnak lenni, mi meg okosak vagyunk" bonmókhoz fordulnak, hanem foltoznak, és inkább vállalják, hogy akárhányan előállnak az ellenpéldákkal arra a kijelentésükre, hogy nem okoz érdemi lassulást.
Persze lehet, hogy csak elfelejtették az XP-t. Lúzerek. Legalább a hupot olvasnák...

Igen, ez lehet az oka :) Itt van frissített kód:
https://github.com/crozone/SpectrePoC

Bár NORDTSCP-vel fordítva az VIA Eden ahogy várható volt: 


Using a cache hit threshold of 80.
Build: RDTSCP_NOT_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED
Reading 40 bytes:
Reading at malicious_x = 000000A0... Success: 0xFF=Æ?Æ score=0
Reading at malicious_x = 000000A1... Success: 0xFF=Æ?Æ score=0
Reading at malicious_x = 000000A2... Success: 0xFF=Æ?Æ score=0
Reading at malicious_x = 000000A3... Success: 0xFF=Æ?Æ score=0
Reading at malicious_x = 000000A4... Success: 0xFF=Æ?Æ score=0
Reading at malicious_x = 000000A5... Success: 0xFF=Æ?Æ score=0
Reading at malicious_x = 000000A6... Success: 0xFF=Æ?Æ score=0

(majdnemXP :)) W2K3 Core2duo: 


Using a cache hit threshold of 80.
Build: RDTSCP_NOT_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED 
Reading 40 bytes:
Reading at malicious_x = 000000A0... Unclear: 0x0D=’?’ score=61 (second best: 0x0E=’?’ score=60)
Reading at malicious_x = 000000A1... Unclear: 0x0E=’?’ score=58 (second best: 0x0D=’?’ score=57)
Reading at malicious_x = 000000A2... Unclear: 0x05=’?’ score=61 (second best: 0x0E=’?’ score=60)
Reading at malicious_x = 000000A3... Unclear: 0x0E=’?’ score=61 (second best: 0x05=’?’ score=60)
Reading at malicious_x = 000000A4... Unclear: 0x05=’?’ score=57 (second best: 0x0E=’?’ score=56)
Reading at malicious_x = 000000A5... Unclear: 0x05=’?’ score=42 (second best: 0x0E=’?’ score=41)
Reading at malicious_x = 000000A6... Success: 0x67=’g’ score=2 
Reading at malicious_x = 000000A7... Success: 0x69=’i’ score=2 
Reading at malicious_x = 000000A8... Unclear: 0x05=’?’ score=28 (second best: 0x0E=’?’ score=27)
Reading at malicious_x = 000000A9... Unclear: 0x05=’?’ score=11 (second best: 0x0E=’?’ score=10)
Reading at malicious_x = 000000AA... Unclear: 0x0E=’?’ score=17 (second best: 0x05=’?’ score=17)
Reading at malicious_x = 000000AB... Unclear: 0x05=’?’ score=61 (second best: 0x0E=’?’ score=59)
Reading at malicious_x = 000000AC... Unclear: 0x05=’?’ score=62 (second best: 0x0E=’?’ score=61)
Reading at malicious_x = 000000AD... Unclear: 0x05=’?’ score=28 (second best: 0x0E=’?’ score=26)
Reading at malicious_x = 000000AE... Success: 0x73=’s’ score=2 
Reading at malicious_x = 000000AF... Success: 0x0E=’?’ score=2 
Reading at malicious_x = 000000B0... Success: 0x0E=’?’ score=2 
Reading at malicious_x = 000000B1... Unclear: 0x0E=’?’ score=62 (second best: 0x0D=’?’ score=62)
Reading at malicious_x = 000000B2... Unclear: 0x05=’?’ score=61 (second best: 0x0E=’?’ score=60)
Reading at malicious_x = 000000B3... Unclear: 0x0D=’?’ score=58 (second best: 0x05=’?’ score=57)
Reading at malicious_x = 000000B4... Unclear: 0x0E=’?’ score=62 (second best: 0x0D=’?’ score=62)
Reading at malicious_x = 000000B5... Unclear: 0x05=’?’ score=59 (second best: 0x0E=’?’ score=57)
Reading at malicious_x = 000000B6... Unclear: 0x05=’?’ score=56 (second best: 0x0D=’?’ score=55)
Reading at malicious_x = 000000B7... Unclear: 0x0E=’?’ score=59 (second best: 0x0D=’?’ score=58)
Reading at malicious_x = 000000B8... Unclear: 0x0E=’?’ score=12 (second best: 0x05=’?’ score=12)
Reading at malicious_x = 000000B9... Unclear: 0x0E=’?’ score=26 (second best: 0x05=’?’ score=25)
Reading at malicious_x = 000000BA... Success: 0x69=’i’ score=2 
Reading at malicious_x = 000000BB... Success: 0x73=’s’ score=2 
Reading at malicious_x = 000000BC... Success: 0x68=’h’ score=2 
Reading at malicious_x = 000000BD... Success: 0x20=’ ’ score=2 
Reading at malicious_x = 000000BE... Success: 0x0F=’?’ score=2 
Reading at malicious_x = 000000BF... Success: 0x73=’s’ score=2 
Reading at malicious_x = 000000C0... Success: 0x73=’s’ score=2 
Reading at malicious_x = 000000C1... Success: 0x69=’i’ score=2 
Reading at malicious_x = 000000C2... Unclear: 0x0E=’?’ score=13 (second best: 0x05=’?’ score=12)
Reading at malicious_x = 000000C3... Unclear: 0x0E=’?’ score=58 (second best: 0x0D=’?’ score=56)
Reading at malicious_x = 000000C4... Unclear: 0x0E=’?’ score=58 (second best: 0x0D=’?’ score=58)
Reading at malicious_x = 000000C5... Success: 0x67=’g’ score=59 (second best: 0x0E=’?’ score=27)
Reading at malicious_x = 000000C6... Unclear: 0x0E=’?’ score=18 (second best: 0x0D=’?’ score=17)
Reading at malicious_x = 000000C7... Unclear: 0x05=’?’ score=59 (second best: 0x0E=’?’ score=58)

Gondolom a timer miatt pontatlanabb, de látszik, hogy ugyanúgy működik. :)
Sajnos (vagy inkább szerencsére) nincs a közelembe XP olyan CPU-val ami RDTSCP támogat (de gondolom ugyanaz lenne az eredmény mint bármi máson :))

Ja, hogy azóta az AMD-kről is kiderült, hogy BPF JIT NÉLKÜL is sebezhetők. Az fasza, nincs menekülőút sem senkinek, ráadásul ez a gyártókat is arra ösztönzi, hogy ne javítsák a hibát normálisan, hiszen minek erőlködnének vele, ha a konkurencia terméke is sebezhető.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Például az EU milliárdos bírság belengetésével, Intel esetében 10 milliárdos bírsággal kellő mértékben ösztönözhetné a gyártókat a helyes irányba. :-)
A minimum, hogy azt az extra profitot ami az elkövetkező időszakban Meltdown és Spectre miatti gépcserékből landol a gyártóknál szépen beszedik bírság formájában.

Normális HUP-ot használok!

VW diesel botránynál kit érdekelt, hogy el vannak túlozva a környezetvédelmi előírások? Jóhogynem már arra kötelezik a gyártókat, hogy tiszta oxigént pöfögjenek ki a diesel autók. A benzin sem talajból tör elő 95-ös oktánszámmal ólmozatlanul. Ezzel is érvelt a VW, hogy ha nem csak az autók károsanyag kibocsájtását vizsgálnák hanem az üzemanyagtankig vezető utat is az azzal járó szennyezéssel, akkor egyből mások lennének az arányok diesel és benzines között.
De ez senkit nem érdekelt. Az sem, hogy a BMW vagy Mercedes pontosan úgy trükközött a szoftverrel mint a VW.
Ha most történetesen az EU meg akarja fejni az Intelt adott a lehetőség. Ismert és titokban tartott hiba ellenére új processzorgenerációt kiadni büntethető és büntetendő cselekedet.

Normális HUP-ot használok!

Jóhogynem már arra kötelezik a gyártókat, hogy tiszta oxigént pöfögjenek ki a diesel autók.

Jóhogynem már kötelezővé tette volna nekik bárki a pöfögtetést. Ha nem tudják megoldani, csináljanak elektromos autót, vagy amilyet akarnak. A környezetvédelmi előírások pedig nem elég szigorúak, mivel még mindig lehet melegíteni a légkört a benzines autókkal. Ha meg nem tetszik nekik a rendszer, lobbizzanak ellene. Van akkora erejük. Ja, hogy hazudni egyszerűbb. Ezt multiék mindig is jól tudták.

Az EU pedig nagyon jól teszi, ha megfeji az Intelt. Eleget élősködtek processzormultiék ezen a kontinensen is.

Lenne. Még a legkisebb nagyvállalat is meg tudná fizetni. Birkáékhoz meg mehetnének a nagyvállalattól selejtezettek, amiknek még mindig tisztességes értékük lenne, nem holmi 10-20 ezer Ft, vagy elektronikai hulladék, amiért ma mennek. A hardvernek az eszmei értéke egységbe kerülne a használati értékével és sokkal kisebb hajlandósággal hajigálnák ki, mint amilyen pazarlást mostanában láthatunk. Ez pedig azt eredményezné, hogy a szoftvergyártók is összeszednék magukat és minden erőforrásoptimalizáló tudásukat latba vetnék, hogy minél gyorsabb, minél szuperebb felhasználói élményt nyújtó alkalmazásokat írjanak azonos hardverre. Sokkal nagyobb kihívás lenne a szoftverfejlesztés szakma annál, mint a mai enyhe túlzással bloated framework-ben össze-StackOverflow-zzuk a kódot, oszt kész.

Érdekesség: a 90-es évek közepén egy jóravaló GSM mobiltelefon nagyjából százezer forintba került. Ez mai értéken több, mint egymillió forint, ha az inflációval számolt reálértékét nézzük (csak hogy érezzük, akkor mennyit kellett érte dolgozni). Mégis, akkoriban már a középvállalatoknál is megjelentek a mobiltelefonok a drága készülék- és percdíjak ellenére.

( Gaab | 2018. 01. 12., p – 16:05 )

Miert is jo nekem, ha sebezheto marad a gepem? Ezt nem annyira ertem.

nagyobb rendszereknel pl alap hogy egy mysql kulon fizikai gepen fut, es azon semmi mas nincs. az is ismeretes hogy ez a patch erosen (sok esetben joval tobb, mint 30%) lassitja a mysql-t. mivel ezen idegen kod semmikepp nem futhat, belepni amugy is csak a root tud ra, tok folosleges patchelni. hasonloan pl. egy build-elesre/forditasra vagy pl renderelesre hasznalt gep eseten.

nyilvan egy desktop pc, vagy akar egy php/webserver eseten ez nem igaz, ott nem kicsit rizikos kihagyni a javitast.

en szerintem ezt a hibat ugy kell tekinteni, mintha a patcheletlen gepen gyakorlatilag mindennek es mindenkinek root joga lenne, mivel pont a memoria hozzaferesi jogosultsag kezelese nem teljesul megfeleloen. ha van olyan geped/eszkozod ahol amugy is minden processz es user root jogu, ott folosleges a patch mert nem noveli a biztonsagot.

A'rpi

( uid_16313 | 2018. 01. 12., p – 21:27 )

Eddig ahhoz voltunk hozzászokva, hogy alapvetően a szoftverek hibásak, és támadhatók, amik peccseléssel olcsón és problémamentesen orvosolhatók. Más kérdés, hogy az utólagos szoftveres foltozgatások is jellemzően lassítják a rendszert, mivel ez már kényszer és nem koncepció.

Namármost, ez a világ itt véget is ért. A HW-fejlődés elérte azt a szintet, amikor már kontrollálhatatlan a HW-szintű biztonság garantálása. Egyszerűen fizikai képtelenség.

Itt kezdődik az a korszak, amikor már a HW-ben sem bízhat meg többé az ember, nem csak a szoftverben.

Hány évig fogunk még sebezhető CPU-kat kapni a boltokban?

Most kellene jönnie a lassabb, energiatakarékosabb és biztonságosabb vasaknak.

--
robyboy

Na azért nem kell ennyire elragadtatnod magad!
"Itt kezdődik az a korszak, amikor már a HW-ben sem bízhat meg többé az ember, nem csak a szoftverben."
Az olyan szép infó bulvár mondat, hogy ki is rakhatnák a jövő havi PC World címoldalára. :-)
Raspberry Pi, Cortex-A53as mobilok, 2013 előtti in-order Atom procis notebookok, többnyire netbookok egyike sem érintett sem Meltdown sem Spectre által. Nem úgy mint az AMD! Hanem valóban nem érintettek. :-)
Az in-order Atomokat leszámítva mind mai számítógép. Ma is újonnan kaphatóak.

Normális HUP-ot használok!

( monyo20 | 2018. 01. 13., szo – 09:02 )

Úgy tűnik mégis akad teljesítménycsökkenés nélküli megoldás:

https://www.blog.google/topics/google-cloud/protecting-our-google-cloud…

We believe that Retpoline-based protection is the best-performing solution for Variant 2 on current hardware. Retpoline fully protects against Variant 2 without impacting customer performance on all of our platforms. In sharing our research publicly, we hope that this can be universally deployed to improve the cloud experience industry-wide.

( Resmon | 2018. 01. 13., szo – 11:59 )

"Bolond lyukból bolond szél fúj..."

( phord | 2018. 01. 13., szo – 13:25 )

[OFF]

végigolvasva ellenállhatatlan késztetést éreztem némi mediálásra:

szerintem hajbazer nem hülye, nem bolond stb., csak próbálja kerülni a dogmákat, nyitottan áll a dolgokhoz, és igyekszik a fontos dolgokhoz saját véleményt és hozzáállást kialakítani. számomra ettől nem ellenszenves, sőt. azt sem gondolom, hogy megkérdőjelezhetetlennek tartja a véleményét, különben blogban publikálná, letiltott kommenteléssel, nem itt, ahol pontosan tudja, hogy szakemberek fogják azt szétszedni minden lehetséges szempontból. biztos vagyok benne, hogy elgondolkodik a hozzászólások többségén, még akkor is, ha itt és most bele is áll a saját véleményébe, és hosszabb távon adott esetben ezek finomítják a hozzáállását a témában.

ugyanakkor kiolvasható a megnyilvánulásaiból egy erős frusztráció is a "fősodratú mérnökurakkal" szemben, ami már kevésbé tűnik racionálisnak. ez egyrészt betudható a fent említett "ne vegyünk át készen véleményeket" attitűdnek, ami nálam pozitív, másrészt jó eséllyel valamilyen múltbéli negatív élmény táplálja, pl. nem sikerült befejezni az egyetemet, vagy csúnyán akarta kioktatni valaki magasabb végzettségű, vagy csak nagyon nem értett egyet már sokszor a "hivatásos szakemberekkel". mindenesetre érezhető, hogy "fősodratúnak" vagy "mérnöknek" vagy "úrnak" lenni az ő szemében bűn, a három együtt egyenesen hitelteleníti az illető álláspontját. emiatt sokszor nem tűnik elég objektívnek.

[/OFF]

a gyártók felelősségét firtatni a konkrét kérdésben meglátásom szerint teljesen valid felvetés. vettél valamit, rá volt írva, mit tud, és most egyszer csak kiderül, hogy innentől csak a 70%-át kapod, mert hibásan terveztük meg, és vagy veszélyt jelent rád, vagy mondj le 30% teljesítményről. amiért korábban eltettük a pénzed, és most eszünkben sincs visszaadni a 30%-át. van erre egy jogi kategória is: termékfelelősség.

egy ilyen helyzetben körüljárni, milyen egyéb lehetőségek lehetnek a helyzet kezelésére, szintén érvényes és hasznos reakció meglátásom szerint, amit én ezúton köszönök. pontosan leírja, hogy nem mindenkinek javasolja ezt a megoldást, de lehetnek olyan esetek, amikor ez a kisebbik veszteség és/vagy kockázat.

szóval lehet, hogy nem ő a legnagyobb szakember a világon, nem neki van a legtöbb tudása és tapasztalata, valószínűleg nincs is mindenben igaza, és néha nem érvel kellően objektíven, de az alapfelvetése szerintem jogos, nem kéne csípőből lehülyézni.

Az már bizonyos, hogy a Meltdown/Spectre sebezhetőségeket adott gépen, megfelelő helyi jogosultsággal futó programmal lehet csak kihasználni.

Számomra továbbra is kérdéses, hogy pl. egy Microsoft szervert / SQL szervert érdemes-e egyáltalán frissíteni, vagy elegendő, ha bekorlátozzuk azok elérhetőségeit. Linux szervereknél ugyanígy.

A NetApp nyilatkozata a kontrollereivel kapcsolatban is ezt erősíti. Nem sebezhetők, mivel zárt rendszerek, és nem futtatnak felhasználói alkalmazásokat.

Ennek fényében a sebezhetőségek elsődleges vesztesei a végfelhasználók, akik agyba-főbe futtatnak mindenféle kétes szoftvereket a gépeiken.

A virtualizált környezetek azért kritikusak, mivel ott létfontosságú a biztonság. Szerintem ezek a legnagyobb vesztesei most a teljesítmény visszaesésének. Itt garantálni kell, hogy ne lehessen "átlátni" a Guest-ek között még véletlenül sem.

Az indító gondolataidhoz meg csak annyit, hogy a közösségeket általában a hasonlóan érző, gondolkodó emberek hozzák létre, aki ebbe nem fér bele, azt közösítik ki. Sajnos ez azóta így van, amióta ember az ember.
Ezért van annyi féle vallás, politikai irányzat, tudományos tézis, stb... vagy akár bőrszín, szexuális beállítottság, zenei ízlés és így tovább.

Már gyerekkorban szépen meglátszik ez, vannak akik bicikliznek, vannak a "Scooter"-esek, a "deszkásaok" a lényeg, hogy mindenki tartozzon valahová, és tudja, hogy miért is oda tartozik, és miért nem a másik csoportba. Falkák ezek, mint az állatvilágban, és meg is van a falkavezér mindenhol, amely pozíciót ugyanúgy hatalmi harcokkal kell elérni az ember által formált csoportokban is.

--
robyboy

+1 én is, szakmai és szociális témában egyaránt.

utóbbihoz annyit, hogy attól, hogy így van, még nincsen rendben. sok az olyan ösztönös emberi viselkedés, amit intelligenciával érdemes kontroll alatt tartani, főleg szociális környezetben, ahol az alkalmazkodás is fontos szempont. szeretném hinni, hogy ez nem rajongói vagy vallási, de még csak nem is pusztán közösségi, hanem egy szakmai fórum, ahonnan nem közösítik ki az eltérő véleménnyel rendelkezőket, főleg ha artikuláltan és indoklással képviselik azt. számomra egész biztosan sokkal izgalmasabb egy szakmai vita, mint egy bólogató, mindenben egyetértő nyáj kérődzése.

Maximálisan egyetértek. Néha én is trollkodok, vagyok provokatív, vagy írok hülyeségeket. Kapok ilyen-olyan válaszokat. Megvan a képességem, hogy mindegyiket a maga helyén kezeljem. Egy biztos viszont, egyikkel sem leszek kevesebb!

Más.

Most néztem az intel-microcode csomag frissülése után (a tavaly novemberi helyett már a januári verzió van fenn), hogy az érintett Intel Core i3-2348m-es mobilprocim verziószáma nem változott:

$ cat /proc/cpuinfo | grep microcode
microcode : 0x29
microcode : 0x29
microcode : 0x29
microcode : 0x29
$

Ez a CPU az Intel szerint érintett. A Fujitsu még nem adott ki új BIOS-t a laptophoz, szerintem nem is fog kiadni.

3 lehetséges okot látok ennek a hátterében:

1. Intel javított, de nem írta át a verziószámot, ebben én sem hiszek
2. Intel nem foglalkozott ezzel a CPU-val, annak ellenére, hogy érintett - ez már hihetőbb
3. Nem változott semmi, csak a dátum :) ez meg a trollkodás - nincs kedvem diff-et futtatni, az bebizonyítaná.

--
robyboy

Igen, SSD-n van a komplett rendszer. A sebesség csak az egyik pobléma egyébként: azok a szoftverek, amiket használok, már csak 64 bites környezetben érhetők el (másokkal is kell adatot cserélni, úgyhogy a használd a régit nem opció, mert olyanokkal cserélek adatokat, akiknek esélyük sem volt a régi verziót jogtisztán beszerezni). Egyébiránt a 32 bites régi verzió XP-n (meg a 2160-as procin) ugyan fut, de egy-egy komolyabb munkánál nagyon sokat számít az is, hogy egy-egy folyamat 10-15 vagy 20 percig darál, vagy épp lefut 2-3 perc alatt. Ha ezt nem egy-két, hanem sok alkalommal kell végigvárni, akkor azért eléggé orrdít a különbség.

"Ennek fényében a sebezhetőségek elsődleges vesztesei a végfelhasználók, akik agyba-főbe futtatnak mindenféle kétes szoftvereket a gépeiken."

Igen, és ezért tartom kapitális felelőtlenségnek azt, hogy azt hajtogatja, hogy ő odafigyel, amit lám az igazol, hogy még sosem törték meg, és aki odafigyel, azt nem érheti baj.
Egyrészt mert ezt nem igaz.
Másrészt pedig akadhat, aki elhiszi ezt neki (azért volna a fórum, hogy valaki tanuljon belőle), ahhoz pedig nagy karakter kell, hogy valaki ne tartsa azt magáról, hogy ő "odafigyel".

Vagyis látszólag segít, és küzd a feleslegesen multiknak adott pénz ellen, gyakorlatilag potenciális áldozatokat treníroz arra, hogy megkopaszthassák őket. Mindezt abban a világban, amelyben még mindig az 123456 jelszó veri a mezőnyt az általános odafigyelésben.

szerintem nem győzködött senkit, ismertetett egy alternatívát. mindenki saját felelőssége megítélni, hogy az adott konkrét esetben mennyire járható vagy nem ez az út.

ha én leírom egy fórumban, hogy Amerikát nem csak repülővel, hanem hajóval is meg lehet közelíteni Európából, vannak előnyei (olcsóbb), hátrányai (tovább tart), kockázatai (elsüllyed), nem én leszek a felelős, ha valaki tutajt ácsol és belefullad az óceánba. szerintem.

Ez egy informatikával foglakozó fórum (jobbára), amelyen olyan kérdések is elhangoznak, amelyekből látszik, hogy a kérdezője kezdő, vagy nem pejoratíve értve: naiv.
Amerikába kevesen indulnak és azok között még kevesebben vannak, akik nem értik, hogy mit jelent 7000 km; fórumokról tájékozódó "naivok", akik azt sem tudják, hogy mit nem tudnak annál kicsit többen akadnak.

Nem, de jure nem felelős az sem, akit komolyan vesz a problémára rákereső noobie, amikor azt írja, hogy ő a format c: paranccsal szokott helyet csinálni és neki bevált, tök jó alternatíva.

Pont a te általad leírt [1] [2] szélsőséges csúsztatások és sarkítások azok, melyeknek semmi keresnivalójuk nincs egy valóban szakmai fórumon. Te azt próbálod éreztetni, hogy ha valaki nem frissít, azt katasztrofális veszély fenyegeti. Ez jól hangzik, de köze nincs a valósághoz. Még akkor sem, ha speciel leszarja a biztonságot, amit én se ajánlanék neki.

aki odafigyel, azt nem érheti baj.

Aki odafigyel, azt kisebb valószínűséggel érheti baj. Mivel az emberi tényező a leggyengébb láncszem, így legnagyobb valószínűséggel az lesz támadva. Ha valaki az emberi tényezőt teszi erősebb láncszemmé, akkor csökkenti a sikeres támadás valószínűségét. Az, hogy nem törtek meg, nem azt bizonyítja, hogy nem érhet baj. Hanem azt, hogy az elgondolásom a saját gépemen működik. Egyébként nem én akarom bizonygatni, hogy a hajbazeri felhasználás hűde biztonságos (nekem megfelel), szoftvermultiék és a tech-lakájmédia akarja bizonygatni, hogy a folyamatos frissítés biztonságossá teszi a gépet. Ami hazugság.

Egyrészt mert ezt nem igaz.

De igaz. Még nem törtek meg. Nem vagyok saját magam ellensége, hogy megtöressem magam, aztán meg letagadjam. Ezt feltételezni rendkívül szűk látókörre és primitív gondolkodásmódra utal. Szerintem fejezd be!

Másrészt pedig akadhat, aki elhiszi ezt neki

Micsodát? Hogy uBlock-kal és ScriptBlock-kal el lehet hárítani a JavaScript-ben betolakodó, Spectre/Meltdown sebezhetőségre épülő kártevőt (amire természetesen működő példát egyet sem mutatott itt senki, csak szélsőségesen hatásvadász riogatást, vádaskodást, de azt annál többet)? Hogy rendszeres backup-pal még a legrosszabb esetre is fel lehet készülni (pl. ransomware)? Hogy némi odafigyeléssel sokkal nagyobb biztonságban lehetsz, mint frissítéssel + oda nem figyeléssel?

Nem, de jure nem felelős az sem, akit komolyan vesz a problémára rákereső noobie, amikor azt írja, hogy ő a format c: paranccsal szokott helyet csinálni és neki bevált, tök jó alternatíva.

Én eddig folyamatosan amellett álltam, hogy a számítógépet biztonságban kell tartani, akár frissítések nélkül is. Szeretném látni, ahogy format c: -zel az adatok elpusztítása nélkül. Jöhet a megoldás. Ha nem tudsz erre megoldást, akkor ugyanolyan hivatásos rettegő/riogató vagy, mint a többi fősodratú mérnök úr, aki csak látszólag törődik a kis noobie-k lelkével gépével és könnyű szívvel nézi végig, ahogy 30%-os teljesítménycsökkenésnek és az utána következő, multiéknak való bevételtermelésnek lesznek alávetve egy velejéig nemtörődöm, felelőtlen, arrogáns és vadkapitalista gigavállalatnak köszönhetően. Csak mert az Intel felelőtlenségét firtató hozzászólást eddig még nem láttam tőled.

"Hogy uBlock-kal és ScriptBlock-kal el lehet hárítani a JavaScript-ben betolakodó, Spectre/Meltdown sebezhetőségre épülő kártevőt (amire természetesen működő példát egyet sem mutatott itt senki, csak szélsőségesen hatásvadász riogatást, vádaskodást, de azt annál többet)?"

Azzal az ismeretlen kartevoket nem hiszem, hogy el lehetne haritani, csak azokat, amik mar leleplezodtek :)

De hat ez is csak olyan mint egy ransomware. Amig nem nem szopja az ember, addig lenyegtelen, amikor igen, akkor meg mar keso. Mindenki merlegelhet, mi fontos neki.

Azzal az ismeretlen kartevoket nem hiszem, hogy el lehetne haritani, csak azokat, amik mar leleplezodtek :)

Egyrészt: http://a.te.ervelesi.hibad.hu/szemelyes-ketely

Másrészt, a ScriptBlock minden JS-ben készült, ismert és ismeretlen kártevőt elhárít, ha be van kapcsolva. Nem szégyen persze, ha nem tudod, hogy mi az, emiatt fogalmatlanul formáltál véleményt. Mikor ezt a hozzászólásomat már végigolvastad, valószínűleg majd utána nézel.

Sőt, ha még egy kicsit jobban végiggondolod, miket írsz le, remélem, az is triviális, hogy az ismeretlen kártevőket a frissítéssel sem hárítod el. Definíció szerint, pont azért, mert ismeretlenek.

mig nem nem szopja az ember, addig lenyegtelen, amikor igen, akkor meg mar keso.

Nem késő, mert visszaállítom backup-ból.

"nyitottan áll a dolgokhoz, és igyekszik a fontos dolgokhoz saját véleményt és hozzáállást kialakítani"

Az a baj, hogy ehhez nem társul a témával kapcsolatban semmiféle mélyebb tudás, így pedig sok fehér foltot tartalmaz ez a saját vélemény és hozzáállás, amelyet erőteljes személyeskedéssel, tények ferdítésével vagy figyelmen kívül hagyásával és értelmetlenül hosszú körmondatokkal kompenzál.

Amikor pedig sarokba szorítja valaki egy kényes kérdéssel, akkor ott vége van az adott szálnak és egy másik ágon újult erővel használja ugyanazt az érvkészletet, lásd például a natív kódra forduló programok és az assembly optimalizációs szálat:
https://hup.hu/cikkek/20180104/minden_amit_a_processzorbugokkal_kapcsol…

És az itt újra előjött az assembly és elő is fog jönni újra-és-újra, mert a rögeszméktől nehéz szabadulni önerőből:
https://hup.hu/node/157278?comments_per_page=9999#comment-2184032

Nem vagyok assembly-programozó, sem .NET programozó, így nem hiszem, hogy pontos, precíz szigorúan ezekhez a területekhez kapcsolódó érveléssel kellene alátámasztanom a véleményem. Az adott szálnak azért is lehet vége (és általában azért van vége), mert nem látom értelmét a további vitának, ugyanis a vitapartnerek szándékosan olyan keresztmetszetbe szűkítik a vitát, amelyből látszólag az ő mainstream álláspontjuk jön ki "nyertesen". Tipikusan ilyen példák a Saxus Mérnök Úr féle "nekem gyorsabban indul a Win10 az Athlon II-n, mint az XP", vagy az "assembly-ben lehet lassabb programot írni, mint .NET-ben" féle közhelyeken való rugózás. Holott minden fősodratú mérnök úr számára egyértelmű kéne legyen, hogy nem a nyelveken van a hangsúly, azok csak példák. Azon van, hogy gyorsabb, hatékonyabb, lighweight-ebb szoftvereket kéne írni, hogy ne kelljen szoftveres elavulás miatt kidobálni a gépeket.

Mellesleg ahhoz, hogy kritizáljam a .NET felé húzó, assembly-től távolodó szoftverfejlesztési trendeket, nem kell assembly-programozó legyek, sem .NET fejlesztő, sem szoftverfejlesztő. Ahogy a filmkritikusnak sem kell tudnia filmet vágni, rendezni, színészkedni, és minden egyebet, ami a filmkészítéshez kell. Azt kell tudnia, hogy néz ki a jó végeredmény. Én pedig elég hamar észreveszem egy szoftveren, ha bloat (rossz a végeredmény). Az a gond, hogy ahhoz, hogy hitelesnek ítéljétek meg a véleményem, elvárjátok, hogy mesteri szinten értsek az assembly-programozáshoz, a .NET-hez, vagy a processzortervezéshez. Amihez egyébként ti sem feltétlenül értetek, csak az által, hogy a fősodratú véleményvonalat osztjátok, ez kvázi mentesít alóla, mert amit elfogadtok, ahhoz nem kell szaktudás kritizálni. Ha azt mondanám, hogy a .NET gyors és fasza, vajon a .NET-ben fejlesztő Saxus Mérnök Úr nekem esne, hogy igazoljam szakmailag, mert addig nem hiszi el, hogy (nálam is) gyors és fasza? Ugye, hogy nem.

"Nem vagyok assembly-programozó, sem .NET programozó, így nem hiszem, hogy pontos, precíz szigorúan ezekhez a területekhez kapcsolódó érveléssel kellene alátámasztanom a véleményem. Az adott szálnak azért is lehet vége (és általában azért van vége), mert nem látom értelmét a további vitának, ugyanis a vitapartnerek szándékosan olyan keresztmetszetbe szűkítik a vitát, amelyből látszólag az ő mainstream álláspontjuk jön ki "nyertesen"."

Nem, nem szűkítik a vitát a mainstream álláspontjukkal, hanem -- dobpergés -- értenek hozzá és ezért tudják, amit te nem tudsz és tudják, hogy hol tévedsz.

Én például veled ellentétben éveken át programoztam alacsony szintű nyelveken és most is előfordul, hogy alacsony szinten programozok egy-egy mikrovezérlőt, ugyanakkor fejlesztettem már C, C++ és Java nyelveken is, mértem is a teljesítményüket... nem elhittem dolgokat, hanem mindig kimértem.

"Mellesleg ahhoz, hogy kritizáljam a .NET felé húzó, assembly-től távolodó szoftverfejlesztési trendeket, nem kell assembly-programozó legyek, sem .NET fejlesztő, sem szoftverfejlesztő."

Nem, nem kell legyél, viszont akkor hamar kiderül, hogy nem értesz hozzá és hülyeségeket beszélsz. Az assembly már évek óta nem ad teljesítményelőnyt, 5-10 éve nincs értelme assembly nyelven írni szoftverekben modulokat, mert a fordító jobb kódot generál a célplatformra.

"Az a gond, hogy ahhoz, hogy hitelesnek ítéljétek meg a véleményem, elvárjátok, hogy mesteri szinten értsek az assembly-programozáshoz, a .NET-hez, vagy a processzortervezéshez."

"Ha azt mondanám, hogy a .NET gyors és fasza, vajon a .NET-ben fejlesztő Saxus Mérnök Úr nekem esne, hogy igazoljam szakmailag, mert addig nem hiszi el, hogy (nálam is) gyors és fasza? Ugye, hogy nem."

Nem mondani kell, hanem tényekkel alátámasztani. Leírod, hogy mit, mikor és hogyan mértél, ekkor mások tudják reprodukálni a mérésedet és validálni a végeredményét... így működik ez, kinyilatkoztatni kevés, az másik tudományterület, ahol elég mondani valamit a híveknek.

Nem, nem szűkítik a vitát a mainstream álláspontjukkal, hanem -- dobpergés -- értenek hozzá és ezért tudják, amit te nem tudsz és tudják, hogy hol tévedsz.

Lehet, hogy értenek hozzá, de ennek ellenére is csak a mainstream közhelyeket látom. Olyanokat, mint hogy "a C fordító gyorsabb kódot generál, mint az assembler", hogy "nem lehet egy program egyszerre gyors és nem memóriaéhes", hogy "azért lassabb a szoftver, mert többet tud" és "azért kell többet tudnia, mert nőnek az igények". Ja, azt még csak úgy mellékesen hozzátenném, hogy sem tőled, sem más fősodratú mérnök úrtól nem láttam számszerű méréseket a hozzáértő™ álláspontjuk alátámasztására.

Nem, nem kell legyél, viszont akkor hamar kiderül, hogy nem értesz hozzá és hülyeségeket beszélsz.

http://a.te.ervelesi.hibad.hu/hamis-okozat

Attól még, hogy nem értek hozzá, nem biztos, hogy nem mondok igazat. Attól még, hogy nem értek hozzá, ugyanúgy lassú lesz nálam a Java-ban megírt desktop alkalmazás és gyors lesz a C++-ban megírt, assembly betétekkel optimalizált alkalmazás. Nekem ez a tapasztalatom és nem azzal töltöttem az életemet, hogy milliszekundumra kiméricskéltem, hogy melyik rajzolja gyorsabban a widget-eket és mennyivel, illetve melyik UI-nak 20 ms, melyiknek 100 ms a válaszideje. Ellenben, nem láttam még olyan Java-ban írt desktop alkalmazást, ami bármilyen azonos alapfunkciókkal rendelkező C++ desktop alkalmazásnál (GTK2, MFC, Qt) gyorsabban reagált volna a felhasználói interakcióra. Így megfelel? Mert én elhiszem, hogy te Java EE-ben írsz olyan adatbáziskezelőt, ami szarráveri az azonos C/C++ implementációkat. De én nem erről beszéltem, korábban sem. Arról beszéltem, hogy sokkal jobb lenne, ha natív szoftvereket írnának, értve ezt úgy általában a felhasználói programokra, mert a natív szoftverek kis teljesítményű gépen gyorsabbak, használhatóbbak. Nem tudom, pontosan mennyivel, de nem láttam még kis teljesítményű gépen (nem szerver/vállalati/mainframe környezetben) Java-t gyorsan futni. Sőt biztos vagyok benne, hogy nem tudsz nekem mutatni olyan, Java-ban írt torrent klienst a mai választékból, ami bármelyik, azonos funkcióval rendelkező C++-ban írtnál kevesebb CPU-t és memóriát eszik.

így működik ez, kinyilatkoztatni kevés, az másik tudományterület, ahol elég mondani valamit a híveknek.

Nem híveket gyűjtök, hanem leírom a véleményemet, a tapasztalataimat és reagálok másokéra.

Lehet, hogy értenek hozzá, de ennek ellenére is csak a mainstream közhelyeket látom.

Az nem mainstream közhely, hanem a valóság. Amiről beszélni szoktál, az meg nem a valóság, hanem egy elképzelt világ.

Olyanokat, mint hogy "a C fordító gyorsabb kódot generál, mint az assembler", hogy "nem lehet egy program egyszerre gyors és nem memóriaéhes", hogy "azért lassabb a szoftver, mert többet tud" és "azért kell többet tudnia, mert nőnek az igények".

Mutass ellenpéldát. Mondani könnyű, hogy ezek közhelyek, de amikor egy hozzáértő belinkel egy előadást a témában, ami cáfolja ezeket a kijelentéseket, akkor a normális ember elgondolkodik azon, hogy tényleg igaz, amit gondol a helyzetről...

Attól még, hogy nem értek hozzá, nem biztos, hogy nem mondok igazat.

Így van. Viszont azért beszélsz hülyeséget, mert nem értesz hozzá és fel se tűnik, hogy hülyeséget beszélsz. Amikor meg az orrod elé teszik a bizonyítékot, hogy hülyeséget beszélsz, akkor nem válaszolsz, aztán teljesen másik témában vagy szálban folytatod tovább, figyelmen kívül hagyva a tényeket.

"Attól még, hogy nem értek hozzá, ugyanúgy lassú lesz nálam a Java-ban megírt desktop alkalmazás és gyors lesz a C++-ban megírt, assembly betétekkel optimalizált alkalmazás."

Mutass pontos mérést, hogy egy ugyanarra a célra szolgáló C++-ban assembly betétekkel megírt optimalizált alkalmazás gyorsabb, mint a Java implementáció. Ne csak beszélj általánosságban, hanem mutass konkrét példát, mérésekkel, környezettel, ahogy szokás. Például JSON serializációban az első négy helyezett JVM-en futó alkalmazás: https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json

Gondolom ezt simán figyelmen kívül fogod hagyni, mert nem illik a koncepciódba. Írj olyan C++ alkalmazást assembly betétekkel, amely jobb, mint az eddigiek. Ennyit kell csak tenned, hogy bizonyítsd az elméleted.

Nem híveket gyűjtök, hanem leírom a véleményemet, a tapasztalataimat és reagálok másokéra.

Mikor mértél utoljára? Szeretnék látni tőled már egy mérést, ami alátámasztja a tapasztalataidat, mert úgy beszélsz és írsz, hogy közben nem állsz a realitás talaján.

Az nem mainstream közhely, hanem a valóság. Amiről beszélni szoktál, az meg van a valóság, hanem egy elképzelt világ.

Nem elképzelt világ. "Az én világom" létezik minden desktop felhasználónál, vagy ha nem is mindnél, 100 millió embernél, akik még XP-t használnak egy nem mai gépen.

Így van. Viszont azért beszélsz hülyeséget, mert nem értesz hozzá és fel se tűnik, hogy hülyeséget beszélsz. Amikor meg az orrod elé teszik a bizonyítékot, hogy hülyeséget beszélsz, akkor nem válaszolsz, aztán teljesen másik témában vagy szálban folytatod tovább, figyelmen kívül hagyva a tényeket.

Leírtam ennek is az okát fentebb. Ha te meg ezt nem veszed figyelembe, akkor továbbra is el fogunk beszélni egymás mellett, tehát nincs nagyon értelme vitatkoznunk, legalább is erről.

Mutass pontos mérést, hogy egy ugyanarra a célra szolgáló C++-ban assembly betétekkel megírt optimalizált alkalmazás gyorsabb, mint a Java implementáció. Ne csak beszélj általánosságban, hanem mutass konkrét példát, mérésekkel, környezettel, ahogy szokás.

Ha adsz egy tool-t, amivel a teáltalad elfogadott, mérnöki™ sztenderdek szerint meg tudom mérni, hogy adott, Windows XP-n futó grafikus desktop alkalmazás mennyi idő alatt rajzolja le a widget-jeit, és mindezek függvényében mennyi CPU-t és memóriát zabál, akkor kapsz róla mérést. Addig be kell érned azzal, hogy azt mondom, hogy nekem eddig minden Java-ban írt program lassabb volt, mint egy azonos alapfunkciókkal rendelkező C++-ban írt és többet is zabált úgy nagyjából mindenből.

Például JSON serializációban az első négy helyezett JVM-en futó alkalmazás: https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json

Igen, sejtettem, hogy egy olyan ellenpéldával rukkolsz majd elő, ami az általam említett kontextustól a legtávolabb esik. Pontosan ezért írtam le az előbb:

én elhiszem, hogy te Java EE-ben írsz olyan adatbáziskezelőt, ami szarráveri az azonos C/C++ implementációkat

Ennek ellenére, a servlet kiemelkedéséből sem következik semmilyen módon, hogy a Java általánosan erőforráshatékonyabb, mint a natív kód. Pláne, hogy valószínűleg azért van így, mert többet és jobban cache-el, mint a többi, de ez által több erőforrást is zabál. Ez azt eredményezi, hogy a Dell ServerCentral Dell környezetein ő muzsikál a legjobban, tehát ott ezt éri meg a legjobban használni, már ha a JSON serializáció a szűk keresztmetszet. Az viszont már mérnök uraságod szélsőséges menedzseri idealizmusa, hogy összesített eredményt állítasz be legjobbnak, mikor latency-ben kilencedik, framework overhead-ben pedig még a TOP 10-ben sincs benne a jávád. Ha pedig ennyire szereted a számszerű méréseket, vess az alábbiakra is egy pillantást.

Itt már sajnos nem teljesít olyan fényesen a jávád. (bár ezt simán figyelmen kívül fogod hagyni, mert nem illik a koncepciódba)

Nade akkor még egyszer, hogy biztosan megértsd: elhiszem, hogy vannak felhasználási módok és környezetek, ahol a Java jobban teljesít, mint a natív kód. Az én felhasználási módom és környezetem nem ilyen és soha nem is lesz ilyen.

Nem elképzelt világ. "Az én világom" létezik minden desktop felhasználónál, vagy ha nem is mindnél, 100 millió embernél, akik még XP-t használnak egy nem mai gépen.

http://a.te.ervelesi.hibad.hu/csuszos-lejto
http://a.te.ervelesi.hibad.hu/kozvelekedesre-hivatkozas

Leírtam ennek is az okát fentebb. Ha te meg ezt nem veszed figyelembe, akkor továbbra is el fogunk beszélni egymás mellett, tehát nincs nagyon értelme vitatkoznunk, legalább is erről.

Ha nem tudsz főzni, akkor nyilván mondhatod egy levesről, hogy nem ízlik vagy nem jó a leves; a baj akkor van, ha elkezded részletezni a szakácsnak, hogy mit kellett volna másképp csinálnia, holott nem értesz hozzá és erre azonnal rájön az, aki egy kicsit is ért hozzá.

Attól, hogy igazad van bizonyos témákban, nem kellene elkezdened megmagyarázni, hogy miért van az úgy és mit kellene másképp csinálni, de valahogy erős kényszert érzel arra, hogy saját magad szempontjából okosnak tűnő tanácsokat adj... de ennek általában hülyeség lesz a vége és közröhej tárgya leszel.

"Ennek ellenére, a servlet kiemelkedéséből sem következik semmilyen módon, hogy a Java általánosan erőforráshatékonyabb, mint a natív kód. Pláne, hogy valószínűleg azért van így, mert többet és jobban cache-el, mint a többi, de ez által több erőforrást is zabál."

Tehát több erőforrást zabál és közben hatékonyabban működik? Miből gondolod, hogy a C++ implementáció nem hoz létre cache-t? Ha kevesebb memóriát zabál, akkor több CPU használat nálad belefér?

"Ez azt eredményezi, hogy a Dell ServerCentral Dell környezetein ő muzsikál a legjobban, tehát ott ezt éri meg a legjobban használni, már ha a JSON serializáció a szűk keresztmetszet."

Más környezetben is ugyanígy muzsikál, csak méréseknél szokás odaírni a pontos környezetet, ha az ember szeretné reprodukálni a mérést. Nem azért írják oda, mert csak ott jó.

"Az viszont már mérnök uraságod szélsőséges menedzseri idealizmusa, hogy összesített eredményt állítasz be legjobbnak, mikor latency-ben kilencedik, framework overhead-ben pedig még a TOP 10-ben sincs benne a jávád."

Fogalmad nincs, hogy mit mér a latency és a framework overhead és hogy kell értelmezni a grafikont, ugye? Csak szerettél volna valamit visszaírni.

"Ha pedig ennyire szereted a számszerű méréseket, vess az alábbiakra is egy pillantást."

Ahja, ezzel két baj van:
- a JVM szerver módban indul el, pedig nem szerver-szerű a terhelés. Ez azért okoz jelentős eltérést, mert szerver módban sokkal több időt tölt indulásnál a JVM azon, hogy optimalizálja a futtatandó kódot, holott a tesztek futási ideje maximum 20 másodperc.
- a használt források nem igazi Java programok, hanem C filozófiával megírt Java programok, fájdalmas nézni, hogy mennyire rosszul implementálták a Java verziót (például kisbetűs osztálynevekkel).

"Nade akkor még egyszer, hogy biztosan megértsd: elhiszem, hogy vannak felhasználási módok és környezetek, ahol a Java jobban teljesít, mint a natív kód. Az én felhasználási módom és környezetem nem ilyen és soha nem is lesz ilyen."

Nagyszerű, de a te saját környezetedben se mérsz, csak írsz valamit, hogy mi mennyire milyen és milyennek kellene lennie. Mutass mérési eredményeket.

Sehol nincs csúszós lejtő. A tény, hogy 100 millió ember futtat hozzám hasonló desktop környezetben programokat nem közvélekedés, mivel ez nem a véleményük, hanem a felhasználói preferenciájuk, workflow-juk.

Ha én azt mondom a szakácsnak, hogy oldja meg, hogy X-1 köbméter gázból finomabbat főzzön, mint múltkor, akkor a szaktudását arra fogja használni, hogy ezt megtegye. Kivéve, ha a szakács hupu, mert akkor megmagyarázza, hogy igazából X+1 köbméter gázból kéne főzni és a közízlés szerint nem úgy finom, ahogy én akarom. Mindezt azzal fűszerezi meg, hogy mit ugatok bele, amikor amúgy se értek a főzéshez. Ha meg igen, akkor főzzek én.

Miből gondolod, hogy a C++ implementáció nem hoz létre cache-t?

Nem gondolom.

Ha kevesebb memóriát zabál, akkor több CPU használat nálad belefér?

Nem fér bele és az ezután következő "CPU/memória optimalizáció egymást zárják ki" című idealista közhelyből sem kérek, köszönöm.

Más környezetben is ugyanígy muzsikál, csak méréseknél szokás odaírni a pontos környezetet, ha az ember szeretné reprodukálni a mérést. Nem azért írják oda, mert csak ott jó.

Nem is mondtam, hogy azért írják oda, ellenben nem mutattál más helyről servlet mérést, csak innen.

Ahja, ezzel két baj van

Nem. Csak egy baj van. Az a baj, hogy két, totál eltérő, totál máshogy elkészített, totál más célú megoldást akarunk összehasonlítani, totál más környezetben.

Nagyszerű, de a te saját környezetedben se mérsz, csak írsz valamit, hogy mi mennyire milyen és milyennek kellene lennie. Mutass mérési eredményeket.

Loop: Ha adsz egy tool-t, amivel a teáltalad elfogadott, mérnöki™ sztenderdek szerint meg tudom mérni, hogy adott, Windows XP-n futó grafikus desktop alkalmazás mennyi idő alatt rajzolja le a widget-jeit, és mindezek függvényében mennyi CPU-t és memóriát zabál, akkor kapsz róla mérést.

Ha ilyet nem tudsz adni, elég az is, ha mutatsz nekem egy GUI-s torrent klienst, amit szerinted jó (nem C-s logikájú) Java programozók írtak és emiatt gyorsabb és kevesebb memóriából elvan, mint a vele azonos alapfunkcionalitású natív C/C++ torrent kliens. Akkor elhiszem, hogy az én "világomban" is megáll a "Java tud gyorsabb lenni a C++ -nál". Addig nem. Természetesen, továbbra is elhiszem, hogy a szervervilágban tud gyorsabb lenni a Java. Csak éppen annak a világnak a céljai is mások, a jellege és a technológiája is más, a felhasználási módja meg végképp.

Ha én azt mondom a szakácsnak, hogy oldja meg, hogy X-1 köbméter gázból finomabbat főzzön, mint múltkor, akkor a szaktudását arra fogja használni, hogy ezt megtegye. Kivéve, ha a szakács hupu, mert akkor megmagyarázza, hogy igazából X+1 köbméter gázból kéne főzni és a közízlés szerint nem úgy finom, ahogy én akarom. Mindezt azzal fűszerezi meg, hogy mit ugatok bele, amikor amúgy se értek a főzéshez. Ha meg igen, akkor főzzek én.

Ha meg kevesebb gázt használ, mert kínkeservesen megoldja, amit szeretnél, de közben hibázik és ezért lesz rossz a leves, akkor meg az a bajod.

A Meltdown és a Spectre pont azért keletkezett, mert a CPU gyártók igyekeztek több teljesítményt kihozni ugyanannyi energiából (ugye OPS/kWh), csak közben nem voltak eléggé körültekintőek, de akkor meg az a bajod, hogy miért csak annyit tudnak a CPU-k, mint azok a CPU-k, amelyeknél nem növelték a hatékonyságot.

Tulajdonképpen neked nem lehet olyan levest főzni, amivel elégedett lennél és te magad se tudsz főzni, csak olyan módon kritizálni, hogy közben képtelenségeket és hülyeségeket beszélsz, mert van egy rögeszméd, amitől nem tudsz szabadulni.

Nem fér bele és az ezután következő "CPU/memória optimalizáció egymást zárják ki" című idealista közhelyből sem kérek, köszönöm.

Ezt beszéld meg azokkal is, akik értik a rendszerek működését.

Ha memóriára optimalizálsz, akkor tömör kódot írsz és a lehető legtöbb dolgot a szükséges időben kiszámolod és nem tárolod le, hanem eldobod és később újra-és-újra kiszámolod; ennek az ára az, hogy több CPU erőforrás szükséges a futása közben. Ha CPU-ra optimalizálsz, akkor a ciklusokat kifejted ismétlődő kódrészletekbe, előre kiszámolt táblázatokkal dolgozol, amelyeket indításkor betöltesz vagy kiszámolsz, nem optimalizálsz agresszíven újrafelhasználható kódrészletekkel és figyelembe veszed az éppen használt hardver jellemzőit; ennek az ára az, hogy több memóriát szükséges a futása közben. A két véglet között tudsz programokat fejleszteni, nincs olyan program, ami egyszerre nyújtja a lehető legtömörebb kód- és adat-memória igényt, miközben olyan gyors, mint a CPU-ra optimalizált kód. Ilyen csak a fejedben létezik.

Én írtam programot 8 bites uC eszközre, ahol mindössze 384 bájt volt a program számára használható ROM és 16 bájt az adatok számára használható RAM és írtam már programot olyan uC eszközre is, ahol volt 64 kB RAM, teljesen más elvek mentén optimalizál az ember a két eszközre. És persze írtam programot szerver oldalra, ahol egyedül az számított, hogy mennyi az OPS/kWh arány. És olyan programot is írtam, amelyik nem volt optimalizálva, mert hamar kellett és csak egyszer volt rá szükség.

Nem is mondtam, hogy azért írják oda, ellenben nem mutattál más helyről servlet mérést, csak innen.

Te hány helyről mutattál eddig mérést? Nekem vannak saját méréseim is, amit mutattál például, azt lemértem magamnál is és megnéztem a mérés körülményeit is.

Ha adsz egy tool-t, amivel a teáltalad elfogadott, mérnöki™ sztenderdek szerint meg tudom mérni, hogy adott, Windows XP-n futó grafikus desktop alkalmazás mennyi idő alatt rajzolja le a widget-jeit, és mindezek függvényében mennyi CPU-t és memóriát zabál, akkor kapsz róla mérést. Ha ilyet nem tudsz adni, elég az is, ha mutatsz nekem egy GUI-s torrent klienst, amit szerinted jó (nem C-s logikájú) Java programozók írtak és emiatt gyorsabb és kevesebb memóriából elvan, mint a vele azonos alapfunkcionalitású natív C/C++ torrent kliens. Akkor elhiszem, hogy az én "világomban" is megáll a "Java tud gyorsabb lenni a C++ -nál". Addig nem. Természetesen, továbbra is elhiszem, hogy a szervervilágban tud gyorsabb lenni a Java. Csak éppen annak a világnak a céljai is mások, a jellege és a technológiája is más, a felhasználási módja meg végképp.

http://a.te.ervelesi.hibad.hu/bizonyitasi-kenyszer-atharitasa

Ha meg kevesebb gázt használ, mert kínkeservesen megoldja, amit szeretnél, de közben hibázik és ezért lesz rossz a leves, akkor meg az a bajod.

Majd belejön. Csak sajnos jelenleg a gázpazarláshoz van hozzászokva, mert így tanították neki a szakácsiskolában a fősodratú mérnök urak fősodrófás szakács bácsik.

Tulajdonképpen neked nem lehet olyan levest főzni, amivel elégedett lennél és te magad se tudsz főzni, csak olyan módon kritizálni, hogy közben képtelenségeket és hülyeségeket beszélsz, mert van egy rögeszméd, amitől nem tudsz szabadulni.

De lehet. Sőt én azzal is bőven elégedett lennék a 30% lassulás mellett, ha ezentúl a szoftvereket 60%-kal gyorsabbra írnák, elhagyva a bloated framework-öket és a szoftverfejlesztői kényelmeskedést.

A két véglet között tudsz programokat fejleszteni, nincs olyan program, ami egyszerre nyújtja a lehető legtömörebb kód- és adat-memória igényt, miközben olyan gyors, mint a CPU-ra optimalizált kód. Ilyen csak a fejedben létezik.

Vannak ilyen programok: Total Commander, IrfanView, SumatraPDF, WinAmp, NirSoft programok, uTorrent, Miranda NG, Microsoft Office 2003. Nem magát az alapelvet vitattam, pont ezért nem kérem közhelyként ezt a tipikus CPU vs memória választ. Arról beszéltem, hogy a Java-ban írt desktop alkalmazások ugyanazokra a feladatokra memóriából és CPU-ból is többet zabálnak.

http://a.te.ervelesi.hibad.hu/bizonyitasi-kenyszer-atharitasa

Nem magát a bizonyítást hárítottam át, hanem kértem egy segédprogramot, amivel bizonyíthatom, amit állítok, olyan módon, amit te elfogadsz. Nem ugyanaz és meglep, hogy ilyen árnyalatnyi különbségeket már nem veszel észre. Pedig még azon fősodratúak közé tartozol, akire valamennyire felnézek, a zöld, természetközeli gondolkodás és a belőle következő gyakorlati megvalósítások miatt. Mindenesetre, magamnak nem kell bebizonyítanom, hogy a Java-ban írt desktop alkalmazások zöme lassú, CPU-éhes, memóriazabáló bloatware, mert ezt számos esetben a saját szememmel láttam és felhasználás közben tapasztaltam.

Majd belejön.

Nem, nem majd belejön, hanem több gázt fog használni, mint a több szakács. Ahogy a hibás CPU-k is több energiát fognak használni a hiba kijavítása után, mint előtte. Nem lesz olyan megoldás, hogy a gyors marad és ezzel egy időben megoldódik a biztonsági hiba is. Valamit-valamiért. Ha kihagyod az ellenőrzéseket, akkor gyors. Ha beleteszed az ellenőrzéseket, akkor lassabb lesz. Csodák nincsenek, csak a kis világodban.

De lehet. Sőt én azzal is bőven elégedett lennék a 30% lassulás mellett, ha ezentúl a szoftvereket 60%-kal gyorsabbra írnák, elhagyva a bloated framework-öket és a szoftverfejlesztői kényelmeskedést.

A szoftvereket gyorsabbra írják... csak még mindig abban a bűvkörben élsz, hogy egy gonosz lobbi lassú programokat ír direkt, nincsenek bloated framework-ök, csak a fejedben, egyszerűen növekszik az a problématér, amit le kell fedni, ahhoz pedig nagyobb teljesítmény kell. A CGA monitoron is lehetett dolgozni, ahhoz kellett 16 kB memória és a 25 Hz frissítéshez kellett 400 ezer memória olvasás másodpercenként. Most 1920x1080 32 bites felbontáshoz kell 7,9 MB memória és a 60 Hz frissítéshez (hogy ne rongálja az ember szemét) kell 474 millió memória olvasás és ez csak a megjelenítés. Mondhatod, hogy mindenki dolgozzon CGA monitoron, mert ha 30 éve lehetett, akkor most is lehet, de nem fog senki CGA monitoron dolgozni, aki egy kicsit is törődik az egészségével. Ez van.

Arról beszéltem, hogy a Java-ban írt desktop alkalmazások ugyanazokra a feladatokra memóriából és CPU-ból is többet zabálnak.

Beszélni bárki tud, én is tudom mondani, hogy szerintem a Java jobb. Mi lesz erre az első kérdésed? Az, hogy bizonyítsam be. Szóval ne csak beszélj, bizonyíts.

Valóban ritka a Java-ban írt gyors program, mint a fehér holló. De azért van néhány, csak azokkal meg nem találkoznak a userek.

Például az Eclipse (főleg a 3-as széria extra pluginek nélküli alap Java környezete) meglepően gyors. Amikor először használtam (sokéve, olyan gépeken, amiket te a mai napig használsz :-) nem akartam elhinni: abban a pillanatban, hogy megnyomom a save-t, készen van a bináris, és lehet futtatni. Sőt, ha debug módban fut a program, akkor a futó programot megpeccseli azonnal, hogy az új kóddal fusson tovább. Ezek nagyon hasznos funkciók, a munkamenetet hihetetlenül megkönnyítik. Dolgozom C alapú projekten is, ott hasonló tudású eszköz nincs, és talán nem is nagyon lehetne megvalósítani sem. A VisualStudio C környezetében kilóra kevesebb kódra is hosszú másodpercekig tart egy fordítás.

(disclaimer - Ha a függőségi fában mélyen van valami, akkor kicsit tovább tart, de még úgy is gyorsabb, mint hasonló méretű C program fordítása. Ha memória-strukturális változás is van a programban, akkor nem tudja online frissíteni az alaptelepítés, bár tudtommal vannak erre eszközök, de azokat még nem próbáltam.)

Egyszer belenéztem az ECJ-be (Eclipse Java Compiler), piszkos trükkök százaival van tele, hogy gyors legyen. De tényleg gyors. És itt például valóban játszik a RAM vs CPU kérdés, mert a legfontosabb trükk az, hogy minden RAM-ban van, és csak a függőségi fában változott dolgok fordulnak újra. Tehát ameddig egy C program fordításakor minden fájlra végig kell nyálazni a stdargs.h-tól kezdve mindent, addig itt a függőségek feldolgozott objektumok formájában kéznél vannak, és azonnali eredményt kapunk.

Javában is lehet tehát gyors programot írni. De komoly ára van, ezért nem sok ilyet látni. A teljesítményre optimalizálásnak a legfontosabb kulcsa általában az, hogy amit nem csinálunk meg, az nem kerül semmibe. A legtöbb lassúnak bizonyuló GUI ugyanazt rajzolja újra ezerszer egy helyett. Az, hogy egy keretrendszer alapból mondjuk 5-ször lassabb, az csak akkor kerül előtérbe, ha ezek a problémák már megoldottak. Viszont a legtöbb esetben, ha ezeket megoldjuk, akkor már elégedett a management, és további optimalizációra nincs is szükség.

És ez mind csak duma, mert valóban nagyon ritka a gyors Java-ban írt GUI program :-). Éppen elkezdtem egy open source-nak szánt JavaFX-es programot, ami gyors lesz. Ha tudsz Java 8-at indítani, akkor majd szólok, ha kész lesz, próbáld majd ki!

Pedig hidd el, hogy tévedsz. Manapság a szoftverek komplexek, mindenféle API-t és protokollt kell támogassanak, egy csomó biztonsági szempontot figyelembe kell venni a fejlesztésnél (hiszen nagyobb a támadási felület). Plusz az ASM-ban írt kód csúnyán platform/verziófüggő, nem éri meg a fordító által akármilyen platformra optimalizált kódhoz képest.

Míg csak pár 8 bites gép volt forgalomban (Commodore és társai), meg 16 bites PC-n is az egyfelhasználós, egyfeladatos, hálózat nélküli MS/PC-DOS uralkodott, egyféle firmware, egyféle OS (nem sokféle verzióval), 0 GUI, akkor még megérte ASM-ben, gépi kódban vitézkedni, meg mindenféle órajelkímélő trükköket bevetni, sőt, motiváció is volt rá, hiszen az akkori szerény hardvereken nem is volt sok minden másképp megvalósítható, nagyon kellett trükközni, mire minden csepp pontenciált ki tudtak hozni a szűkös hardverlimitből. Azóta viszont bonyolult lett a világ, mindent netre és hálózatra kötnek, minden többfelhasználós, többfeladatos, csomó biztonsági dologra kell figyelni, multiplatformos, multi GUI-s fejlesztésekre törekednek. Ilyen megváltozott környezetben az ASM-et a hajadra kenheted, millióféle eszköz van forgalomban, nem csak PC-ből (szerver, asztali, laptop, táblagép), de mindenféle más androidos, iOS-ses platform (teló, tábla, okosóra, okoshátvakaró), ahány eszköz, annyi féle hardver, architektúra, OS, verzió, felhasználói felület, sok szerencsét ahhoz, ha mindegyikre egyenként végletekig optimalizált gépi vagy ASM-kódot akarsz írni, még egy egyszerűbb szoftvernél sem leszel vele kész 100 év alatt sem. Plusz hiába írod meg ASM-ben a kódot, a kód nem az optimalizáció hiánya miatt lassú, vagy fogyaszt sokat, hanem a kernelre, API-kra, driverekre, szerverre kell várnia (és azok miatt több a memóriafoglalás is), és ez az a túlnyomó rész, amit akkor sem tudsz felgyorsítani, lefaragni, ha Chuck Norris szinten tolod az ASM-et, és az egészet megírod fele annyi memóriaigénnyel, és lefutna a kód érdemi része fele annyi órajelciklusból, és hipertömörítéssel is zsugorítasz rajta. Megkerülni sem tudod, mert a modern OS-ek nem biztosítanak közvetlen hozzáférést a hardverhez, meg a kernel sem valós időben, valós módban dolgozik, hanem ütemez, meg cache-el, meg virtualizál, és minden erőforráshoz csak akkor enged, ott és úgy hozzáférést, ahogy ő látja jónak, optimálisnak. Egyszerűen annyira meghatározzák a futást a kernel, az API-k, a futáskörnyezet, hogy a nagy részére a programozónak nincs is ráhatása, hacsak az ASM-programjához nem rittyent össze egy komplett, összehackelt saját OS-t, külön grafikus felülettel, hálózatkezeléssel, fájlrendszer-támogatással, driverekkel, stb., és a felhasználó a hiperoptimalizált szoftverhez át nem bootol erre, de akkor már megint ott tartanánk, hogy bloat az egész, meg egy fejlesztőnek kell feltalálni mindenből a keretet, és nem lenne mindenre elég ideje, és egyféle eszköz egyféle verziója lenne csak támogatva.

Azért írtam neked múltkor a multimédiás-winampos-mpv-s topikban, hogy inkább fogyasszon az a program 100-300 MB memóriával többet, induljon el fél másodperccel lassabban, de legyen stabil, bugmentes, ne legyen tele biztonsági lyukakkal, legyen elérhető több platformra, a következő Windows update-nél vagy OS patchnél ne álljon bele a földbe, ne kelljen állandóan kilőni meg újraindítgatni, lehessen rá stabilan minden környezetben, minden régebbi verziójú rendszeren is számítani, amikor szükség van rá. Ha ez csak API-kkal, meg 100 kiló libbel, frameworkkel, és nagyobb hardverigénnyel megy, akkor úgy megy, mindennek megvan az ára. Manapság erre van igény, erre ment a világ, ehhez pedig bloatosodnia kell mindenkinek, szoftvereknek, hardvereknek, fejlesztőknek. A fedezet megvan rá, a hardverek bőven kifejlődték magukat a kellő szintre (sőt, fejlődésben lehagyták a szoftveres oldalt, ezért lehet még 5-10 éves gépeket is használni).

Mondom, az ami neked bloatnak tűnik, az csak azt jelenti, hogy az igények nőttek, a világ bonyolultabb lett, a te igényeid és szemléleted meg megrekedt több évtizeddel ezelőtti szinten, leragadtál egyfajta 32 bites PC (jó, a Turion 64 bites, de régi OS-sel ezt a részét nem használod), egyfelhasználósként használt 32 bites majd két évtizedes elavult OS-énél, és csak szemellenzősen ezek szempontjait vagy hajlandó látni a nagyobb összkép helyett. Ja, igen, előre szólok, ha nem tudsz érdemben reagálni, ne reagálj, teérvelésishibás-személyeskedés linkből nem kérek. Megsértődni meg lehet szép csendben, meg az érvelésem is lehet hibás, de attól a tények nem változnak.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

ne haragudj, nem olvastam végig hajbazer teljes munkásságát, és nem is fogom emiatt. csak és kizárólag erre a posztra kívántam reagálni, az itt olvasottak tükrében.

iderángatni más posztokból más témákat és reakciókat, szerintem méltatlan, előítéletre és rosszindulatra utal. jelen, konkrét témában szerintem nem mutatta sem mélyebb tudás hiányát, sem fehér foltokat, nem tapasztaltam sem személyeskedést, sem tények ferdítését, de könnyen előfordulhat, hogy figyelmetlen voltam, ha idemásolod ebből a topicból, mikre gondoltál, meggyőzhető vagyok.

Én viszont már végigolvastam és végigszenvedtem a munkásságának nagy részét.

"iderángatni más posztokból más témákat és reakciókat, szerintem méltatlan, előítéletre és rosszindulatra utal."

Bocsánat, de ezek megtörtént tények.

"jelen, konkrét témában szerintem nem mutatta sem mélyebb tudás hiányát,"

Fogalma nincs a sebezhetőségek kihasználásáról, hogy honnan támadhatják...

"sem fehér foltokat,"

Saját maga is bevallja sokszor, hogy nem ért hozzá.

"nem tapasztaltam sem személyeskedést,"

Akkor ez például mi a lófasz, ha nem személyeskedés? "A baj, Tisztelt Manfréd Fősodratú Mérnök Úr, hogy a hangadó kolomposok kötözködésnek, beszólásnak, arroganciának, önfejűségnek, szakmailag megkérdőjelezhetőnek tekintik azt, ha valaki a fősodratú véleményvonaltól szignifikánsan eltér és igyekszik a saját útját járni, a birkacsordához való csatlakozás helyett."

"sem tények ferdítését, de könnyen előfordulhat, hogy figyelmetlen voltam, ha idemásolod ebből a topicból, mikre gondoltál, meggyőzhető vagyok."

Linkeltem fentebb, hogy mennyire figyelmen kívül hagyta a kínos kérdéseket, aztán ugyanazt folytatta itt is, lásd assembly, mint ultimate megoldás minden problémára. Mit szeretnél még?

Ez egy permanens személyeskedés, szinte minden hozzászólásában felmerül, előkerül: "fősodratú mérnök úr"

Valaki itt már elemezte, és hajlok arra, hogy igaza van, miszerint valami múltbéli traumából fakadó erős kisebbségi érzés okozza, hogy mindenkivel szemben előveszi ezt a degradáló és gúnyos mondatrészt.

Az látszik, hogy olvas a témában, de az is látszik, hogy soha nem dolgozott olyan helyen, ahol erősen használják az IT-t, mert belátná, hogy amiket irkál, azok tarthatatlanok. Sok állítása az életet próbálja cáfolni vagy egyszerűen csak kijelenti, hogy mindenki hülye, bezzeg ő mekkora helikopter. Pökhendi, magas lóról osztja az észt és amikor lehúzta magához a beszélgető partnerét/partnereit, a szemükre hányja, hogy pökhendiek, magas lóról beszélnek, stb. Ezek között belinkeli az érvelési hibás oldalait, amikben szerintem magára ismert, ami nem tetszik neki, ezért a többiekre akarja kivetíteni azokat a hibákat, amikkel rendelkezik. Szóval egy defektes személyiség rajzolódik ki az írásaiból, aki olvas a témában, aki (sötét)zöld és mindent ennek a zöldségnek akar alárendelni, miközben nem akarja tudomásul venni, hogy másoknál más a prioritás, stb. Elég kellemetlen és frusztrált alak benyomását kelti bennem.

Örülök, hogy hasznosnak ítéled a témát, ahogy annak is, hogy valamennyi dologban egyetértünk a processzorgyártók felelősségét, a szakmai vélemények megoszlását, illetve a sajátvélemény-formálás módszereit illetően.

Fősodratú mérnök uraknak azokat a hangadó elemeket nevezem, akik minden témába - és nem csak az én témáimba - a tech-médiában fellelhető mainstream dogmákat, illetve az informatika szakma divatdiktátorainak gondosan preparált, körbemarketingezett, esetenként hatásvadász álláspontját osztják, szóról szóra ugyanazon copy-paste érvelés és gondolatmenet alapján, ahogy az a csapból kifolyott. Mindehhez esetenként szélsőségesen elitista hozzáállást társítva igyekszenek az alapjaiban másképp gondolkodókat megalázni, lejáratni, nevetségessé tenni, vagy a közösség előtt elhitelteleníteni.

Ebben a témában túlnyomórészt "bolond"-ozást, facepalm-ozást, haszontalan (kizárólag elméleti alapokon nyugvó) riogatást, hivatásos rettegést, csúsztató és túlzó betörős / autós hasonlatokat, vádaskodást, felelőtlennek bélyegzést és popcorn pattogtatást láthattunk tőlük. Az eredeti témakiírás az volt, hogyan kapcsolhatjuk ki a Spectre, Meltdown javításokat. Egy kezemen meg tudom számolni, hány olyan hozzászólás érkezett, ami szakmai választ ad erre a kérdésre, olyat, ami alapján esetleg frissíthetném a témanyitót. Ami pedig nekem igazán fáj (innen a frusztráció), hogy a szakmámat Magyarországon ilyen hangadók képviselik az egyik (ha nem a) legnagyobbnak mondható szakmai(?) fórumon.

Nem kenyerem az általánosítás, de akkor is ezt tapasztalom. Jó, valóban erős túlzás azt állítani, hogy a hazai informatika szakmai véleményvonalának fő képviselői az itt elitkedő mérnök urak. Azonban, nem kell annyira antitrendnek lenni, mint én, hogy szétszedjenek valakit errefelé, csak mert nem a legmenőbb™, legtrendibb™, legszakmaibb™, lekorszerűbb™ megoldások iránt van affinitása. És általában ugyanarról a 10-15 emberről beszélünk, akik lehet, hogy nem a szakma éllovasai, de ezen a fórumon ők kommentelnek a legtöbbet és ők erőltetik a copy-paste véleményeket.

/off Nem a szellemi képességeidre írtam azt amit, nézz utána mint jelent a közmondás.. Én szeretem a hup-ot olvasgatni, tényleg a saját, és a mások által használt/üzemeltetett rendszerek hibáiból lehet a legtöbbet tanulni. Nagyon ritkán szólok hozzá bármihez is, annak ellenére hogy napi szinten többször átolvasom a híreket, új témákat. Párszor kérdeztem itt, mindig normális hangnemben, korrekt válaszokat/iránymutatásokat/megoldásokat kaptam. De tudod, kezd elmenni a kedvem ettől, mert az utóbbi időben ahányszor felnézek ide, a fórumok fele veled van tele. A szál témája miután megjelensz kb. az 5. kommenttől kezdve elmegy egy pro-kontra idézetgyűjteménybe, a saját, komolytalan világnézeted folytonos mantrázásába. Például: "biztosan 30%" "bemagyarázza magának hogy kell neki az okostelefon" "windózikszpé/p4/stb" "engem még sosem törtek meg". És ez csak az elmúlt pár nap termése.. Semmi kedvem az agymenéseid közül kiválogatni a hasznos tartalmat. Tényleg nem értem, Trey minek engedett ide vissza. Ne fáradj a válasszal, mert nem fogom elolvasni, ezt a szálat utoljára nyitottam meg. Csak gondoltam tisztába teszem a fejedben a közmondás valódi jelentését.

" amiért korábban eltettük a pénzed, és most eszünkben sincs visszaadni a 30%-át. van erre egy jogi kategória is: termékfelelősség."

Az pc részegységpiac árazási gyakorlata szerint nem 30% a végfelhasználó pénzbeli vesztesége. Akkor amikor megvette pl csúcs Intel Core i7 processzort, egy 30%-kal alacsonyabb eredményeket tudó cpu nem 30% került kevesebbe hanem több mint 50%-kal. Sőt talán még harmad áron is talált volna 70%-on teljesítő alsóközép kategóriás processzort.

Egy másik kérdés, hogy ki vonható felelősségre. Részegységenként megvett pcnél valószínűleg az Intel még akkor is ha a kis pc boltban rakták össze. Egy Dell, HP vagy Apple pcnél viszont már szerintem ezek a cégek a felelősek, akik különben szintén jelentős extra pénzt elkérnek a csúcs Intel procival szerelt prémium modellek pár százalékos extra teljesítményéért. Ha a VW autók teljesítményének az eséséért a VW beszállítói a felelősek, mondjuk egy Bosch alkatrész és a szoftveres hibáért az Accenture, akkor a vásárló továbbra is VW-t pereli és nem a Bosch meg Accenturet.

Normális HUP-ot használok!

szerintem nem a pontos százalék mértéke vagy a perelendő jogi személy kiléte a kulcskérdés. nem vagyok jogász, ezekhez nem tudok érdemben hozzászólni. a józan paraszti logikám viszont azt mondja, hogy itt hibás termék lett értékesítve, ami vagy nem biztonságos, vagy biztonságos működés mellett nem az értékesítéskor feltüntetett teljesítményt produkálja. ez elég egyértelmű mulasztásnak tűnik, ami a végvelhasználó érdekeit vaskosan sérti, miközben az okai elég egyértelműen nem az ő hatáskörében keresendők. normál körülmények között ilyenkor kártalanítás illeti, aki a kárt (adatszivárgás / teljesítményvesztés) elszenvedi, vagy ennek a kockázatnak ki van téve, önhibáján kívül.

engem, mint végfelhasználót, eddig érdekel a történet jogi része, a többi, amit írtál, a jogászok dolga.

Amúgy, ha jól értem, akkor a hiba végső oka az, hogy a spekulatív ágakon a memória jogosultság ellenőrzés ki van spórolva, és csak utólag történik meg, tehát a spekulatív ág lefutásának sebessége függhet olyan memóriatartalomtól, amire nem lenne olvasási jog.

Végsősoron tehát egy kispórolt logika miatt van a sebezhetőség. Mintha az autóban csak egy körös lenne a fék, hogy autós hasonlat is legyen :-).

ami vagy nem biztonságos, vagy biztonságos működés mellett nem az értékesítéskor feltüntetett teljesítményt produkálja

Nope. Ugyanazt a teljesítményt továbbra is adja, ha mondjuk DOS-t használsz, ahol nincs egymástól védendő több process, nem látsz semmilyen teljesítmény-vesztést. Az oprendszer, amit a CPU futtat fog ezentúl többet dolgozni, ami természetesen azzal jár, hogy több idő kell egy-egy művelet elvégzéséhez.

BTW, melóhelyen ~150 desktop/laptop gép (Core2-től 6th gen i5-ig minden, U-s végűtől a desktopig) 5 percenként küld CPU használati adatokat (5s, 1m és 5m átlag), vannak szép grafikonjaim meg egy csomó RRD fájlom. Még azért adok neki egy hetet, de ránézve az egy hónapos grafikonokra, semmi értelmezhető változást nem látni, pedig 30% eltérést még annyi átlagolás után is észre kéne tudnom venni...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem load-ot (mármint a Unix-os "hány futáskész process van") nézek, hanem gyakorlatilag CPU üresjárati időt (Windows, NSClient++ és előbb-utóbb a NtQuerySystemInformation [https://msdn.microsoft.com/en-us/library/windows/desktop/ms724509(v=vs…] hívás SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION paraméterrel, aztán a magonkénti 100.0 - idle-t összegzi - ezen szvsz. szerepelnie kellene)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( hajbazer v | 2018. 01. 14., v – 14:19 )

Update..

  • Frissült a POSReady 2009 szekció: Nem rá lesz javítás.
  • FreeBSD-re review alatt van a patch, hamarosan várható a bekerülés. A hivatalos announcement után én is igyekszem a javítás hatástalanítását posztolni.
  • OpenBSD-ről nincs hírem. Ha valakinek van, írja meg!

( hyper80 v | 2018. 01. 15., h – 09:41 )

Bizonyos Windows 10 verzióknál más a patch száma:

Windows 10 version 1709 (Fall Creators Update): KB4056892
Windows 10 version 1703 (Creators Update): KB4056891
Windows 10 version 1607 (Anniversary Update): KB4056890
Windows 10 version 1511 (November Update): KB4056888
Windows 10 version 1507 (Initial Release): KB4056893

( uid_16313 | 2018. 01. 15., h – 10:27 )

A témafelvetés valóban provokatív egy csöppet.

Régebben hallottam olyan érveket, hogy a vírusvédelmek feleslegesek, mert csak arra jók, hogy belassítsák a gépeket [analóg mint a Meltdown/Spectre foltozások], illetve -mint ez ki is derült- a legjobb backdoor platformok, mivel alapvetöen admin jogosultsággal rendelkeznek minden felett.

Mégis, ki az a bátor, aki emiatt nem használ vírusvédelmet? Èn Windows alatt nem mernék védelem nélkül élni, ha backdoor, ha nem.
[Belegondolva már maga a Windows is egy kémszoftver egy kis rosszindulattal].

Néha meglepödök, hogy milyen weblapokon jelez be a Bitdefender, hogy fertözött.

--
robyboy

Régebben hallottam olyan érveket, hogy a vírusvédelmek feleslegesek, mert csak arra jók, hogy belassítsák a gépeket [analóg mint a Meltdown/Spectre foltozások], illetve -mint ez ki is derült- a legjobb backdoor platformok, mivel alapvetöen admin jogosultsággal rendelkeznek minden felett.

Nem backdoor platform, de marha nagy támadási felületet ad (a víruskeresőnek minden formátumot támogatnia kell úgy is, hogy szabályos a fájl, úgy is, hogy nem az, és mivel minden fájlműveletnél dolgozik, egy-egy sebezhetőséget könnyű kihasználni is).

Mégis, ki az a bátor, aki emiatt nem használ vírusvédelmet?

Lehet élni nélküle is, csak elég sok áldozattal járhat és körültekintően kell kialakítani a rendszert. Pl. csinálhatod azt, hogy kérdés nélkül _minden_ rendszerindításkor snapshotból visszaállsz egy korábbi verzióra, a felhasználói mappákat meg átirányítod egy fájlszerverre, amin akár 5 percenként snapshotolsz.
És akkor innentől játszik az, hogy amikor frissítened kell valamit (mondjuk böngésző, Java, rendszer, driverek stb.), akkor új snapshot kell, tehát hosszú távon is törődés-igényes, nem csak induláskor. De működtethető alternatíva.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Kaspersky-éket pont azért csapták ki az USA-ból, mert kémkedett a vírusvédelmük (vagy szimplán politikai okokból).
De hülyék is lettek volna, ha nem használják ki ezt a lehetöséget. Eleve beteg orosz vírusvédelmet rakni amerikai eszközökre (és fordítva).

A második példád egy elméleti lehetöség, ami abszolút nem életszerü. Most komolyan: szerinted ezt bárki csinálná így?
Szerintem azért sem életszerü, mert nem biztos, hogy azonnal a tudomásodra jut, hogy megferözödött a rendszered, innét kezdve aztán abban sem lehetsz biztos, hogy a snapshot, amit visszaállítasz vajon tiszta-e?

--
robyboy

A megbízunk-e a víruskeresőben, hogy nincs benne backdoor témakör... hát ja. Csak ez akkor tényleg messzire vezet, mert akkor miért bízol meg az OS-ben, a HW firmware-ben (lásd ME), ... Nem auditálhatsz minden egyes kódsort, meg ha auditálsz is, pl. egy Spectre szintű sebezhetőséget (amiről nem feltételezheted, hogy nem backdoor volt eredetileg ;) ) hány évtizedig nem szúrtak ki?

A snapshot kényelmesen lehet külső eszközön, amit a futó rendszer nem ismer (mivel úgyis kell hálózati eszköz, triviálisan PXE boot, az imagelő rendszer átbillenti, hogy local vinyót bootoljon, a local vinyón levő rendszer meg átböki, hogy legközelebb netről indítsa az image-előt). Innentől kezdve automatizáltad az image visszatételét és (ha az image update-jekor [amit air gapben intézel, víruskeresővel átnézett pendriveról] meg kell adnod a jelszót [image telepítéshez elég egy ro hozzáférés, a módosításához rw kell], akkor sehogy sem tudja piszkálni még egy célzott támadás sem az image-t)

És persze, hogy marha kevesen használják így [*] (és lássuk be: ők virtualizálnak és a virt gépet snapshotolják), de működhet.

[*]: ad abszurdum, anno csináltam egy egy gigás pendrive-ra egy bootolható Linuxot, ami egy nagyon csúnyán kiherélt (gyakorlatilag minden összetevő kuka, tömörített rendszerpartció, ...] XP virtuális gépet indított VirtualBoxban, aztán kilépés után visszaállította a snapshotot. Már csak annyi kellett volna hozzá, hogy hálózatra pakolja a user adatokat [nem tette, mert nem arra kellett].

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A fenti megoldásnál még talán egyszerűbb is lehet egy sima live CD újraírható lemezen. Alkalmanként készítesz egy új build-et naprakész csomagokkal, és felülírod a korongot egy új verzióval.

Talán még Windows-zal is megoldható lenne egy live CD-ről bootoló rendszer, ami ramdiskbe, vagy memória híján vinyóra dologozik, ami minden boot közben formázódik. (a virtualizációt elkerülendő)

( mark7 | 2018. 01. 15., h – 19:51 )

Ehhez csak annyit, hogy te a elit felső 10 ezret képviseled a i7-3770 processzoroddal.
Vannak ismerőseim, akiknek M-ban vett komplett laptopja alig drágább, mint neked csak a processzorod.
Persze, tudjuk hogy nem szabad 150 ezer alatt új laptopot venni, de sokak csak a 80 ezrest engedhetik meg maguknak. Árulni viszont szabad.
Ők már eddig is panaszkodtak, hogy a vele vett 8, 10-es W használhatatlanul lassú.
Nekik 1%-os lassulás is fájdalmat okoz.

Ne kezd már el ezt te is. Használtan az i7-3770 30k HUF körül van online oldalakon, ha kis szerencséd van (mert valaki meg van szorulva, vagy bontó ad túl gyorsan nagyobb tétel szállítmányon, vagy jó licitet találsz), akkor még akár olcsóbb vételt is ki lehet fogni. Egyáltalán nem olyan nagy luxus ma már, 5 éves matuzsálem proci. Fórumokon elég sok embert látok ilyen 6-8 gen. i5-i7 K-s procikkal, meg elég durva, hasonló generációs Xeonokkal meg Ryzenekkel, na, az a luxus, és meg mellépasszintják vízhűtéssel a 1080-as vagy 1080 Ti GTX-et, 200-250k-s kártyák (ezekre szokta írni a Prohardver, meg a hwsw, hogy „népkártyák”, mert a nép megengedheti magának ugyebár, főleg a magyar).

Múltkor hajbi is rázendített, hogy az i5-3340M-em micsoda csillióbloat luxusproci, aztán a vicc az, hogy valamelyik Ryzen rekordfordításos HUP hírnél mért mindenki defconfigos kernelfordítási időt, és én értem el a leggyengébb eredményt az egész oldalon az i5-3340M, meg az i7-2620M procijaimmal. Ja, tényleg atombloat mindegyik, ilyen percekkel hosszabb idővel kullogtam ezekkel archaikus mobilprocikkal a sor legvégén.

Laptopot kb. 200 alatt nem szabad venni. 80 ezerért is van tűrhető, csak nem újonnan kell venni, hanem használtan üzleti laptopot. Sokan nem értenek hozzá, elmennek 80k-val új laptopot venni, és hazavisznek egy Atom-os, meg Celeron N-es hulladékot, ami már újkorában sem jó semmire, mert egy átlag Facebook-oldaltól letérdel, de legalább se rendes hűtés, rövid időn belül elemeire hullik, zsanér lötyög, stb.. Ráadásul mindezt úgy, hogy a legtöbb embernek nincs is szüksége laptopra, mert nem hordozza, csak hát a laptop a divat, az asztali gép meg ciki, mert ott ugyanazért a pénzért sokkal nagyobb teljesítményt kapsz, és könnyebb bővíteni, szerelni is.

1% lassulás lófütykös tejszínhabbal. Amelyik gépnek tényleg ez a -1% számít, az enélkül is használhatatlan már, és rég csereérett.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Te pedig kérlek, ne folytasd a mindent pénzben mérünk szélsőséges idealizmust.

Akármennyibe is kerül az i7-ed, az nem járható út, hogy a szoftverek erőforráséhsége miatt dobálunk ki működő hardvereket. Ráadásul, egy régi AMD (pl. egy Turion), vagy egy Core2 bőven rendelkezik az alapfelhasználáshoz szükséges erőforrásokkal. Még Full HD videó is lemegy rajta (természetesen csak natív lejátszóval).

csak nem újonnan kell venni, hanem használtan üzleti laptopot

Na, ebben az egyben egyetértünk.

mert egy átlag Facebook-oldaltól letérdel

Ami azért van, mert egy átlag Facebook oldal a legnagyobb bloatware. Egy VKontakte oldalról ez már nem mondható el, mert ott legalább webfejlesztőék tisztában vannak azzal, hogy Oroszországban nem divat minden évben megvenni a legújabb hardvert, ezért ki van optimalizálva (vagy lehet, hogy nincs így, csak én gondolom, de nekem minden szempontból sokkal gyorsabb). Nehogy már megint a hardver gyengesége legyen a bloatware. A Facebook funkcionalitását egy natív szoftver egy P3-ason elvinné, normálisan megírva.

1% lassulás lófütykös tejszínhabbal. Amelyik gépnek tényleg ez a -1% számít, az enélkül is használhatatlan már, és rég csereérett.

Épp arról van szó, hogy az 1% kizárólag az elitkedő, csiligyors i7-tel operálgató fejlődésmániásoknak, ha valamennyit számít, mert elég sznobok ahhoz, hogy számítson, egyébként abban egyetérthetünk, hogy effektíve nem számít egy ilyen processzoron. Nekem sem számítana, de még a Turion 64-emen sem. A lassulás azonban nem 1%, hanem 30%, effektíve pedig egyre több, ahogy mész vissza az időben a processzorok tekintetében.

Ez mindennel így van nála. Olvas valamit, meg úgy gondolja, hogy úgy van, és akkor onnantól a mantrája lesz. Nem néz utána, nem méri le. Ha meg valaki rávilágít neki a tényekre, akkor az idealista-kapitalista, fejlődést divatból erőltető mérnök úr lesz, aki automatikusan hazudik, meg érvelési hibákat vét.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

A 30% pontosan akkor került szóba, amikor még csak előzetes mérések voltak, akkor is egy tág intervallum magasabb értéke. Azóta vannak pontosabb mérések, amik elég vegyes képet mutatnak. Te ennek ellenére még a 30 százalékkal dobálózol.

Mi ez, ha nem félelemkeltés? Csak épp nem a hiba hanem a frissítések ellen.

Konkrétan idézek abból a cikkből, ami a HUP-on jelent meg a témával kapcsolatban talán elsőként, a javítások publikálása előtt:

"Sajnos a patchek hatása mind Windowson, mind Linuxon teljesítménycsökkenés, amely az előzetes mérések szerint - a taszktól és processzorokról függően - 5-30% közé tehető."

Ehhez képest vannak újabb mérések többféle környezetben, és helyzetben, és tény, hogy vannak olyan felhasználási módok, ahol a javításoknak köszönhetően nagyobb a visszaesés, de még ma is fixen a 30 százalékkal dobálózni nevetséges és hiteltelenné tesz.

Csak csöndesen megjegyzem, mert látom, hogy megy az ekézés ezerrel, én sajnos tapasztaltam ezt, méghozzá kedvenc lövöldözős játékom közben, 126-ról 80-ra esett alkalmanként a fps, amit elég durvának találok, szóval biztosan van határozottan tapasztalható hatása, más kérdés, hogy milyen hardverkörnyezetben.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Azért az a 80fps sem vészes

Hát köszönöm szépen. Csodálkoztok (Frankó Mérnök Úrral az élen), hogy nem töröm magam egész estés méricskélésekkel, mikor ez rá a válasz, hogy "áh jó lesz az még neked, ne aggódj". Egy multimilliárd dolláros cég rajtatok kereste magát degeszre úgy, hogy közben silány minőségű, gyári hibás terméket kaptatok. Amikor meg már kiderült, ugyanúgy piacra dobták a következő hibás szériájukat is, "áh jó lesz az még ezeknek" alapon. Ti pedig maximálisan az ő profitérdekeiket képviselitek, ezzel a szélsőségesen vadkapitalista, korporatokrata idealizmussal és passzív agresszióval.

Volt a hsz. végén egy ":-P", ez az egyik. A másik, hogy te állítod folyamatosan, hogy 3% lassulás van - viszont aki állít valamit, az prezentáljon megismételhető, jól dokumentáltan önmaga vagy más látal végzett mérési adatokat és leírást a mérésről.
A "piacra dobták a következő hibás szériájukat is" kapcsán fel lett hívva a figyelmed arra, hogy egy új generációs CPU fejlesztése kb. 5, azaz öt év. Ha te vállalhatónak tartod azt, hogy öt évnyi fejlesztés mehet a kukába, és vállalható az, hogy ennyi ideig senki (sem az Intel, sem az AMD, sem pedig az ARM lapkák gyártói) nem hoz ki új cpu-t, mert az ominózus sérülékenységet okozó elvi hibát már nem tartalmazó processzort terveznek, nos, akkor baromira el vagy tévedve, illetve megkérdezem, hogy ebben az általad elvárt új processzor kibocsátása nélküli időszakban mi legyen? Álljunk meg a mai szinten, küldjük el a hardverfejlesztőket átképzésre (nincs új SoC, nem kell új hardvert tervezni köré), az alaplapok tervezését végző mérnökök is menjenek zabot hegyezni? Vagy hogy a búbánatban képzeled el?

Lesz@rom az Intel/AMD meg az összes gyártó profitérdekeit - az én érdekem az, hogy a feladatomat el tudjam kényelmesen, elfogadható időráfordítással végezni. Ehhez meg tetszik, vagy sem, a feladatok által érintett adatok mennyisége, a feladatok bonyolultságának a növekedése miatt bizony nem elég egy 4-5 évvel ezelőtti CPU, hanem folyamatosan menni kell előre a teljesítményben, illetve a működés optimalizálásában is.

Van, amire jó egy eldő generációs rpi, vagy épp az Atomprocesszoros Aspire One netbook, de van, amire nem, amire kell a nagyobb CPU, a több RAM - elsősorban munka terén, de szórakozásra is.

De azért a patch kiadása nem öt év, azt esetleg meg lehetett volna várni, hogy már javított mikrokóddal és rendszerrel mérjük meg az új cpu sorozat teljesítményét. Akkor legalább az új cpu-val az ember tényleg azt kapná, amit kipróbált, és amiért fizetett. (A patch is hamarabb meglett volna, ha a gyártó prioritásként kezeli.)
Őszintén remélem, hogy legalább azon processzorok esetében, amit azóta adtak el, hogy tudtak a hibáról, elveszít az intel (és mások) egy-két pert, már csak azért is, hogy óvatosságra nevelje őket.

Ah igen, Wintach! Meg Tseng! Az fenomenális cucc volt a maga idejében.

A helyzettel kapcsolatban meg, csak egy része a problémának az, hogy drasztikusan is csökkenhet a teljesitmény, a másik része, hogy a delikvens nem ezért fizetett, amikor kiadta a pénzt a cuccra.

Kocsis példa (fantáziátlan vagyok megint): veszek egy Ferrarit, aztán egy nap leszabályozzák max. 300 km/h-ról mondjuk 200-ra, mert leég a motor. Biztos nem örülnék neki, mert nem EZT vettem meg.

--
robyboy

A Turion procikat nem ismerem tényleges erőben, még sose használtam. A C2D-val lehet mit kezdeni valóban, nem egy erős proci, de el lehet vele lenni. A titka, hogy nem XP-nél kell leragadni, meg nem feltétlenül Win10-et erőltetni rá, hanem fel kell tenni egy rávaló linuxot soványabb grafikus felülettel, meg lehetőleg kell hozzá min. 4 giga RAM, meg egy olcsóbb SATA SSD, bár akkor már talán a Win10-et is elviszik tűrhetőbben, mégse az való rá.

A 30% a mániád lett. Néhány előzetes mérés jósolt ennyit, hogy EGYES feladatoknál lehet ez a maximum teljesítménycsökkenés, nem az, hogy minden gépen, minden szoftvernél ennyi. Ahol mértek is hasonló csökkenést, azok szerverek voltak, nem home PC-k, amelyeken inkább 0-3% közötti a lassulás ténylegesen, de inkább a 0-hoz közelebb. Ráadásul azt sem kell elfelejteni, hogy ezek csak korai patchek, ahogy lesz egyre több tapasztalat a témában, meg új védekezési technikák, meg finomítanak a patcheken is, úgy még ennyi teljesítményveszteség sem lesz. Leül a hírérték, megnyugodnak a kedélyek, és világos lesz, hogy az a 30% csak pánikkeltés volt, amit a szenzációhajhász média felkapott. Ez már most valószínű ilyen tesztek alapján:
https://www.phoronix.com/scan.php?page=article&item=pre-pcid-kptiretpol…

Senki nem mondta, hogy a régi procikat és gépeket ki kell dobni. Lehet fejleszteni őket, vagy el lehet tenni pótgépnek (csak mindennapos feladatokra nem kell erőltetni őket), vagy valami kísérletezős, linuxos vagy BSD-d másod/harmadgépnek. Meg XP és Win7-10 helyett érdemes Linuxot tenni rájuk, hiszen ezeken amúgy sem játszanak általában, hogy Win kelljen rá.

Az i7 meg hiába hangzik luxusnak, nem mindegy, hogy új vagy használt, hányadik generáció, milyen kiadás, mobil vagy asztali, hány magos, i7 és i7 között óriási különbségek lehetnek teljesítményben, árban, GPU-erőben, mindenben. Egy sima (nem MQ/HQ-s) mobil i7 szinte fele sincs teljesítményben az azonos generációs asztalihoz képest (fele annyi mag/szál, alacsonyabb alap/turbóórajel/fesz, kevesebb cache, kisebb TDP), egy ultralow voltage U-s proci, meg még annál is sokkal gyengébb, szinte már csak a nevében i7, asztaliból inkább az i3 környékét hozza csak, vagy még azt sem, generációtól is függ. Csak az Intel hülye kategórizálása, annyit jelent, hogy a saját generációban, a saját platformján (mobil, vagy desktop) hogy áll a többi azonos generációs-platformos Intel procihoz képest, lényegében csak azt jelöli ez az elnevezés, hogy felső kategória, de már azt sem, mióta van i9-es is. Már korábban is előfordult, hogy pl. a mobil i5-i7 között azonos generációban alig volt különbség, némi órajel csak, vagy +1 MB cache, de alig volt erősebb egyik, mint a másik. Ugyanez volt a C2D-nál is, ott is nagy különbség van generációk és kiadások között, akár 10×-es sebességkülönbség is előfordulhat a korai leggyengébb és kései legerősebb között. Ezt nem szabad elfelejteni, mikor ilyen általános i7, C2D, viszi a FullHD-t általánosításokkal dobálózunk a levegőben. Tudom, hogy imádod a konkrétumokat és a számokat, méréseket kikerülni, de reméljük leszoksz róla előbb-utóbb.

A Turion procikat nem ismerem tényleges erőben, még sose használtam. A C2D-val lehet mit kezdeni valóban, nem egy erős proci, de el lehet vele lenni. A titka, hogy nem XP-nél kell leragadni, meg nem feltétlenül Win10-et erőltetni rá, hanem fel kell tenni egy rávaló linuxot soványabb grafikus felülettel, meg lehetőleg kell hozzá min. 4 giga RAM, meg egy olcsóbb SATA SSD, bár akkor már talán a Win10-et is elviszik tűrhetőbben, mégse az való rá.

A 30% a mániád lett. Néhány előzetes mérés jósolt ennyit, hogy EGYES feladatoknál lehet ez a maximum teljesítménycsökkenés, nem az, hogy minden gépen, minden szoftvernél ennyi. Ahol mértek is hasonló csökkenést, azok szerverek voltak, nem home PC-k, amelyeken inkább 0-3% közötti a lassulás ténylegesen, de inkább a 0-hoz közelebb. Ráadásul azt sem kell elfelejteni, hogy ezek csak korai patchek, ahogy lesz egyre több tapasztalat a témában, meg új védekezési technikák, meg finomítanak a patcheken is, úgy még ennyi teljesítményveszteség sem lesz. Leül a hírérték, megnyugodnak a kedélyek, és világos lesz, hogy az a 30% csak pánikkeltés volt, amit a szenzációhajhász média felkapott. Ez már most valószínű ilyen tesztek alapján:
https://www.phoronix.com/scan.php?page=article&item=pre-pcid-kptiretpol…

Senki nem mondta, hogy a régi procikat és gépeket ki kell dobni. Lehet fejleszteni őket, vagy el lehet tenni pótgépnek (csak mindennapos feladatokra nem kell erőltetni őket), vagy valami kísérletezős, linuxos vagy BSD-d másod/harmadgépnek. Meg XP és Win7-10 helyett érdemes Linuxot tenni rájuk, hiszen ezeken amúgy sem játszanak általában, hogy Win kelljen rá.

Az i7 meg hiába hangzik luxusnak, nem mindegy, hogy új vagy használt, hányadik generáció, milyen kiadás, mobil vagy asztali, hány magos, i7 és i7 között óriási különbségek lehetnek teljesítményben, árban, GPU-erőben, mindenben. Egy sima (nem MQ/HQ-s) mobil i7 szinte fele sincs teljesítményben az azonos generációs asztalihoz képest (fele annyi mag/szál, alacsonyabb alap/turbóórajel/fesz, kevesebb cache, kisebb TDP), egy ultralow voltage U-s proci, meg még annál is sokkal gyengébb, szinte már csak a nevében i7, asztaliból inkább az i3 környékét hozza csak, vagy még azt sem, generációtól is függ. Csak az Intel hülye kategórizálása, annyit jelent, hogy a saját generációban, a saját platformján (mobil, vagy desktop) hogy áll a többi azonos generációs-platformos Intel procihoz képest, lényegében csak azt jelöli ez az elnevezés, hogy felső kategória, de már azt sem, mióta van i9-es is. Már korábban is előfordult, hogy pl. a mobil i5-i7 között azonos generációban alig volt különbség, némi órajel csak, vagy +1 MB cache, de alig volt erősebb egyik, mint a másik. Ugyanez volt a C2D-nál is, ott is nagy különbség van generációk és kiadások között, akár 10×-es sebességkülönbség is előfordulhat a korai leggyengébb és kései legerősebb között. Ezt nem szabad elfelejteni, mikor ilyen általános i7, C2D, viszi a FullHD-t általánosításokkal dobálózunk a levegőben. Tudom, hogy imádod a konkrétumokat és a számokat, méréseket kikerülni, de reméljük leszoksz róla előbb-utóbb.

A Turion procikat nem ismerem tényleges erőben, még sose használtam. A C2D-val lehet mit kezdeni valóban, nem egy erős proci, de el lehet vele lenni. A titka, hogy nem XP-nél kell leragadni, meg nem feltétlenül Win10-et erőltetni rá, hanem fel kell tenni egy rávaló linuxot soványabb grafikus felülettel, meg lehetőleg kell hozzá min. 4 giga RAM, meg egy olcsóbb SATA SSD, bár akkor már talán a Win10-et is elviszik tűrhetőbben, mégse az való rá.

A 30% a mániád lett. Néhány előzetes mérés jósolt ennyit, hogy EGYES feladatoknál lehet ez a maximum teljesítménycsökkenés, nem az, hogy minden gépen, minden szoftvernél ennyi. Ahol mértek is hasonló csökkenést, azok szerverek voltak, nem home PC-k, amelyeken inkább 0-3% közötti a lassulás ténylegesen, de inkább a 0-hoz közelebb. Ráadásul azt sem kell elfelejteni, hogy ezek csak korai patchek, ahogy lesz egyre több tapasztalat a témában, meg új védekezési technikák, meg finomítanak a patcheken is, úgy még ennyi teljesítményveszteség sem lesz. Leül a hírérték, megnyugodnak a kedélyek, és világos lesz, hogy az a 30% csak pánikkeltés volt, amit a szenzációhajhász média felkapott. Ez már most valószínű ilyen tesztek alapján:
https://www.phoronix.com/scan.php?page=article&item=pre-pcid-kptiretpol…

Senki nem mondta, hogy a régi procikat és gépeket ki kell dobni. Lehet fejleszteni őket, vagy el lehet tenni pótgépnek (csak mindennapos feladatokra nem kell erőltetni őket), vagy valami kísérletezős, linuxos vagy BSD-d másod/harmadgépnek. Meg XP és Win7-10 helyett érdemes Linuxot tenni rájuk, hiszen ezeken amúgy sem játszanak általában, hogy Win kelljen rá.

Az i7 meg hiába hangzik luxusnak, nem mindegy, hogy új vagy használt, hányadik generáció, milyen kiadás, mobil vagy asztali, hány magos, i7 és i7 között óriási különbségek lehetnek teljesítményben, árban, GPU-erőben, mindenben. Egy sima (nem MQ/HQ-s) mobil i7 szinte fele sincs teljesítményben az azonos generációs asztalihoz képest (fele annyi mag/szál, alacsonyabb alap/turbóórajel/fesz, kevesebb cache, kisebb TDP), egy ultralow voltage U-s proci, meg még annál is sokkal gyengébb, szinte már csak a nevében i7, asztaliból inkább az i3 környékét hozza csak, vagy még azt sem, generációtól is függ. Csak az Intel hülye kategórizálása, annyit jelent, hogy a saját generációban, a saját platformján (mobil, vagy desktop) hogy áll a többi azonos generációs-platformos Intel procihoz képest, lényegében csak azt jelöli ez az elnevezés, hogy felső kategória, de már azt sem, mióta van i9-es is. Már korábban is előfordult, hogy pl. a mobil i5-i7 között azonos generációban alig volt különbség, némi órajel csak, vagy +1 MB cache, de alig volt erősebb egyik, mint a másik. Ugyanez volt a C2D-nál is, ott is nagy különbség van generációk és kiadások között, akár 10×-es sebességkülönbség is előfordulhat a korai leggyengébb és kései legerősebb között. Ezt nem szabad elfelejteni, mikor ilyen általános i7, C2D, viszi a FullHD-t általánosításokkal dobálózunk a levegőben. Tudom, hogy imádod a konkrétumokat és a számokat, méréseket kikerülni, de reméljük leszoksz róla előbb-utóbb.

Egyetértek, hogy használtan lehet olcsóbban régebbi, nagy teljesítményű gépet venni.
Laptop nem való játékra vagy kernelfordításra. Ilyen dolgokhoz rendes, nagy PC kell.

Ahogy az Intel is ígérte, ahogy meglesznek a GCC és egyéb optimalitások ( értsd. szoftveresen javítják az Ő tervezési hibájukat a hw-ben) a lassulás mértéke csökkenni fog, és átlagos felhasználáskor (nem SQL meg Web sever) valószínűleg fel se fog tűnni.

Szinte teljes mértékben igazad van!
Kivéve abban hogy i7-es processzor elterjedt széles tömegeknél.
A 150-et is javítani akartam felfele.
Pont erről beszélek, a TV-s, egyéb ujság reklámok ontják a akciós Celeron-os laptopokat, az átlag reklámfogyasztó meg beveszi, ahelyett hogy megkérdezne valakit, aki azt tanácsolná, vegyen használt, márkás i5 üzletit.
Meg valakinek csak új kell, szélesvásznú képernyővel, az üzletiek meg 4:3-ak általában.
Ennyiért meg valóban letérdel pár megnyitott weblapnál.
Egy ismerősöm, aki tanácsot kért, lehetett rábeszélni arra hogy ha már úgyis részletre veszi a laptopot, akkor 100 ezres helyett vegyen egy i5-öt, azzal elvan egy darabig.

Na jó, próbáljuk meg mégegyszer, mert nem jön át. Nem bántani akartalak, csak nem értem, hogy mit szertnél mondani. Megpróbálom dekódolni, mi történt.

mark7: Meg valakinek csak új kell, szélesvásznú képernyővel, az üzletiek meg 4:3-ak általában.

kroozo: "Te mikor láttál utoljára üzleti laptopot? :)" Értsd: Cáfolnám, Nem, már nagyon régen nem, gyakorlatilag keresni kell őket, ha egyáltalán van még ilyen.

mark7: "Jó lehet hogy 16-osak már, de sok 14"-os, azért tűnik kicsinek egy 15.6-hoz képest"

kroozo: nem nagyon érti, hogy hogy jön ide a méret, mikor eddig képarányról beszéltünk, meg azt se, hogy milyen 16os, de gondolja, hogy az ugyanaz mint a 15.6. Megemlíti, hogy még mindig van bőven 15.6, bár a 14 is simán jó lehet, nem véletlen terjed az az üzleti szektorban sem.

mark: belinkel 1 db 12.1es üzleti HPt.

Szóval az van, hogy nem értem mit szeretnél mondani, miért nem jó egy használt üzleti laptop, ami még csak véletlen sem 4:3 már vagy 10 éve, bőven van belőle 15.6os, még akkor is, ha létezett más méretben is?

(bár szerintem aki egyszer a kezébe vett egy 14est, az utána nagyon nem akar majd nagyobbat. Kivéve, ha eleve a 15.6 is kicsi volt, és igazából kell valami 17es böszme mondjuk grafika miatt)

Azt meg végképp nem értem, hogy jön ez ide, szerintem ez a hozzászólás, amire reagáltál úgy két hét távlatából, bőven korábbi. Meg miért akarnék én azzal dolgozni? Ráadásul nem tudom, hol olvastad, hogy jó programozó vagyok, ami ugyan hízelgő, csak kár, hogy nem vagyok programozó :)

Egy legalább 8-10 éve minden lapos 16:9-es vagy 16:10-es, az üzleti gépek is.
Abban igazad van, hogy az i7 nem elterjedt széles tömegeknél, mivel veszik inkább újonnan a szart, később meg nem bővítenek, mert nem tudják, hogy lehet, vagy olcsó, használják bővítés nélkül a gépet, ha meg már használhatatlan, akkor vesznek újat, újra valami szart. Attól viszont, hogy nincs elterjedve, nem jelent elitizmust. Nyilván, aki nem ért hozzá, és nem tájékozódik, nem kér segítséget, az jellemzően szart fog venni akármiből, nem csak PC-nél, laptopnál is.

De igen, nem kell feltétlenül az i7-re rámenni, az i5-ök se rosszak, aztán ha később olcsóbb lesz, meg lesz rá keret, akkor bele lehet dobni i7-est is használtan. Nyilván nem akkor kell venni, mikor még 50-100 ezerbe kerül az adott proci, mert akkor tényleg csak az elit tudja megfizetni.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

a) Igen, az i7-3770 egy gyors proci, még ma is. Azért, mert a gépet fizikai számolásokhoz vettem, a processzor és a memória a fontos volt. Ugyanakkor nem dobtam ki egy átlag laptop árát gamer videokártyára. Nekem leginkább az tűnt fel az ilyen-olyan boltok akcióiban szép számban elkelő gépeknél, hogy kicsi diszk, gyenge proci, kevés memória, brutál videó, amivel egy épp akkor aktuális játék elmegy ezerrel. És most ezeknek a felhasználói akarják pár százalék teljesítményveszteség elkerülése érdekében kockáztatni az adatokat, ami nem biztos, hogy csak nekik okoz kárt (a legegyszerűbb eset, ha valami olyan helyen dolgoznak, ahol az én adataim is ott vannak, de ha csak a bankkártyájukról lopnak le emiatt pénzt, jó eséllyel a bank magára vállalja, ami miatt én is kisebb kamatot kapok).

b) Érdekes, én például szöveget szerkeszteni, táblázatot kezelni, sőt, az ezen a gépen futó számolásokat kicsiben kipróbálni egy ennél sokkal egyszerűbb laptopon is tudok (mondjuk kb. 1/10-e teljesítmény). Csak nem a játékkal van a gond?

c) Ismét: elismerem, hogy ez a CPU gyártók sara. Ha leperelnek róluk egy csomó pénzt, mondjuk vissza kellene adni a tulajdonosoknak, nem bánom. De nem az a megoldás, hogy nekem nem telik gyors gépre, ezért inkább kockázatot okozok mindenkinek.

( lcsaszar v | 2018. 01. 17., sze – 13:43 )

A Microsoft a következőket írja:

Warning

Customers who only install the Windows January 2018 security updates will not receive the benefit of all known protections against the vulnerabilities. In addition to installing the January security updates, a processor microcode, or firmware, update is required. This should be available through your device manufacturer

Akkor most ez a visszacsinálás csak a szoftveres javításokra vonatkozik? (nyilván igen)
A firmware update-et nem kell visszacsinálni, hogy visszakapjuk a gyors de sebezhető gépet? Az nem lassítja le a processzort? Működhet egyik javítás a másik nélkül, vagyis felléphet-e bármilyen probléma, ha csak a firmware javítást tettük fel?

Érdekes módon az MSI elhatárolódik a témától, nem ad ki BIOS frissítést az alaplapjaihoz, mondván, hogy ez nem az ő termékeit érintő probléma.

Igen, jól érted a dolgokat. Ha nem akarsz teljesítményvesztést, akkor a mikrokód sem lehet fent, ha kell, BIOS-t kell miatta downgrade-elni. De nem javaslom, annyit nem lassítanak ezek a foltok, hogy megérje sebezhetővé tenni a gépet, csak nagyon speciális esetben léphet fel olyan felhasználási kör és extrém lassulás, aminél meg kell lépni, de ez biztosan nem átlag felhasználású desktop PC szintje.

Az MSI-nek teljesen igaza van, ők teljesen ki tudják magukat vonni, majd a sérülékenységes aktívan kihasználó támadó kód megnézi, hogy MSI lapon fut-e, és ha látja, hogy igen, akkor mégse lendül támadásba, hanem inaktiválódik, hiszen az MSI haragját senki nem meri kivívni, még orosz, ukrán és kínai hackerek sem. Az NSA-t, Pentagont, CIA-t, Mossadot nyugodtan lehet hackelni, de az MSI az fele se tréfa. Az egészséges önbizalom sose árt.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

( tovis v | 2018. 01. 17., sze – 13:56 )

Még kellhet :(

* Én egy indián vagyok. Minden indián hazudik.

( hajbazer v | 2018. 01. 23., k – 23:44 )

Mai HWSW: Torvalds: az Intel Spectre javítása egy hulladék

Ezt se én mondtam. Ahogy az utóbbit se.

"
" target="_blank">A Lyft egyik mérnökének mérése szerint a Haswell(?) Xeon processzorokat alkalmazó AWS C4 instance-en magas terhelés mellett nagyjából 20 százalékot lassított az IBRS bekapcsolása, amely a szakember állítása alapján az Intel aktuális legújabb mikroarchitektúrájának számító Skylake végrehajtási sebességét kevésbé veti vissza."

Természetesen, a fősodratúak byilvánvalóan még mindig szkeptikusak a lassulásban, előszeretettel mosdatják az Intelt és próbálják rámkenni a felelősséget. Na és azokat, akik a FUD kampány és a tech-média hisztériakeltése következtében frissítettek a gányolt javításokra, értük ki vállalja a felelősséget? Jahogy senki... Persze, ezt nem is kell megkérdezni, mert felelőssége itt csak a fogyasztónak van. A gyártónak nincs, ők majd a fogyasztók kárára "minden problémát orvosolnak". Aki pedig nem fogadja el feltétel nélkül az orvoslást, az kérem felelőtlen. Idáig sikerült süllyednie ennek a szakmának. Undorító, felháborító és tenyérbemászó.

Több, mint egy éve volt processzormultiéknak orvosolni a hibát, erre előállnak egy instabil, gány szar megoldással, a két korábbi arrogáns húzásuk mellett, miszerint a CEO eladta a részvényeit a bejelentés előtt (!), és miszerint az Intel már rég tudott a hibáról, mikor a Coffee Lake-et piacra dobta. Azt gondolom, hogy egy ilyen vállalatnak semmiféle keresnivalója nincsen egy tisztességes piacon.

Értem. Mert a faxtuggyamilyen cégnél faxtudjavalaki, egy bizonyos generációhoz tartozó proci egyik modelljének faxtudjamilyen instance blablájánál fingott egy -20%-ot, akkor már ki kell vastagítani, és mindenki rohanjon a falnak. Szerintem még a haswelles felhasználók többségét sem érinti ez ilyen szinten, csak megint a pánikkeltés megy. Tudom, énérvelésihibámponthuperszalmababszem.

Mondjuk örülnék, ha nálam már lassítaná ezt a 20-30-50%-ot, csak lenne fent, de még mindig nincs, és még úgy 2 hónapig fogom élvezni a sebezhetőség áldásait. Torvalds csak nyugodtan kussoljon, és szép csendben essen neki, hogy még a 4.15 RC10-be bekerüljön az a nyüves Spectre1 elleni folt, ne kelljen vele a 4.16-ig várni, utána ha kész van, lehet az Intelre mutogatni, meg mindent leszarozni.

Nem vagyok fősodratú, és az Intelt sem védem, mert egy szar, szemét cég. Egy éve még nem ismerik ugyan sebezhetőséget, de 7 hónapja már igen, és még csak most kezdtek töketlenkedni a mikrokóddal, amit nem tudtak normálisan megcsinálni elsőre, azt is csak a legújabb procikhoz. Közben meg a türelmi időt arra használták fel, hogy kihozzák a Coffee Lake-et, kiadhassanak egy újabb sebezhető szériát. Az apjuk kaszá't, az is a rét közepén, motorossal. Az ilyen szemétség miatt legközelebb a Google helyében nem is adnék az Intelnek türelmi időt, hanem mindjárt a felfedezésről szóló tanulmány elkészültének napján publikálnám a sérülékenységet (gondolom ezt azért nem lépnék meg, mert ők is sok Intel-procit használnak). Nincs értelme értesíteni őket, meg türelmesnek lenni, mert ezt az időbeli haladékot csak arra használják, hogy sunnyogjanak, és ne javítsák ki a hibát.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Értem. Mert a faxtuggyamilyen cégnél faxtudjavalaki, egy bizonyos generációhoz tartozó proci egyik modelljének faxtudjamilyen instance blablájánál fingott egy -20%-ot, akkor már ki kell vastagítani, és mindenki rohanjon a falnak.

Mert a faxtudjavalaki, egy bizonyos generációhoz tartozó proci egyik modelljének faxtudjamilyen instance blablájánál fingott egy -1%-ot, akkor már mindenki rohanjon a falnak lélegezzen fel, könnyebbüljön meg, hiszen az Intel ura™ a helyezetnek.

Tudom, énérvelésihibámponthuperszalmababszem.

Nem érvelési hibád. Egyszerűen csak ellentmondasz önmagdnak, miközben akaratlanul is mosdatsz egy velejéig arrogáns nagyvállalatot.

Persze ezzel még nincs vége: "Mondjuk örülnék, ha nálam már lassítaná ezt a 20-30-50%-ot, csak lenne fent" vs "ha kidobni nem is kell, de az a 30% teljesítményveszteség, amit belengetnek, az nagyon durva átlag felhasználói szinten is."
Gratulálok! Győzött a FUD Raynes önkontrollja felett és most már választja az akár 50%-os lassulást is, csak ne kelljen félelmetes™, veszélyes™, javítás nélküli operációs rendszert használnia. Más kérdés, hogy valódi bűnözők által elkövetett Spectre/Meltdown támadásról és ebből következő adatvesztésről nem érkezett még hír, de az elméleti síkon való riogatás manapság olyan trendi, hogy bűn lenne nem élni vele.

Torvalds csak nyugodtan kussoljon, és szép csendben essen neki, hogy még a 4.15 RC10-be bekerüljön az a nyüves Spectre1 elleni folt, ne kelljen vele a 4.16-ig várni, utána ha kész van, lehet az Intelre mutogatni, meg mindent leszarozni.

Torvalds csak nyugodtan hívja fel a figyelmét a Linux közösségnek (és úgy egyébként az egész felhasználóközönségnek, akikhez eljutnak a szavai), milyen kockázatot vállal, ha valaki egy velejéig arrogáns, felelőtlen, látszatinnovációkban utazó, a piacot defektes termékekkel elárasztó nagyvállalattól készül processzorokat venni a jövőben. A jelenben pedig jobb lesz, ha elgondolkodnak egy class action perbe való becsatlakozásról.

Nem vagyok fősodratú, és az Intelt sem védem, mert egy szar, szemét cég.

Köszönöm.

Az Intel lehet, hogy egy szar, szemét cég, de sajnos majdnem teljesen monopól helyzetben van/volt évekig.
Erről a vásárlók is tehetnek, hogy a Cyrix eltűnt, az AMD meg vegetált évekig, mert senki nem vette meg az ő procijaikat. Most élvezhetünk, hogy a csodás Intel lett a piacon az egyeduralkodó.

Szerintem a többversenyzős piac tudná az ilyen hibákat enyhíteni , kiküszöbölni.

Nagyon remélem hogy az Intel minden egyes Intel CPU tulajnak ad valamiféle kártérítést, kupont vagy valamit, amivel enyhíti a felhasználókat ért kárt.

De, sőt az ARM is. Ami Intel-specifikus, az a Meltdown (és az is érint 1-2 ARM-ot, de AMD-t elvileg nem). A Spectre meg gyakorlatilag minden gyártónál ott van. De azért az Intel a szemét :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A Spectre meg gyakorlatilag minden gyártónál ott van. De azért az Intel a szemét :)

Nem azért szemét az Intel, mert a Spectre minden gyártónál ott van, vagy mert nincs ott minden gyártónál. Az Intel azért szemét, mert a CEO eladta a részvényeket a hibák nyilvánosságra hozatala előtt, piacra dobta a Coffee Lake-t a hibák ismeretében és értelmes javítás hiányában, tűzoltás közben kísérleti nyúlnak használja a processzoraikat megvásárlókat és szar, szemét, gány "megoldásokat" eszközöl. Persze, nyugodtan védd csak tovább multiékat.

AND
A cég a mikroarchitektúrális különbségekre hivatkozik, illetve arra, hogy egyelőre senki sem tudta demonstrálni processzoraikon a Spectre 2-t.

https://www.hwsw.hu/hirek/58342/spectre-2-meltdown-intel-xeon-linus-tor…

De te gondolom 7/24-ben azon dolgozol hogy produkáld a hibát, amivel alátámasztod a vádaskodásod.

Erről a vásárlók is tehetnek

Tehetnek, de azt se felejtsd el, hogy az Intel gyakorlatilag a vásárlók megtévesztésével ígért nagyobb sebességet egy koncepcionálisan szar, összegányolt hardveren, amit most vissza kell lassítani, hogy a gányolásukat kompenzálják. A vásárlók hibája a birkalogika és a naivitás. Az Intelé a szándékos megtévesztés, a tervezésen való spórolgatás, a hibán való ~1 évig semmittevő ücsörgés, meg amit már felsoroltam minden fősodratú mérnök úrnak (de szinte hiába).

Sehol nem védtem semmilyen vállalatot. Tanulj meg olvasni. A bár csak lassítana 20-50%-ot részt szarkasztikusan értettem, tudom, hogy nem fog annyit lassítani. Fent van a Meltdown, Spectre2 elleni patch, és linuxon konkrétan eddig a hetek során 0% lassulást tapasztalok (lehet ki lehetne mutatni néhány % lassulást szintetikus benchmarkokkal, de nem azok futtatására vettem a gépet, hanem használni). Ugyanerről számolnak be más linuxos és windowsos felhasználók is a vonatkozó topikokban, alig van ember, aki érezhető lassulást tapasztal (ők jellemzően valami speciális szoftvert használnak, vagy szerveren tapasztalják). Nem hinném, hogy pont a Spectre1 elleni folt fog annyira lassítani, hogy használhatatlan legyen a gép. Idővel ráadásul az is valószínű, hogy még finomítani fognak a foltokon is, nem kéne egy összekapkodott kezdeti foltozás alapján végleges következtetéseket levonni.

Egyébként meg nem szemétkedni meg személyeskedni akarok, de nem kéne ezzel a Spectre/Meltdown témával foglalkoznod. Annyira durván elment a XP-Turion64-P3 (meg ASM-DivX-Winamp) triód mellett az idő, hogy téged egyáltalán nem érint, azoknak a platformoknak tényleg mindegy, hogy van-e folt ezekre a sérülékenységekre, folt nélkül is nettó használhatatlanok már értelmes dologra, max. csak ilyen hiperminimállinuxot faragós hobbira tudok ilyen gépet elképzelni, vagy DOS/Win9x-es retró játékok futtatására, de netezéshez meg mindennapi felhasználáshoz már vicc kategória.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

( hajbazer v | 2018. 01. 30., k – 08:59 )

Még a múlt héten Linus Torvalds hozta a formáját és helyretette az Intelt annak fősodratú bérkernelfejlesztőjével, David Woodhouse-zal együtt.

https://www.hwsw.hu/hirek/58342/spectre-2-meltdown-intel-xeon-linus-tor…

Végül a Microsoft is belátta, hogy a processzoroknak nem csak a működése defektes, hanem a gyártó mérnökurai sincsenek a helyzet magaslatán, így részben hatástalanította a fent listázott javításokat.

https://www.hwsw.hu/hirek/58369/microsoft-intel-spectre-meltdown-frissi…

Természetesen, processzormultiék részéről továbbra sincs semmiféle hajlandóság a gyakorlati felelősségvállalásra (visszahívás, kártérítés stb.).

"Egyébként mit értesz fösodratú alatt? Az én szótáramból hiányzik ez a szó..."

"Szvsz. "mainstream"... nekem is fájt, mikor leesett."

":) Vegülis a nyelvben az a legszebb, hogy alakíthatjuk, nemdebár?"

A "mainstream" és a "fősodor" egy jelentésű, vélhetően régi folyami hajózási szakkifejezések.
A köznyelv nagyjából ugyanabban az időben, és azonos átvitt értelemben vette át, mindkét nyelvben.
Egyik legkorábbi hazai, köznyelvi (irodalmi) említése Arany János tollából történt, az egyik versében, 1862 táján.
(persze, az ő korában a kifejezéshez még nem kötődtek pejoratív felhangok, sem magyar, sem angol köznyelvi használatban)

-
"Attempting to break SpeedLock can damage your sanity"

Ja, mint ahogy van slágerzene és rétegzene, avagy mainstream jazz vs. progresszív jazz, ugyanúgy kell legyen mainstream informatikus és alternatív informatikus, aki szembemegy a fősodorral? Hát, lehet hogy van olyan munkahely, ahol elnézik a kísérletezést. Végül is attól megy előre a világ...

Az az informatikus, aki nem lát túl a munkahelyi trendeknek való megfelelésen, az bizony kőkeményen fősodratú. Nem kéne elfeledni, hogy a Linuxot milyen elvek mentén dolgozó (kezdetben egyáltalán nem fősodratú) mérnököknek köszönhetjük. Az, hogy a befektetők által lufiként felfújt, majd hőlégballonná erősített tech-multik hiénákként telepedtek rá a szabad szoftverre és a nyílt forrásra, már más kérdés.

Egy ideje olvasgatom az ámokfutásodat. Valamit nem értek: te mennyit dolgoztál olyan környezetben, ahol egy hibának, ha nem is rád, de a munkaadódra nézve, súlyos következményei lehetnek?

Mert nekem nagyon úgy tűnik, hogy egy percet sem.
Mintha létezne bármi ami tökéletesen működik.
Itt az egyetlen amit az Intelnek és egyes vezetőinek felróható, az a probléma kezelése.
Hogy a javított mikrokód hibás, talán több gondot okoz, mint a javítatlan, az szimpla kapkodás következménye, ami bárkivel előfordulhat, ha hirtelen ekkora tömegű szar szakad a nyakába.

Alapvetően igazat lehetne adni neked, azt kivéve, hogy hirtelen szakadt a nyakukba. Több mint fél éve volt az Intelnek javítani a hibát, ők már 2017 júniusa óta tudnak róla. Csak a nyilvánosságnak újak ezek a sérülékenységek.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Fél év nagyon kevés erre, ha helyes a sejtésem a hiba mélységéről. Különösen, hogy nem is kizárólag inteles belső hibáról beszélünk, mert más gyártók, sőt, talán más architektúrák is (pl.IBM Power?) érintettek.
Egy ilyen meló érzésem szerint felér egy új proci tervezésével, mert ugye a működőképességet fenntartani, minél kevesebbet lassítani a processzorokon stb. stb. stb., azért nem egy egyszerű dolog. És mindezt esetleg kissé pánikolva. (tudom, itt mindenki tökéletes, rezzenéstelen nyugalommal veszi az ilyen akadályokat...)
Szóval én meg tudom érteni az inteles szakembereket, hogyha nem lett megfelelő minőségű amit elsőre kiadtak.
Remélhetőleg lassanként gatyábarázzák.
A vezetőket, marketingeseket nem annyira...

+1, ráadásul úgy, hogy a disclosure-ig csak a nagyon-secu-nagyon-megbízható teamek dolgozhattak rajta, sima "mezei" alkalmazottak nem (meg kell válogatni, hogy ki tudhasson az ilyen hibákról és minél kevesebb embernek szabad róluk tudnia, annál kisebb eséllyel szellőzteti meg valaki az iparági megegyezett dátum előtt [mint ahogy az most is történt, "szerencsére" csak egy héttel])

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez már nevetséges, SzBlöki, ne haragudj. Titoktartási szerződést mire találták ki? Csak nem arra, hogy ha valakinek eljár a szája, akkor a gatyát is leperelhesse róla az Intel? A Google nem parázott, hogy kiszivárog? Ennyi erővel a Google is gondolkodhatott volna így, ír hozzá saját patch-et, aztán csak utána adja ki az információkat. Siralmas, ahogy a minden jó ahogy van és a minden a mi biztonságunk érdekében történik idealizmusokban kapálózva védeni próbálod ezt a gánykonszernt. Csak tudnám, miért.

Ha egy Intel/AMD/IBM/MS/security@kernel.org/Google/whatever alkalmazott miatt idő előtt kiderül egy ilyen, Te, mint végfelhasználó mi az istenre mész azzal, hogy az Intel/AMD/IBM/MS/security@kernel.org/Google/whatever a szart is le tudja perelni az adott emberről az NDA miatt? Te magyarázod mindig a nagy gonosz multik felelősségét (és hogy milyen felelőtlenek), amikor meg felelősségteljesen járnak el, akkor az a baj.

minden jó ahogy van

Lófaszt van jól, mert még így is előre kellett hozni a disclosure tartalmát.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

mi az istenre mész azzal, hogy az Intel/AMD/IBM/MS/security@kernel.org/Google/whatever a szart is le tudja perelni az adott emberről az NDA miatt?

Amire most mennek a végfelhasználók az elbaszott javítással, amit vissza kellett vonni. Ha valaki ki akarta használni ezeket a hibákat a januári megjelenés óta, már rég kihasználta. Az NDA arra jó, hogy az alkalmazott miatt ne derüljön ki. Az a lényege, hogy elvegye az alkalmazott kedvét attól, hogy járjon a szája. Mellesleg, azt se feledd, hogy attól még, hogy azt mondja valaki, hogy "branch target injection", hekkerék nem fogják egyből odavillantani az exploitot. Hasonlóképp ki kell kutatniuk, mint Google apánknak. Innentől kezdve azzal védeni az Intelt, hogy a végfelhasználókat akarta megvédeni a "védtelen" szituációtól nem más, mint szélsőséges idealizmus, arrogáns, korporatokrata marketing-bullshit "érvelés".

Na ja, csak ahhoz, hogy effektív védelmi mechanizmust építs ki, nem elég annyi, hogy "branch target injection". Viszont egy név is lehet elég arra, hogy kárt okozz vele - anno a BadLock bugnál [ugye szintén coordinated disclosure, mert több terméket érintett, mert protokoll-szintű hiba volt], miután a név és a felfedező kiléte már nyilvánosságra került, de a hiba részletei még nem, többen a Samba-féle locking mechanizmus kódját kezdték vizsgálni (mivel évekkel korábban a hibát felfedező Metze commitolt egy lock.c fájlt) - és találtak a BadLocktól teljesen független hibákat (hogy végül kihasználható sebezhetőség is lett-e belőle, azt passz).

Az NDA arra jó, hogy az alkalmazott miatt ne derüljön ki.

Melyik az idealizmus, bízni abban, hogy N ember az NDA miatt még véletlenül sem szivárogtat semmi infót (ami ráadásul nem csak az lehet, hogy egy sör mellett elmondja egy havernak, elég az, ha akarva-akaratlanul egy publikus repóba commitol a fixhez tartozó kódot - lásd, ahogy most ténylegesen kiszivárgott [Linus beolvaszotta a KPTI-t] és azt a tényt, hogy a black hatek az összes fontosabb projekt és cég github repóit követik, pont az ilyen commitokért) vagy megbízni M kézzel válogatott emberben (ahol M nagyságrendekkel kisebb, mint N!), akik már bizonyították a megbízhatóságukat? (principle of least privilege és ilyesmik...)

Vagy szerinted komolyabb állami pozíciókba akkor ezentúl ne kelljen átvilágítást csinálni, mert ha aláíratjuk velük, hogy ejnye-bejnye lesz, ha kifecsegik a dolgokat, az elég?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nézd öregem, vagy tartsd magad ahhoz, amit a blogomban műveltél, vagy gondolkodj el rajta, hogy esetleg nem kéne a másikat basztatni csak azért, mert épp elgurult a gyógyszered.
Pont a fentire céloztam az ortopéd sebészet kapcsán.
Ha tudsz normálisan, akkor maradj annál, ha nem, akkor meg akadj le rólam teljesen. Ennyi. Köszöntem.

ui: a néhány évvel ezelőtti levélváltásunk óta már tudom, hogy ültünk egy asztalnál... :D

Senki nem várta el az Inteltől a tökéletes megoldást. Én sem. Tisztában vagyok vele, hogy mindenki hibázhat és ha Intel iránti perfekcionizmust sejtesz a véleményem mögött, akkor nagyon rosszul látsz.

Jelen esetben arról van szó, amit és ahogy az Intel művel és ahogy kezeli a helyzetet. Az a szélsőségesen vadkapitalista, profithajhász, önző és arrogáns magatartás, ami nálam kevésbé "ámokfutó" elemek zsebében is nyitja a bicskát. Szeretnélek emlékezetetni az alábbiakra.

  • Az Intel közel egy éve tud a hibáról és már azelőtt is tudott a hibáról, hogy a Coffee Lake piacra dobásra és sorozatgyártásra került volna. Mégis piacra dobták.
  • Az Intel CEO-ja a hiba nyilvánosságra hozása előtt eladta az Intel részvényeit. Ez egy ilyen kulcsfontosságú pozíció esetén egy valamit biztosan jelez: ő sem bízik már a saját cégében és abban, hogy megfelelő megoldást talál a problémára.
  • Az Intel közel egy éve tud a hibáról és a piszkos kutatómunkát már mások elvégezték helyette. Neki két dolgot kellett volna csinálni: megfelelő javítást írni és tesztelni. Egyik sem sikerült. Ami nagyobb baj, hogy a magatartásukat elnézve, nem is állt szándékukban.

Az Intel minden esélyt és segítséget megkapott arra, hogy saját tökéletlenségét ellensúlyozza. Mégis a felelősséget a vásárlóikra hárítva, őket kísérleti nyúlnak használva, velejéig arrogánsan viselkedett. Erre sajnos már nincs mentség. Persze védd csak nyugodtan multiékat.

Nagy kár, hogy mikor kivételesen írsz egy olyan hozzászólást, amivel egyet lehetne végre érteni, a végén agyonvágod valami hülyeséggel. Szinte mindennel egyetértek, amit írsz az Intelről, csak azzal nem, hogy nem állt szándékukban a javítás. Szerintem igenis szándékukban állt, csak szimplán hanyagság vagy szervezetlenség miatt elcseszték. Mentségük akkor sincs rá persze, jobban kellett volna ezt az egészet kezelniük. Azért ők nem a Kovács Józsi garázsbété, akinek se erőforrása, se semmije nincs hibajavításra/tesztelésre.

Nem csak az Intel vizsgázott rosszul, a MS, Canonical is elkapkodta az első frissítést, meg a Linux kernelesek is késnek a Spectre1 elleni tisztán szoftveres javítással. Gondolom az Apple és a többi cég sem jeleskedett jobban a sérülékenységek javításában. A média szintén levizsgázott, sok félinformáció, dezinformáció, pánikkeltő anyag látott napvilágot (jajj, milyen sokat fog lassítani a patch, használhatatlan lesz a gép, mindenkinek ki kell dobnia).

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Úgy vélem, a fősodratúaknál egy kicsit kifinomultabb igazságérzettel és kritikai rálátással rendelkezel, mégis van benned egy AzértMégseLehetIlyenSzarAVilág, illetve egy NemVagyokHájbazer exception handler, aminek köszönhető az, hogy az ilyen fogalmazásbéli apróságokon is képes vagy fennakadni, ráadásul úgy, hogy félre is értelmezed.

Azt írtam, hogy az Intel úgy viselkedett, mint akinek nem állt szándékában megfelelő javítást eszközölni. Ami igaz, amennyiben hanyagok voltak. Márpedig azok voltak, amivel te is egyetértesz. Szerintem van különbség aközött, hogy nem állt szándékában javítást eszközölni (egyáltalán nem akarta megjavítani), illetve nem állt szándékában megfelelő javítást eszközölni (lehet, hogy meg akarta javítani, csak igénytelenül tette, netán úgy akart tenni, mintha meg akarná javítani, de sokkal jobban érdekli, hogyan adja majd el a küszöbön álló új processzorait és dobatja ki a régieket).

A média szintén levizsgázott

A tech-lakájmédia tette a dolgát: elültette a bogarat a fülekben, hogy ezentúl ha valakinek lassulgat a gépe, rögtön asszociáljon az ultimate megoldásra: újat kell venni és ki kell dobni a régit. Mellesleg kihagytál egy nagyon fontos elemet a zárójeles felsorolásodból, mégpedig a csúnya, gonosz hekkerekkel való riogatást. Tekintettel arra, hogy a lakájmédia máig képtelen volt előhozakodni olyan incidensről szóló hírrel, amelyben a szóban forgó sebezhetőségeket használta ki valaki. Az Intel és szoftvermultiék bénázása pedig rengeteg előnyt adott a csúnya, gonosz hekkereknek. Miért lehet, hogy mégse nyomják fel milliószámra a böngésző memóriaterületéről kiolvasott Facebook- és GMAIL-jelszavakat? Tán nem azért, mert sokkal több a Spectre/Meltdown elméleti füstje, mint a gyakorlati lángja?

Akkor máskor fogalmazz egyértelműbben. Semmiképp nem szándékos hanyagságot feltételezek (azt már eleve nem is hanyagságnak, hanem szándékosságnak kéne hívni), szerintem csak spórolni akartak az erőforrásokkal, aminek kapkodás, csúszás, hibázás lett a vége. Nyilván a szándékuk nem lehetett ez, szakmailag senki nem égeti magát szándékosan. Mindenképpen javítaniuk kell normálisan a Spectre-sérülékenységeket, hiszen az új procik hiába nem fogják tartalmazni, akkor is negatív visszhangja lehet, hogy ha majd azokban is felfedeznek sérülékenységet, akkor majd az sem lesz, vagy nem rendesen javítva, hanem még újabb procit kell majd akkor is venni. Ilyet meg az Intel sem engedhet meg magának, hiába lehúzó cég.

Nem hinném, hogy átlag felhasználó bármilyen rés vagy sérülékenység miatt VALÓS veszélyben lenne, ha tart az adatairól biztonsági mentést, és amennyiben az accountjain nem tárol olyan értéket, olyan személyes adatot, amivel vissza tudnak élni. Akkor csak némi kényelmetlenséget okoz, ha felnyomták a gépét, újratelepíti, accountot vagy visszaszerzi, vagy nyit másikat. Nyilván, ezért ennél könnyebb egy hivatalosan nem sérülékeny, nem lyukas rendszert használni. Biztonsági mentés meg mindig kell amúgy is, a háttértár is bármikor beadhatja a kulcsot. Szépen mutatja, hogy még gépek százmilliói használnak nem támogatott OS-t, szoftvert, verziókat, és az ilyen felhasználók többsége is éli vígan az életét. Jó, lehet kicsit lassabb a gép, mivel néha botnetbe van kapcsolva (de ilyenkor azt hiszik, hogy régi a gép, vagy tisztán a Windows hibája), vagy többször kell vírus miatt újrahúzni a Nyilászárókat, de nagy lelki törést nem szokott okozni, és még azért őket sem szokták hekkelni minden nap. Néha beszopnak egy kis ransomware-t is, olyankor megy a sikongatás, hogy jajj a családi képet és doksik odalettek, de aztán gyorsan meg szoktak nyugodni, hogy majd lesznek helyettük újak, mentés, frissítés, támogatott szoftver az továbbra sem kell, mert lassít, meg munkás, olyannal csak a gyávák meg a kockák tökölnek feleslegesen.

A Spectre2-nél a korrektebb cikkek megjegyezték, hogy elég nehezen használható ki. A Meltdown könnyebben, de az már minden OS-en kapott tisztán szoftveres javítást, amihez nem kell új mikrokód.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

( icee | 2018. 02. 03., szo – 21:16 )

Ezt a topicot jobb lenne törölni, ez egy kritikus hardware vulnerability amit patchelni kell mitigálás szempontjából nem pedig kikapcsolni... otthon a kis linux desktopodon kapcsold ki, hátha attól megjavul az wireless egér netalán működni fog a mikrofon a skypeban. Linux desktop éve van idén is amúgy?

Ezzel nem értek egyet.
Ahol fontos, hogy patch-elve legyen a rendszer (ha majd egyszer lesz teljeskörű, valódi, működőképes javítás rájuk), ott talán van annyi szakértelem, hogy egy ilyen topic ne tudja lebeszélni a javítások telepítéséről a felelősöket.
Otthon meg aki nem akar patch-et, update-et telepíteni, az sok esetben most sem teszi. Gondolod, hogy ezzel az ismertetővel bárkit, aki egyébként felrakná a javításokat, sikerülhet rávenni azok törlésére?
Ha nem, akkor miért kellene törölni?

Nem értek egyet amit írtál.

Ahol fontos, hogy patchelve legyen a rendszer, az nagyrészt a hozzá nem értők számítógépe. Ott kevés esetben van szakértelem. A user vagy nem nyúl hozzá az oprendszer frissítési folyamatához, vagy a warezpistike esetleg eljut oda, hogy a hiba jelentőségét nem megértve eljut egy ilyen leírásig, mert zavarja hogy pár fps-t esett a kedvenc játéka.

"Otthon meg aki nem akar patch-et, update-et telepíteni, az sok esetben most sem teszi."

Szerintem ez nem igaz. A legtöbb otthoni felhasználó gépén a win10 frissül automatikusan, könnyen letiltani se tudják. Nem is törődnek vele, esetleg bosszankodnak azon milyen zavaró, hogy megint frissíteni kell.

Egyébként pont ez az egyik réteg "Ahol fontos, hogy patch-elve legyen a rendszer". Home, hozzá nem értő felhasználók. Szóval nem, nincs szakértelem :) (Persze a másik réteg a hozzáértő rendszerüzemeltetők, ez oké).

És kinek ártanak ezek a bejegyzések? A warezpistikéknek, akik csak annyira értenek hozzá, hogy rájönnek hogy emiatt lassult be a gépük, és nem értik meg a kockázatot, az a pár fps a gétéáötben pedig fontosabb.

És nem ugyanezek a pistikék azok, akik helyből tiltják a windows update-et, mercsak?
Egyébként netre kiengedett desktopon és publikus szervereken nehezen tudok elképzelni olyan helyzetet, amikor az update-ek általános mellőzése elfogadható alternativa lenne.

Bármennyire is szeretnéd gyengeelméjű, hozzánemértő egységsugarúaknak feltüntetni WarezPistikééket, sajnos megint szélsőséges idealizmusok vakvágányára jut a gondolatmeneted, minek okán irreálisan leegyszerűsítve próbálod ábrázolni a kis modellvalóságod, aminek természetesen semmi köze az igazihoz.

Ahol fontos, hogy patchelve legyen a rendszer, az nagyrészt a hozzá nem értők számítógépe.

Így igaz. A hozzánemértőknek™ pedig fogalmuk sincs, mi az a Spectre vagy a Meltdown, sőt, a HUP-ról se nagyon hallottak úgy egyébként. Tehát, mint szegény™, kiszolgáltatott™ hozzánemértők™ biztonsága™ fölött anyáskodó, hivatásos rettegő, itt az ideje, hogy végre lenyugodj. Ők még csak a topik címét se fogják látni.

warezpistike esetleg eljut oda, hogy a hiba jelentőségét nem megértve eljut egy ilyen leírásig, mert zavarja hogy pár fps-t esett a kedvenc játéka

A gondolat második felében kezd érdekessé válni a történet, mert itt már bekapcsol a bullshit generátor is. Mert ha gondolkodnál, mielőtt leírsz valamit, és elitkedés helyett értő olvasással olvasnád akár ezt a topikot, akár az egész fórumot, akkor látnál jó példákat arra, hogy nem WarezPistikékről van szó, hanem olyanokról, akik pontosan tudják, mit vállalnak a javítások kikapcsolásával, továbbá hozzáértőként nem süllyedtek le arra a kényelmi szintre, hogy az operációs rendszertől várják a számítógépük megvédését, mint tette azt a frissítésmániás, fősodratú mérnök urak túlnyomó többsége.

"Otthon meg aki nem akar patch-et, update-et telepíteni, az sok esetben most sem teszi."

Szerintem ez nem igaz. A legtöbb otthoni felhasználó gépén a win10 frissül automatikusan, könnyen letiltani se tudják. Nem is törődnek vele, esetleg bosszankodnak azon milyen zavaró, hogy megint frissíteni kell.

Sajnos itt sem sikerült HZ Mérnök Úr sorain értő olvasással végigfutnod. Nos, aki nem akar patch-et, update-et telepíteni, az függetlenül WarezPistike vagy hozzáértő kilététől, be fogja állítani úgy a rendszerét, hogy az ne telepítsen frissítéseket. Ehhez elég egy Google vagy YouTube keresés és máris ki vannak kapcsolva. Ja és itt se kell tudni, mi az a Spectre/Meltdown.

És kinek ártanak ezek a bejegyzések? A warezpistikéknek, akik csak annyira értenek hozzá, hogy rájönnek hogy emiatt lassult be a gépük, és nem értik meg a kockázatot, az a pár fps a gétéáötben pedig fontosabb.

Egyrészt, még mindig nem láttuk valódi, rosszindulató kihasználását az említett hibáknak, csak riogatást, hisztériakeltést, hivatásos rettegést. Ha gondolod, linkelhetsz. A PoC az nem az, az csak egy elmélet bizonyítása, laboratóriumi körülmények között. Másrészt, a böngészők már foltozva vannak, JS alapon a sebezhetőségek nem használhatók ki. Harmadrészt, ha WarezPistike van olyan hülye, hogy minden kapott EXE fájlra rákattint, akkor nem a Spectre vagy a Meltdown kihasználásával lesz ellopva és eladva a Dark Web-en a WoW karaktere, hanem sokkal egyszerűbb módon (pl. rögzítve lesz egy keylogger-rel, netán ki lesz olvasva a játékból vagy a Chrome tárolt jelszavai közül sima SQL lekérdezéssel). Negyedrészt, egy WarezPistike bármikor vígan újratelepíti a gépét, hiszen úgyis mindent warez oldalról szedett. Ötödrészt, igen, fontosabb pár FPS a GTA5-ben, mert ha ezt ígérte a gyártó, akkor ne utólag vegye el az FPS-eket, a saját hibájából adódóan. Ahogy természetesen, nem csak az FPS fontos, hanem minden mérőszám, ami performance.

Tekintettel arra, hogy a hivatásos rettegésre és a tech-lakájmédia hisztériakeltésének sajátvéleményként való előadására kényszert érző fősodratú mérnök urak hozzászólásai így is felülreprezentáltak ebben a topikban, nem gondolom azt, vagyishát szépen szólva nettó baromság, hogy pont ez a topik jelentené akadályát annak, hogy valaki megfelelően tájékozódjék a sebezhetőségek jelentette kockázatokról. Akinek van egy kis józan esze, az ezt be is látja, mielőtt billentyűzetet ragad és hozzászól.

Kicsit mást értünk valódi, rosszindulatú kihasználás alatt, de annyi baj legyen. Azért köszönöm, hogy igyekeztél komolyan venni a linkre vonatkozó kérésem.

Ettől azonban még sajnos nem fogok rettegni. Ennek egyik oka az, hogy Windows XP alatt, napi szinten Internetezve, víruskeresőt nem használva, eddig túléltem az összes nagy kártevőhadjáratot és zsarolóvírus-támadást. Ha pedig "nem éltem volna túl", se lett volna nagy megerőltetés visszaállítani a backup-ot, tekintve, hogy amennyi időt igénybe vett volna, annyit birkáék is eltöltenek a Media Markt-ban új laptop-nézegetéssel.

A másik ok, ami viszont már nem ennyire szubjektív az az, hogy a malware samples annyit jelent, hogy gyanúsnak feltételezett, útközben elkapott, tehát támadást meg nem valósított kódokat töltöttek fel a víruskeresők automatikusan, vagy a felhasználók manuálisan (pl. VirusTotal). Ez egyáltalán nem bizonyítja azt, hogy ezek a kártevők akkora mértékben támadnak és pusztítanak, mint amekkora FUD kampány söpör végig a tech-lakájmédiában. Sőt, egyáltalán nem bizonyít semmit arra vonatkozóan, hogy ezek a kártevők sikeres támadásokat (pl. egy jelszólopást, vagy egyéb érzékeny adatok olvasgatását, mivel másra úgyse nagyon lehet használni) hajtottak volna végre.

Szeretnék látni egy botnetet, ami erre épül és van benne mondjuk legalább százezer PC, és akkor még keveset mondtam. Szeretnék látni egy pastebin dump-ot jelszavakról, amiket ily módon szereztek meg. Amíg nincs ilyen, addig üres hablatyolás és szenzációhajhász félelemkeltés a frissítési idealizmus erőltetése. Tekintve, hogy, hogy az ismert, web-ről bepofátlankodni kívánó malware-eket még az én nem támogatott, nem frissített Windows XP-men is kiszűri egy uBlock Origin (de ha az nem és nagyon félek, akkor egy MalwareBytes, ami a fősodorral ellentétben, még támogatott XP-n).

De, meg lehet. Idealista, kényelemhajhász WiFi helyett használsz normális, kábeles Internetet.

Alternatíva lehet, ha trey implementál egyedi azonosítót minden hozzászólás post form-jába, így a rendszer nem engedi be kétszer ugyanazt. Bár, ahogy elnézem, most is van egy hasonló. 


<input type="hidden" name="form_token" id="edit-form-token" ... >

Csak valószínű, nem erre van használva.

Elméletileg lehetséges az, hogy a Wifi-n egy keep-alive HTTP-n kimegy a POST, utána elveszik a visszajövő ACK, így a kapcsolat timeout-ol. Ekkor pedig az idealista Chrome bontja a keep-alive kapcsolatot (timeout) és nyit egy újat, amin újraküldi, hogy mégse törjön le a kényelmeskedő felhasználó ujja +1 kattintástól. A timeout helyett lehet egy network change is, amikor a Wifi-n kimegy a csomag, de az ACK már nem jön vissza, így egy másik network-ön (mobilneten, kábelen, másik wifi-n) kimegy még egyszer a POST automatikusan. Szerintem kizárólag az alkalmazásréteg felel az ilyenekért, mert egyedül csak ott elfogadott, hogy a fősodor alapdolgokat is összegányoló implementációkkal hozakodik elő.

Saját tapasztalat: nekem számtalanszor volt dupla, főként szarakodós, lassú Wifi-n.

Akkor az a böngésző objektíven szar és nem ismeri a HTTP protokollt:

This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see section 9.1.2). Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s).

(https://tools.ietf.org/html/rfc2616#section-8.1.4 - Kiemelés tőlem)

A POST expliciten non-idempotent.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem feltétlenül cél, hogy ismerje a HTTP protokollt. Az elsődleges cél, hogy birkáék használják és ebből a Google-nek profitja legyen. Akár abból, hogy a Chrome felhasználók automatikusan Google szolgáltatások felé kacsintgatnak. Akár abból, hogy a Google az alapértelmezett kereső a Chrome-ban és a fizetett hirdetések után dől a lé. Akár abból, hogy a Google az alapértelmezett kereső a Firefox-ban és a fizetett hirdetések után dől a lé.

Mellesleg, Wifi-n azért is szar a Chrome, mert valamilyen szélsőséges idealizmus folytán nagyon szereti újrahasznosítgatni a nyitva lévő keep-alive kapcsolatokat és csomagvesztésnél sokszor rengeteg időbe telik, míg timeout-ol és hajlandó nyitni egy újat, avagy betölti az oldalt. Ilyenkor hiába nyitsz új tab-ot, ott is újra akarja hasznosítani a már meglévőt, míg egy olyan oldal, ami felé nincs aktív keep-alive kapcsolat, azonnal bejön. Ekkor szoktam kézzel a chrome://net-internals/#sockets alatt a Close idle sockets és Flush socket pools gombokat nyomogatni. Az is segít, és gyorsabb is, ha nyitok egy inkognitót, mert az független socket pool-t használ.

Na, látod, most meg vagy dicsérve. Valaminek normálisan utánanéztél, nem patika magazinos bulvárcikkeknek dőltél be. A gyakorlat is alátámasztja, számtalanszor volt már Chrome-ban és FF-ban is, hogy csak egyetlen egyszer nyomtam a elküldés gombra, de az adott weboldalon 2-3× posztolódott, amit írtam. Az esetekben csak az volt a közös, hogy lassan ment el, amit küldtem, POST-tal küldődött minden esetben.

Amúgy milyen érzés, hogy te is fősodratú, tények által összezavart mérnökúrrá avanzsáltál elő? :D Vagy ha nem is, de legalább jó úton haladsz afelé.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

http://a.te.ervelesi.hibad.hu/hamis-okozat

Attól még, hogy te is tapasztalsz valamit, amit én is tapasztalok és ennek az okait ugyanabban látjuk, nem lesz egyikünk se fősodratú.

Fősodratúak azok az idealisták, akik a Chrome-ba és a Firefox-ba szabványszegő POST implementációkat írtak, a kényelmeskedés és a felhasználói élmény™ biztosításának érdekében (amihez mondjuk jobb lenne inkább a bloat kódbázist optimalizálni, a HTML-t és a JS-t elfelejteni és átállni bináris szabványokra, API-kra).

Azért én kíváncsi lennék egy megbízható tudással rendelkező egyén véleményére is. Ugyanis a hup nálam is szokott akadozni, de ennek semmi köze a wifihez, sem a saját hálózatomhoz, ugyanis másik fülön, másik oldal, gond nélkül megy olyankor is.
És nálam az egyetlen duplikáció ilyenkor történt, jó eséllyel duplán "kattintott" Beküldés miatt.

Annak ellenére, hogy spam-nek nevezed a linkelt oldalt, mivel már annyiszor láttad, úgy tűnik, egyetlen alkalommal se sikerült értő olvasással elolvasnod. A köznyelvben értelmezett személyeskedés nem ugyanazt jelenti, mint a személyeskedés érvelési hibája.

kíváncsi lennék egy megbízható tudással rendelkező egyén véleményére is

Ergo, utaltál arra, hogy én nem vagyok megbízható tudással rendelkező, ezért esetleg nem úgy van, ahogy mondom. Ezzel kimerítetted az alábbi definíciót.

"Egy álláspont vagy egy állítás helyességét a kijelentő személye, vélt vagy valós személyiségjegyei vagy feltételezett érdekei alapján próbáltad meg kétségbe vonni."

Ironikus, hogy ezek után pont te butázol, ostobázol és parasztozol.

Mivel a gazdája/készítője ismeretében blokkolva van, akkor sem olvasnám el, ha érdekelne a tartalma. A személyeskedés mást jelent, mint amit te próbálsz ráerőszakolni. De mivel ennyire erőszakosan hirdeted azt az oldalt, megkockáztatom, hogy a tiéd, kevésbé rossz esetben a tulaj vérrokona vagy. :D

blokkolva van

Nem szégyen, ha blokkolva van, én is blokkolom pl. az összes reklámot, minden oldalról, kivétel nélkül, mert nem óhajtom vadkapitalistáék manipuláció-hadjáratát és marketing-bullshit gyűjteményét látni. Azonban, ha a tartalmát se ismered és nem is olvastad, akkor ne vonj le következtetéseket belőle és ne nevezd ráerőszakolásnak azt a definíciót, amit szimplán lusta voltál elolvasni és értelmezni.

mivel ennyire erőszakosan hirdeted azt az oldalt, megkockáztatom, hogy a tiéd, kevésbé rossz esetben a tulaj vérrokona vagy.

Ki kéne bújj a fősodratú, szélsőségesen érdekközpontú gondolatvilágodból és akkor nem csak ilyen közhelyes konklúziókra futná.

kíváncsi lennék egy megbízható tudással rendelkező egyén véleményére is

Ergo, utaltál arra, hogy én nem vagyok megbízható tudással rendelkező, ezért esetleg nem úgy van, ahogy mondom.

Írtál egy elméleti lehetőséget, amire válaszul kaptál egy RFC-t, ami kifejezetten megtiltja az elméleti lehetőségként vázolt esetet. Amire válaszul elkezdtél anekdotázni, hogy nálad márpedig így van.

Egyébként triviálisan tudnád bizonyítani az igazad: nézz bele a Chromium kódjába, keresd meg a vonatkozó részt, aztán linkeld be. És akkor elismerjük, hogy igazad van, és még akár a bug reportodhoz (mert ez egy bug, mert itt csak duplikálódik egy hozzászólás, egy rosszul megtervezett banki felületen [láttunk már ilyet, na...] egy-egy tranzakció duplikálódik, ott már van anyagi kár is...) is hozzá szólunk, hogy a sok hozzászólás miatt a fejlesztők is foglalkozzanak vele.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"Azért én kíváncsi lennék egy megbízható tudással rendelkező egyén véleményére is. "

Nem vagyok az, de azért elmondok egy történetet.

Egy webalkalmazáson dolgoztam, amiben egy bizonyos gombra kattintva előjött egy dialógusablak. Kaptam a megrendelőtől egy visszajelzést, miszerint a funkció elromlott, nem jelenik meg az ablak, csak felvillan. A hibakeresés oda vezetett, hogy a gombbal nincs semmi baj, egyszerűen duplán kattintgat a kedves megrendelő, amivel előhozza, és el is tünteti az adott ablakot azonnal. Na persze nem szándékosan kattintott duplán, az egere ment gallyra.

Természetes, hogy az első reakció az volt, hogy biztos én rontottam el, ne nézzem hülyének, különben is, neki az egere tökéletes, hiszen drága gémer egér (vagy mi). A megoldás az lett, hogy egy időzítővel garantáltam a dupla kattintások elnyelését.

Pár hét múlva szól a megrendelő, hogy tényleg rossz volt az egere.

***

Namost, ezzel nem azt akarom mondani, hogy akárhányszor duplán jelenik meg egy komment itt, az egérhiba miatt. Messze nem. Én is küldtem már be kommentet duplán olyan triviális körülmények közt, hogy például szimplán beremegett az ujjam, és akaratlanul duplán kattintottam, vagy azt hittem hogy elsőre mellékattintottam, holott mégsem.

Az pedig, hogy a Chrome konkrétan hogy kezeli a POST beküldését nem vita tárgya. Mármint. Jöhetnék én olyannal, hogy "szerintem", meg hogy "nem hinném hogy". De minek jöjjek, amikor le is tesztelhetem az adott jelenséget? Konkrétan mérhető a működés, de akár a Chromium forráskódjában vizsgálható is volna.

Nos, ehelyett idő híján csak egy buta tesztet csináltam, egy scripttel, ami 10 mp alatt fut le. Egyszer futott le, a Chrome észrevette, hogy megszakadt a kapcsolat, és utána nem akarta automatikusan újra beküldeni. Ennyike.

Igazából nem semmi, megjelenik a böngészőben a csík, ami mutatja, hogy elkezd tölteni (Chrome-ban legalább is). Ha nem, akkor az a böngésző tényleg gáz.

Arról vitázhatnánk, hogy a böngésző(k) van(nak) rosszul tervezve, hogy enged(nek) request elindítása után interakciót (másodszori beküldést, vagy akármi mást), vagy a weboldalaktól jogos elvárás lekezelni ezeket az eseteket. Mindenesetre annak ellenére, hogy a dolgok így működnek, nagyon kevés helyen van tényleg lekezelve, itt a hup-on sincs, pedig az az egy sor JS-t bepakolni igazán nem volna nagy dolog...

Nálam pl. hiába az az egy sor JS, mert a noscript mindet megfogja. ;)
Azért ha lenne publikusan elérhető homokozója a hupnak, eljátszanék azzal, hogy döglődő hálózaton mit művel egy-egy böngésző. Esélyt adva rá, hogy a gyakorlat más, mint az elmélet.

"Hm? NoScript elég jól paraméterezhető, hogy ne okozzon gondot az ilyesmi ;)"

Igen, csakhogy te ezt mondtad:

"Nálam pl. hiába az az egy sor JS, mert a noscript mindet megfogja. ;)"

A kettő üti egymást. Vagy mindent fog, vagy ha jól paraméterezed, akkor nincs gond.

Más kérdés, hogy vannak gyártók és bizonyos rendszerek, amik sosem lesznek peccselve, mivel nincs rá szükség. Ilyen pl. a NetApp Storage, nevezhetjük akár beágyazott rendszernek is, mivel nem futnak kliens joggal alkalmazások, így a sebezhetőség kihasználásának az esélye kb. a nullával egyenlő.

--
robyboy

( tgerczei | 2018. 02. 05., h – 19:50 )

'sudo vi' sudoedit
------------------------
{0} ok boto
boto ?

( hajbazer v | 2018. 03. 25., v – 16:48 )

Frissültek a Windows-ok és a BSD-k. Sajnos, OpenBSD-ről máig nem találtam értelmes infót, hogyan lehetne kikapcsolni a javításokat. Ha valakinek van működő megoldása, írja meg!

Na, fene, BSD-zel. Nem bloat az neked? :D

Linuxon egész jó a helyzet Retpoline + user point sanitization-nel. Aztán megjött a kernelbe az IBPB meg az Intel is kiadta végre újra a mikrokódcsomagot (így a 2. gen. Core i procim is használja, a kernelkimenetből ítélve sikerrel frissül rajta a mikrokód bootkor), azzal viszont nálam is érezhetően belassult, nem mértem pontos számokat, de érezhető volt a lassulás. A vicc, az, hogy meg egyet frissült a kernel, 4.15.11-től kezdve bekerült a IBRS_FW védekezés is, és ezzel nem lassít, újra engedélyeztem, és nem érzek különbséget a javítások nélküli, retpoline-os, és IBRS-ses állapot között. Bár lehet valami trükk van, és hiába nincs letiltva, nem használja a mikrokódos védekezést. Ha lesz BSD-re retpoline és user point sanitization, azokat nyugodtan bekapcsolhatod, nem lassítanak, a phoronixos tesztek is csak 1-2%-os sebességcsökkentést mutatnak PTI-vel együtt, annyi meg nálad sem lesz tétel.

Egyébként meg Windowsnál nem elég a Winnek frissülni, kell hozzá mikrokód is, ami BIOS formájában heggeszthető csak jelenleg úgy fel, hogy a javítás tudja használni. Mert amúgy betölthető az új mikorkód valami VMware-es cuccal is, de a PH-n kikísérletezte valaki, hogy túl későn tölti be, a kernel még valami korai szakban vizsgálja a mikrokód fentlétét, de akkor még nem áll rendelkezésre, ezért nem tölti be hozzá a javításokat. Bár erre is ígértek patcht, hogy frissíteni lehessen új BIOS nélkül is mikrokódot Windows alatt.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Igen, mert az éljen az XP, meg az az anti bloatware és kapitalista fejlődést erőltető multi fősodratú mérnökurazás nem unalmas egyáltalán. De azt írd már, hogy a BSD-vel mire jutottál, nagyon kíváncsi vagyok.

Vagy ha kedved van, akkor az ATi X1250-es driverre is visszatérhetünk Linux alatt, amint felraktál rá egy Archot, ami alapból a kernelbe épített modesetting drivert használja, amihez csak egy Mesa-t kell feltegyél, hogy hogyan alakultak a prociterhelések.

Egyébként meg arra számíthatsz, hogy egy csomó helyen írok erről a Meltdown/Specre dologról, mert sok róla a tévhit, hiába van ezeknek külön oldal dedikálva, lófasz infó van rajta, de legalább az MS is kiadott már rá egy rakat frissítést, amit kiadott, majd visszavont, akkor az Intel is balfaszkodott, most megint kiadták a mikrokódcsomagot, de egyes procikra, amelyekre ígérték mégse adnak ki, de még BIOS sem lesz minden laphoz, de az MS már dolgozik egy mikrokódot telepítő frissítések, de az még nem érkezett meg csak Skylake-hez, de még mindig vitatott, hogy a Spectre2 kihasználható-e AMD procikon. Főleg Windowson max. káosz van ezügyben, de még mindig sok gép nincs foltozva, meg ezt a 30%-os teljesítményvesztéses mantra is nagyon tartja magát. Szóval addig ja, rácsesztél, mert ha bullshitet észlelek, fosni fogom rá a litániákat. Kifogyhatatlan téma, csomó védekezési módszer van rá. Már csak a sebezhetőséget és annak foltozását detektáló programokról lehetne litániákat írni.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

( hajbazer v | 2018. 08. 15., sze – 19:02 )

Frissült a Linux szekció, a Spectre V2 és V4 (Store Bypass) javítások kikapcsolásával.

Egyúttal, hamarosan várható még egy frissítés, ugyanis multiék továbbra is, még jobban belassítanák a processzorokat, csakhogy mindenki újat vegyen, amiben már ki van javítva minden (ja nem... üdv. Skylake).

Istenem, milyen jó ilyenkor hátradőlni egy 10 éves gépen futó Windows XP-vel és jót röhögni azon, ahogy a fejlődésmániás, megélhetési tech-majmok kapkodnak össze-vissza.

Valamilyen szinten ebben kezdek veled egyetérteni. Mármint nem a frissítések és patchek fel nem tételében, meg az XP éltetésében, hanem úgy értve, hogy elkezdtem én is hanyagolni ezeket a procis sérülékenységeket, hanem lesz@rom most már. Egyre több CPU security bugot találnak meg, gomba módra szaporodnak, egyre inkább nem tudnak lépést tartani a foltozással, ergo mindenki sérülékeny, értelmetlen bármi ellenállás.

Pont pár napja publikáltak még 3 sérülékenységet, foreshadow, meg stb., jönnek ezek csőstül a jövőben, és mindenki védtelen lesz, mindegy hogy a Spectre Chapter n+1 folt fent van-e neki, mert a hajára kenheti. Még az sincs, hogy veszel olyan procit, ami ezekben nem érintett, mert általában mind az. AMD-k egyelőre kevésbé, de majd a jövőben azokban is egyre növekvő ütemben fedezik fel a jóságokat. Ezt most mindenki megszívja, nincs mit rajta szépíteni.

Még azt sem mondanám, hogy elég letiltani a spektulatív meg out-of-order végrehajtást, mert pl. az SMT-t is támadják már, meg minden fajta cache felhasználást, és akkor ennyi erővel az összes procicache-t is tiltsuk le, és visszasüllyedünk a végére a DOS korszakbeli, egy szálas 80386-os sebességére. Itt valamit a procigyártóknak kell majd lépnie, valami nagyon gyökereset, hogy ennek a dominóhatásnak az elejét vegyük egyszer és mindenkorra. Valami teljesen más tervezési koncepciót, egy vadi új architektúrát kell ez ellen kitalálni.

No keyboard detected... Press F1 to run the SETUP

Na, ez dícséretes. Végül pedig eljutsz majd oda, hogy megérted: az emberi tényező még mindig az, amelyik egyszerre tud lenni a legerősebb és a leggyengébb láncszem a képletben. Leggyengébb, ha csak digitális fogyasztó ösztönlényként tapicskol és kattintgat. Legerősebb, ha tudatosan, intelligens módon internetezik és tisztában van azzal, hogy nincs biztonságban. Ekkor a viselkedésével fogja kompenzálni ezt a tényt, csak a feltétlenül szükséges oldalakat látogatja és azokat is megfelelő elővigyázatossággal (uBlock, ScriptBlock, NoScript stb.).

Nem azzal van baj, hogy a processzor sebezhető. Azzal van, hogy támadó kódot futtatsz rajta. Ha nem futtatsz rajta kártékony kódot, nem kell semmiféle javítás. Alapvetően az internetezés koncepciója az, ami rendkívül szarul lett megtervezve, illetve nem is lett, csak alakult a sok pénzéhes, marketing-idealista csilimániás web-"fejlesztő" ökörködése mentén. Az internetes szolgáltatásokat üzemeltetőknek elég volna egy API-t biztosítaniuk, és azt valaki használhatná egy akármilyen jól kifaszázott biztonságú programmal. Számomra nonszensz, hogy egy weboldal kódot futtasson a gépemen, mert csak így hajlandó normálisan működni. Ez egy orbitálisan elhibázott koncepció. Adatokat kellene csak engedni ide-oda, hiszen a mai modern web-es cloud-idealizmusok is végső soron API-n kommunikálnak, csak előbb le kell töltődnie hozzá a javascript-bloat-nak. Helyette lehetnének asztali kliensek, amikhez nem kéne böngésző, és csak adatokkal kommunikálnának. Tehát máris nem kéne félni az ilyen Spectre hülyeségektől, hogy majd javascript-ből kiolvassa a memóriát, csak akkor ha szánt szándékkal indítja el Tapicskoló Tamás a spectre.exe-t a gépén. De akkor persze már ő a gyenge láncsszem, és meg is érdemli, hogy szanaszét legyen hekkelve, mintsem a frissítés adta biztonság illúziójában kényelmeskedhessék.

Korábbi vitáink margójára megjegyezném: Tisztában vagyok vele, hogy soha nem jön el az az idő, hogy áttérsz a jó öreg XP-re. Viszont, legalább végre kezded kapiskálni, hogyan jutottam arra a véleményre és gondolkodásmódra, ami miatt megtartottam az XP-t. Ennek valahol örülök. Egyébként, láss csodát, a mai napig probléma nélkül muzsikál az XP-m.

Oszt a natív program nem számodra ismeretlen kód, ami ugyanúgy lefut ugyanazon a processzoron? Cserébe legalább azonnal kaphatsz natív kódot, úgyhogy még különösebben játszani sem kell a JS engine működésének a megfejtésével...

Logikai bukfenc: jajúristen, mindenféle jött-ment kódot futtathat a gépemen, arra az a megoldás, hogy letöltöm a mindenféle jöttment kódját és majd futtatom én. Uh...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Marhára nem fogtad fel a lényeget, de ami még szembetűnőbb, hogy nem is erőltetted meg magad.

Lényeg összefoglalva: Van egy API-d instant messzendzselésre, videónézésre, és e-mail-ezésre. Ezeket hívhatjuk protokolloknak is. Mondjuk XMPP, RTSP, IMAP/SMTP. De legyenek csak API-k, akár JSON alapon. Ezekhez olyan (akár open-source) programot ír bárki, amilyet akar. SzBlökinek extra biztonságos™, naponta frissített™, garantáltan kártevőmentesített™, ajándék víruskereső-licenccel. Az API-kban (vagy a protokollokban) kéne csak megállapodni. Miért ne lehetne egy IMAP-hoz hasonló protokoll internetes vásárlásra? Máris el lehetne felejteni a csilibloat 90%-át, és hogy minden webáruház másképp néz ki, meg igyekszik vásárlásra manipulálni az arra látogatót. Elég lenne adatokat csereberélni az egyes kliensek és szerverek között. Nem kéne a webfejlesztők által összemajomkodott kódokat futtatni senki gépén.

mindenféle jött-ment kódot futtathat a gépemen, arra az a megoldás, hogy letöltöm a mindenféle jöttment kódját és majd futtatom én.

Ja, mert jobb a biztonság illúziójában ringatott felhasználó böngészőjén minden jöttment kódot lefuttatni, mintsem ha egyáltalán nem kell távoli kódot futtatni, hanem a megbízható API kliensed kommunikál a szerverrel.

XMPP, RTSP, IMAP/SMTP

Van ezekkel egy szintű protokoll, amibe mindent be tudsz ágyazni: HTTP. A három felsorolt protokoll egészen fix adatmodellel dolgozik (még az XMPP a kivétel, ott a különböző XEPekkel változik folyamatosan az adatmodell - csak aztán sok sikert a minden szükségesnek ítélt kiterjesztést támogató szerver és kliens kereséséhez...), a vásárlásos példádnál maradva a protokoll semmit nem mond arról (mert nem az a dolga), hogy a "Csá, kéne tizenötezet műanyag basz. Köszi, B." szövegű leveled akkor legyen vásárlás.

Miért ne lehetne egy IMAP-hoz hasonló protokoll internetes vásárlásra?

Tessék, ülj le és csináld meg. Vagy csak kezdj el egy specifikációt összerakni. Felőlem mehet HTTP transporton JSON-nal. Sok sikert hozzá. Kb. pár másodperc gondolkodás után rájössz, hogy egész más adatmodell kell egy consumer to consumer (ebay), egy business to consumer (amazon, aliexpress, ebay) és egy business to business (alibaba) vásárláshoz. Az első kettőhöz illik online (értsd: azonnali, tranzakción belüli) fizetést csinálni, a harmadiknál a legtöbb cég kiröhögne, ha a "úúú és kártyával kelljen fizetni" tétel megjelenik a követelményeid között. Aztán persze a termékleírásoknak valamilyen strukturált formában kellene közlekedniük, különben ott tartunk, hogy az egyik mark-up nyelvet lecseréltük egy másikra és van egy nagy adathalmazod, amiben kb. fulltext tudsz csak értelmesen keresni (ez még az ebay-nek sem igazán megy, nézd meg időnként a bal oldali sávban a szűrési lehetőségeket). Aztán persze jönnek a különböző payment processorok (PayPal), mert Hajbazer (tm) natív kliens mániája miatt nem fogom minden jött-ment site-nak megadni a bankkártya adataimat, továbbra is szeretném csak a PayPalnál tárolni azokat (whoops, még egy API, amit az elfogadók [Paypal, google pay, apple pay, lófasz pay] torkán le kell nyomnod és a kliensben implementálnod, adatmodellel mindennel, vissza az asztalhoz specifikálni). Aztán persze ha nem valami létező, TLS-t támogató transport protokollt használsz (pl. HTTPS), akkor kezdhetsz agyalni a titkosított átvitelen, még HTTPS esetén is gondolkodhatsz az authentikáción is stb.

Persze, le lehet ülni, lehet csinálni tök jó protokollokat az auth-tól kezdve a shipping providereken (én pl. nem szeretem, amikor az eladó tudja a címem, jobb lenne, ha azt egyedül a szállító cég kapná meg, ők csak adjanak egy azonosítót, amit a feladó ráragaszt a dobozra, mielőtt átveszi tőlük a szállító, majd utólag ráteszik a címet, ha másik szállítóhoz kerül [pl. dán posta átadja a magyar postának, de egy DHL "házon belül" megoldja])... azon túl, hogy soha nem végeznél vele, mert mindig lenne olyan use case, amire még alkalmatlan a megoldásod, több verzió kellene a protokollból (az IMAP is már a 4.-nél tart és a mai napig hozzá kell piszkálni időnként (egyébként ha már mail access és protokoll: az Exchange ActiveSync protokoll elkövette ugyanezt a hibát, nagyon részletes adatmodellt definiált... és a tizenhatodik verziónál jár, pont a fentiek miatt: megváltozott követelmények, folyamatosan változó adatmodell és úgy általában a kliensek képességeihez igazítják időnként [20 éve a mobileszközök kicsit más képességgekkel rendelkeztek és máshogy nézett ki az e-mail is...]).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ha megfigyelted, most is HTTP-JSON alapon működnek a webes szolgáltatások API-jai. Elenyésző esetben XML. Ezeket kéne egységesíteni. A protokollokat csak azért hoztam fel példának, mert azokat is lehetett egységesíteni, bármennyire is más az igénye pl. a levelezésben egy enterprise környezetben dolgozónak, vagy egy otthoni felhasználónak. Le van bennük specifikálva, hogyan küldhetsz adatot és milyen adatokat küldhetsz. Ezt tekintheted egyszerű adatmodellnek is. De maradjunk a HTTP-JSON API-nál. Érdekes módon, mikor a Web 2.0 éledezni kezdett, nagyon sokan kezdtek egységesített, plugin-okkal bővíthető, központilag fejlesztett tartalomkezelőket használni. Olyanokat, mint Wordpress, Drupal, Joomla. Mert lusták voltak nulláról írni egy sajátot. Valahonnan innen kéne megfogni top-down logikával a dolgot, nem az adatmodelleken erőlködni.

Legyen egy cég, de inkább egy közösségi szervezet (vagy alapítvány), amely specifikálja és elkészíti ezeket az API-kat, aztán, amennyire csak lehet, egységesíti. Ezekhez az open-source közösség, akár nagyvállalati támogatással készít API klienseket, amik csak a célnak megfelelő dolgokat tudnak. Később ezeket átveheti az Amazon, az eBay, de akár a Facebook és a YouTube is. Ők mentesültek a saját bloated weblap és bloated kliens (Messenger for Android, iOS stb.) karbantartásától, cserébe kevesebb marketing-idealizmust vihetnek bele, de legalább a felhasználók is mentesültek a bloattól. Egyébiránt, áruld el nekem, hogyan lehetséges az, hogy egy okostelefonos Messenger applikáció 200 MB diszket foglal és az akksi legalább harmadát viszi úgy, hogy csak üzenetküldésre alkalmas. Mindeközben, a Facebook Lite 2 MB-on (század annyi helyen!) elfér, a Facebook minden (nem csak üzenetküldő) funkcióját hozza (néhányat csilibloat nélkül), és alig fogyaszt valamit az akksiból. Ja hogy úgy, hogy van kellő számú afrikai és közép-ázsiai, akit Facebook-függővé akarnak tenni, de rájöttek, hogy ők nem engedhetik meg maguknak a 2 évente új okostelefon megvásárlását. Ígyhát elkülönítettek egy csapatot a fejlesztésre, és láss csodát, töredék erőforrással is megoldhatóak ugyanazok a problémák. Na, ez a szemléletváltás kéne történjen az informatikában (és vele együtt a webvilágban) is.

Ennek ellenére te inkább egy pazarló, fenntarthatatlan, koncepcionálisan túltervezett és az egyes rétegeket, komponenseket egymásra tákoló-hákoló megoldást éltetsz, olyan megoldható mérnöki problémákra hivatkozva, melyekbe a hozzád hasonló fősodratúak lusták voltak beleásni magukat. Ezért inkább 3 évente vetetünk új gépet mindenkivel, aki konstans gyors böngészést akar, meg megemeljük az internet-sávszélességét, mikor végső soron csak szöveges és képi adatot kell cserélnünk. A szerinted legjobb megoldás erre az, hogy gyakorlatilag 100x-1000x-es overheaddel (leöltődő JS bloat, marketing-ideliasta design elemek, háttérképek, háttérvideók stb.) csinálja meg mindenki a maga bloated kliensét, végső soron ezzel a végfelhasználót szivatva, akinek előbb-utóbb úgyis be fog minden lassulni a böngészőjében. Persze, ha ennyire ellene vagy a natív API klienseknek, említhettem volna a minimalista static HTML felületeket is, amiket akár egy Pentium 3-asról is kényelmesen (értsd: gyorsan) használni lehetne. Tudod, amilyen a Gmailnek is van. Valamilyen megoldás kellene arra, hogy ne kelljen mindenkinek a legújabb szoftvereket (és ezáltal, néhány éves késéssel hardvereket) használnia ahhoz, hogy adat csere-berét folytasson, amit akár egy 386-osról is meg lehet csinálni. Ehhez persze le kéne ülni és újratervezni azt, amit ma webnek nevezünk. Leülni és gondolkodni pedig nem számít sikeres patternnek a szélsőségesen idealista, vadkapitalista világfelfogású, velejéig arrogáns cloud-multiknak, és mivel a hozzád hasonló tech-majmok valahogy mindig őket követik, így a webfejlesztő IT-csicskaréteg is marad a seggén, és nem tesz semmit. Jó lesz az úgy is, hogy kidobálja mindenki a számítógépét, okostelefonját és vesz helyette újat. Jó lesz, mert termelődik a GDP.

pl. a levelezésben egy enterprise környezetben dolgozónak, vagy egy otthoni felhasználónak.

És nézd meg, más protokollt használ (EWS, EAS, MAPI vs IMAP, POP3, SMTP, WebDAV/CalDAV/CardDAV - csak hogy egységes legyen).

Le van bennük specifikálva, hogyan küldhetsz adatot és milyen adatokat küldhetsz.

Valóban, le. Bármilyen szöveget, vagy bináris dolgot megfelelően (pl. base64) enkódolva. Attól ez még nem lesz egy API-nak használható valami.

Olyanokat, mint Wordpress, Drupal, Joomla.

Olyanokat, amik gyakorlatilag BLOB-ként kezelnek egy markup nyelvvel leírt tartalmat. Ami nem feltétlenül jó megoldás, ha strukturált adatokra van szükséged.

Legyen egy cég, de inkább egy közösségi szervezet (vagy alapítvány), amely specifikálja és elkészíti ezeket az API-kat,

Azért, mert?

aztán, amennyire csak lehet, egységesíti.

Tervezünk egy API-t és utána gondolunk bele, hogy lehet, hogy más is kellett volna bele az egységesítéshez?

Ezekhez az open-source közösség, akár nagyvállalati támogatással készít API klienseket,

Azért, mert? Kik lesznek hozzá az API kiszolgálók?

Később ezeket átveheti az Amazon, az eBay, de akár a Facebook és a YouTube is.

Akiknek ez azért érné meg, mert?

Ők mentesültek a saját bloated weblap és bloated kliens (Messenger for Android, iOS stb.) karbantartásától, cserébe kevesebb marketing-idealizmust vihetnek bele,

Tehát az egyébként a meglévő rendszereiket súúúlyos pénzekért cseréljék le azért, hogy megszűnjön az, ami megkülönbözteti őket a konkurenciától? És az eddigi fejlesztési költségeiket cseréljék le support költségre, ahol minden jöttment random kliensét támogatni kell?

De továbbra is: csak egy (akármennyire minimális) funkcióra csak 10 percig gondolkozz el, hogy hogyan kéne megtervezni AZ apit. Pl. csak az IM-re. És akkor majd jönnek az igények, hogy szép és jó a protokoll, amit feltaláltál, de kellene bele group chat, end-to-end titkosítás, voice/videó hívás, protokoll-szintű támogatás arra, hogy tudd elosztani a terhelést, valamiféle federációs megoldás, spammelés elleni védelem, kézbesítési/olvasási értesítés, ... És ez csak az, ami fejből eszembe jutott; ha tényleg leülsz egy olyan protokollt megalkotni, amit szeretnél is, hogy használjanak, kénytelen vagy a most létező _összes_ átalakítandó rendszer _összes_ funkcióját belevenni vagy legalábbis a későbbi implementációt elérhetővé tenni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

És nézd meg, más protokollt használ (EWS, EAS, MAPI vs IMAP, POP3, SMTP, WebDAV/CalDAV/CardDAV - csak hogy egységes legyen).

Ami még mindig messze nem annyi, mint ahány webshop létezik, saját felülettel.

Azért, mert? Kik lesznek hozzá az API kiszolgálók?

Azért, mert előbb-utóbb felveti a világot az elektronikus hulladék, ami kifogástalanul működő eszközökből keletkezett. Egyébként, meg azért, mert sok esetben most is így megy. Valaki előre megírt valamit. Például egy operációs rendszert. Azt pedig a cloud szolgáltató szolgáltatja neked VPS-en. Hülye lennél VPS-t venni, ha nem lenne ott az OS. De ahhoz semmi köze a szolgáltatónak azonkívül, hogy működteti. Beszélhetnék SSH-ról, phpMyAdmin-ról is, vagy Webmin-ről, amiket szintén hivatalos hozzáférési felületként biztosítanak szolgáltatók. Mégse ők fejlesztették, egyiket sem. Miért ne lehetne egy, a közösség által fejlesztett szolgáltatást, protokollt és API-t foganatosítani, amire létezne ugyanúgy Windows XP-s kliens, mint legcsilibb Linux-os. Azt ne mondd, hogy képtelen vagy megérteni, hogy közösség által lefejlesztett API-k tudnának normálisan működni.

Olyanokat, amik gyakorlatilag BLOB-ként kezelnek egy markup nyelvvel leírt tartalmat. Ami nem feltétlenül jó megoldás, ha strukturált adatokra van szükséged.

Ahogy szintén nem jó elkészíteni egy, a kliens gépeken futó, interpretált nyelven (tehát eredeti céját tekintve ember által olvashatónak szánt) íródott kódot, hogy aztán leminimalizáld (tehát eredeti céljával ellenkezően, ember által olvashatatlanná tedd), később betömörítsd gzip-pel, majd leküldd a kliensnek, ahol ugyanezeket eljátszatod visszafelé. Mondhatni, az eredetileg hypertext transfer protocol-t is blob-nak használjuk. Aszinkron, AJAX hívások esetén pedig úgy abuse-oljuk, ahogy nem szégyelljük. Persze, nyilván nincs jobb világszintű megoldás a tákolmány hákolmányánál.

Akiknek ez azért érné meg, mert?

Mert nem csak és kizárólag a saját profitjuk hajhászásán jár az eszük, hanem odafigyelnek valamennyire az egyetemes hasznosságra és arra, hogy hosszú távon se basszanak ki a saját ügyfeleikkel, akiknek új gépet kell venniük, közel azonos funkcionalitás eléréséhez. Vagy mert már valaki megcsinálta helyettük, ingyen és bérmentve (ahogy most is a seggük alá tolják a Linux kernel-t, dollármilliós fejlesztéseket megspórolva nekik). Vagy mert szimplán egy haladóbb gondolkodású világban (ami még nem jött el) törvény kötelezi őket rá.

Tehát az egyébként a meglévő rendszereiket súúúlyos pénzekért cseréljék le azért, hogy megszűnjön az, ami megkülönbözteti őket a konkurenciától? És az eddigi fejlesztési költségeiket cseréljék le support költségre, ahol minden jöttment random kliensét támogatni kell?

A konkurenciától az különböztesse meg őket, hogy jobban, igazságosabban, etikusabban és korrektebben bánnak az ügyfeleikkel. Ne az, hogy több érzelmi manipulációs csilibloat-ot villantanak az ügyfelek képébe, vagy hatékonyabban nudge-olják (ravaszul csalogatják) bele őket olyan termékek megvásárlásába, amire eredetileg nem lett volna szükségük. Az eddigi fejlesztési költségek valahogy sose számítanak, amikor 2-3 évente megújítják (nulláról újraírják) a felületeiket cloud-multiék (mint most a Gmail), általában sokkal bloat-abb, undorítóbb, lebutítottabb felületűre. A régit meg szépen kidobják. Szóval, én nem sajnálnám a fejlesztési költségeket. Pláne, hogy sokkal nagyobbra rúg annak a többszázmillió felhasználóknak a pluszköltsége, akik cloud-multiék elbloatosítási gyakorlatai miatt kénytelenek 3-4 évente új gépet/okostelefont venni, amennyiben ugyanolyan gyors és reszponzív felhasználói élményt akarnak, mint annakelőtte.

Azt ne mondd, hogy képtelen vagy megérteni, hogy közösség által lefejlesztett API-k tudnának normálisan működni.

Tudnak normálisan működni, de továbbra is rossz rétegben jársz. Te arról beszélsz, hogy mondjuk az SMTP fölé húzzunk még egy protokollt (legyen mondjuk SoSMTP - Shop over SMTP), ami megadja, hogy a levél törzsébe milyen részek kerüljenek pontosan milyen tartalommal. Mint ahogy a HTTP felett ott volt mondjuk az RSS. Meg az RSS 2.0. Meg az Atom. Meg... mert változni fog azoknak az adatoknak a köre, amit bele akarnál tenni.

Mondhatni, az eredetileg hypertext transfer protocol-t is blob-nak használjuk

Igen, a protokollok nagy részét, vagy ha definiál is adatmodellt, az nagyon zárt (mert ha bárki bővítheti, akkor kapsz egy csomó egymással inkompatibilis rendszert...). Nézz meg pl. egy LDAP-ot, ott van a protokoll (ott van egy raklap protokoll, kiegészítés, ..., de ezt most hagyjuk). A _lényeget_ viszont a helyileg definiált séma adja (még ha van is néhány standard séma, azok egymással marhára nem kompatbilisek, az összes alkalmazás-specifikus séma [egy isc dhcp szervernek tök más osztályok kellennek egy ldap back-endre, mint amiket mondjuk az MS DHCP szerver használ...].

_EZT_ kellene neked valahogy egységesítened, akár csak egy-egy (rész)feladathoz, egy egymással versengő (így ellenérdekelt) cégekből álló piacon. Továbbra is, sok sikert.

Vagy mert már valaki megcsinálta helyettük, ingyen és bérmentve

Továbbra is: miért állna neki bárki kitalálni, hogy a piacon szereplő _összes_ szolgáltató most és a _jövőben_ mit és hogyan akarna csinálni (mert ebből kell levezetni a protokollt!), csak azért, mert _talán_ használná is valaki.

törvény kötelezi őket rá.

Na, ez lenne az egyetlen, amivel rá tudnád venni őket. Keress egy barátságos EU képviselőt, dobd be neki az ötletet, pár évig eljogászkodnak, aztán még az is lehet, hogy lesz belőle valami. Kíváncsi lennék arra a megbeszélésre, ahol mondjuk az Amazon, az Ebay és az Aliexpress fejlesztői próbálják összerakni A protokollt, ami egyiknek sem jár kompromisszummal...

Az eddigi fejlesztési költségek valahogy sose számítanak, amikor 2-3 évente megújítják (nulláról újraírják) a felületeiket cloud-multiék

Azért egy új front-end írni nem akkora meló, mint a teljes back-endet lecserélni és közben teljes architektúrát váltani és több évtizednyi know-howt és best practice-t kidobni...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nyilvánvalóan magasabb az IT műveltséged, hiszen nálam sokkal több rövidítést ismersz. ;)
(Erről a "Joel on Software" is megemlékezett.)
A sok okosság helyett nézzük az eredményt. Nyilvánvalóan egy bank napról napra fejlődik, és ezt újabb protokollok kitalálásával kell megoldani. Sőt, az a pénz, amit mobilappal utalsz át, az egy tök másik pénz, mint amit nem mobilappal utalsz. Tehát kell még néhány protokoll...
Már csak azért is, hogy kellően kielégítsd a felhasználók igényeit. Erre jó példa az OTP felülete. Készült egyszer egy olyan is, amikor a kávé+cigi nem volt elég utalásonként. :) Szerencsére - gondolom, a felhasználók nyomására - két napon belül visszavetették az oldalt a sötét középkorba. Így aztán használható maradt.

A blobosításban nem a blobosítás a probléma. Erre jó példa a soap, amikor egy alapvetően egyirányúnak szánt protokollba csomagoltak kétirányú rpc-t. Első talákozásom ezzel a szörnyűséggel úgy kezdődött, hogy egy hibaüzenet kiírásakor elakadtam. Rákerestem, és megtaláltam a megoldást: nincs megoldás. Legalábbis a problémán vitatkozó kőkemény soap guruk szerint. Az ok a két összecsócsált protokoll ellentmondása. Vajon miért nem használták rpc céljára az elég ősi rpc protokollt?

Mondhatni, a frontend és a backend is egyre szarabb lesz, amire újabb okosságok ráhúzása a helyesnek vélt javítási módszer. Csak néha nem jön be, viszont a számítógépek fejlődése egyes esetekben (de nem mindig) képes ellensúlyozni a naív próbálkozásokat.

Mindez persze nagyon jó, hiszen a káosz egyre több embernek ad munkát. Ez támogatja a népesség növekedését, hiszen a káosz növelésével egyre több utódnak lesz munkája. Nincs itt semmi hiba!

Nyilvánvalóan egy bank napról napra fejlődik, és ezt újabb protokollok kitalálásával kell megoldani. Sőt, az a pénz, amit mobilappal utalsz át, az egy tök másik pénz, mint amit nem mobilappal utalsz. Tehát kell még néhány protokoll...

Hajbazer meg azt mondja, hogy az OTP ne csinálhasson n+1 protokollt, hanem előtte üljön le világszinten _minden_ banki szereplővel (és persze az open source fejlesztői közösséggel, mert a klienseket ugyebár ők csinálják) és találjanak ki _egy_ darab protokollt, amivel mindenki kompatibilis lesz...

A blobosításban nem a blobosítás a probléma.

Ha kompatibilis implementációkat kell csinálni, akkor azért elég nagy probléma (vagy nagyon pontosan specifikálva van, hogy mi, hol és hogyan van abban a blobban, de akkor már nem hívnám blobnak, mert van egy jól definiált struktúrája).

Vajon miért nem használták rpc céljára az elég ősi rpc protokollt?

Lehet, hogy idióták, lehet, hogy csak ezt ismerik, lehet, hogy felültek a soap-hype vonatra, de lehet, hogy kellett nekik a transport protokoll nyújtotta néhány szolgáltatás (HTTP: titkosítás, kliens/szerver azonosítás, SOAP: önleírás, ...). Bármilyen feladatra lehet rossz eszközt választani, ez tény, ahogy egyébként jó eszközt is lehet rosszul használni. (egyébként melyik "ősi rpc protokollt", mert abból is van egy kisebb raklapnyi?)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egy kicsit félreértetted az iróniát. Igy aztán tudjuk kivel vagy! ;)
Már miért kéne ugyanahhoz a művelethez másik protokoll? A bankok meg világszinten elég jól együttműködnek. Egy multi meg kényszeríteni fogja az egyik országban működő megoldást a másik országra is - függetlenül attól, hogy rossz és drága. Megteheti, hiszen elég pénzt gombolnak le rólad. ;)

Az "ősi" a (sun)rpc. Csak egy héj, amit egy "helyi" specifikációval megtoldva nevezhetnén soap-nak.(Jólvanna! Pontosan tudom, hogy sok másból áll egy ilyen.) Inkább a rossz eszközválasztás az igaz. Aztán rögtön ott is terem 4db alkalmazásszerver, és ez így jó. No, meg szabványos! Az meg szóra sem érdemes, hogy 1 mező alapján lekérdezett 1 sornyi adatot (magyarázom: az adatstruktúra a büdös életben nem fog megváltozni) kell továbbítani. Ehhez azért feltétlenül szükséges az önleírás. :-D Csak manapság soap-ot mindenki tud programozni, egyszerű rpc-t meg csak akkor, ha van hozzá "szabványos java rpc". (WTF, nem is tudtam, hogy a java a szabvány! Inkább a C#! XD) Kb. itt tartunk, ezért - hiába rossz a kiejtése ;) - hajbival értek egyet. De csak részben. Nem hinném, hogy direkt opensource lenne a megoldás. Legfeljebb, ha az ingyenszoftvert az IBM fizeti. :-)

Alapvetően az internetezés koncepciója az, ami rendkívül szarul lett megtervezve, illetve nem is lett, csak alakult a sok pénzéhes, marketing-idealista csilimániás web-"fejlesztő" ökörködése mentén. Az internetes szolgáltatásokat üzemeltetőknek elég volna egy API-t biztosítaniuk, és azt valaki használhatná egy akármilyen jól kifaszázott biztonságú programmal. Számomra nonszensz, hogy egy weboldal kódot futtasson a gépemen, mert csak így hajlandó normálisan működni. Ez egy orbitálisan elhibázott koncepció. Adatokat kellene csak engedni ide-oda, hiszen a mai modern web-es cloud-idealizmusok is végső soron API-n kommunikálnak, csak előbb le kell töltődnie hozzá a javascript-bloat-nak. Helyette lehetnének asztali kliensek, amikhez nem kéne böngésző, és csak adatokkal kommunikálnának.

+1 !

Arról nem írsz soha semmit, hogy mire jutottál BSD vonalon. Pedig pont tegnap jutottál eszembe, hogy az egyik amcsi fórumon valakinek a 386-os gépére régi Linux helyett a NetBSD-d ajánlották, bár egy másik user be is idézte azonnal, hogy annak is min. 486-os proci kell. Azzal te is tehetnél próbát, nem Linux, de az XP-hez képest mégis modern rendszer, mai napig fejlesztik, támogatják, nem bloat. Bár az X szerverezést, meg a Gtk-bloatot lehet azon sem úszod meg, de soványabb OS-t nem nagyon fogsz találni P3-ra meg Turionra.

No keyboard detected... Press F1 to run the SETUP

Azért, mert pont arra jutottam, mint Linux vonalon. Gyakorlatilag ugynazokat az egyre jobban elsilányított, lebutított, idealista bloatware-eket kell használni ott is, ha grafikus felületet akarsz (értsd: hogy egyáltalán összehasonlítható legyen egy Windows XP-vel). Ott is van GTK3, ott is van bloated Qt5. Amiket egyértelműen nem vagyok hajlandó használni, csak azért mert friss™. Egy szó, mint száz. Maradok az XP-nél. Annak pedig örülök, hogy a frissítés-idealizmusod elkezdte megtörni a keserű valóság. Annak már kevésbé, hogy ezt továbbra is leművelhetik tech-multiék azokkal, akik meggazdagították őket. Avagy velünk, vásárlókkal, felhasználókkal.

Jó, de a Qt5, Gtk3 mögött nem állnak multik. Opensource közösség van mögöttük. Ebben egyezett ki a szakma, kellenek egységes API-k és libek, amire mindenki építeni tud, amit csak akar. Ezt ma már egy rendszeren sem úszod meg, még XP alatt sem, mert pl. ha nem akarod, hogy az uTorrent/Bittorrent bitcoint bányásszon a háttérben, felraksz egy qBittorrentet, de oh wait, ha megnézed a fájlokat, amikkel érkezik, tele van Qt-s .dll-ekkel. Plusz hiába kerülöd a bloatot OS szintjén, ahogy előszedsz egy böngésződ, ömlik az arcodba a bloatság, ma már az egész web, meg az összes működő böngésző bloat. Max csak úgy tudnád ezt elkerülni, ha barlangba költözöl és offline életet élsz.

Esetleg nem használsz grafikus felületet.

No keyboard detected... Press F1 to run the SETUP

Jó, de a Qt5, Gtk3 mögött nem állnak multik.

De igen. A Qt5 mögött állnak multik, illetve multiérdekek. A Gtk3 fejlesztői hátterét nem ismerem, de ahhoz hogy gyűlöljem, bőven elég ránéznem. Messziről lerí róla a tablet-idealizmus és a tech-multik (Apple, Google, Microsoft) által elbirkásított, egyre inkább lebutított felhasználói felületek majmolási mániája. Miközben amúgy még mindig desktop GUI toolkitről beszélünk.

Ebben egyezett ki a szakma, kellenek egységes API-k és libek, amire mindenki építeni tud, amit csak akar.

Engem nem kérdezett meg senki erről. Sőt, gyanítom, hogy e fórumon elitkedő, fősodratú mérnök urak többségét sem. És nem "a szakma", hanem a tech-multik találták ezt ki, nem "a szakmának", hanem birkáéknak. "A szakma" csicskamódra beáll a sorba és követi "dollármilliárdos cégek nem tévedhetnek" alapon.

Ezt ma már egy rendszeren sem úszod meg, még XP alatt sem, mert pl. ha nem akarod, hogy az uTorrent/Bittorrent bitcoint bányásszon a háttérben, felraksz egy qBittorrentet, de oh wait, ha megnézed a fájlokat, amikkel érkezik, tele van Qt-s .dll-ekkel.

Valamelyik FUD kampánynak megint sikerült felülnöd. A BitCoin bánya csak az ingyenes verzióval tud feltelepülni és kikapcsolható, amellett, hogy nem is az uTorrent része. A reklámblokkok is kikapcsolhatók Preferences -> Advanced alatt, csak ezekhez ugye át kell nézni az Advanced beállításokat is, nem csak belekényelmesedni a világba, ahogy az mostanában divatos. Mellesleg, még mindig az uTorrent az egyetlen normális, grafikus felülettel rendelkező, nem bloat asztali kliens. De a qBittorrent is inkább csak kisebbik rossz. Nagyon bloat-os kedvében elvan 80 MB memóriából. Belefér. Ettől függetlenül, nyugodtan használhatom az uTorrent régebbi verzióit is, amiben nincs BitCoin bánya, még véletlenül se.

Plusz hiába kerülöd a bloatot OS szintjén, ahogy előszedsz egy böngésződ, ömlik az arcodba a bloatság, ma már az egész web, meg az összes működő böngésző bloat.

Ez így van. Ezért használok ScriptBlock-ot és kerülöm alapvetően a bloat oldalakat. Tudniillik, a böngészőben sem magától jön a bloat. Kellenek hozzá oldalak, amit egyik-másik webökör bloat módon rakott össze, behúzva a fél világ JS libjét, majd azzal a legegyszerűbbnek tűnően, szigorúan a legkisebb ellenállás felé tendálva implementált mindent, nehogy túl sokáig tartson és egy kicsit technológiailag is igényes legyen.

Max csak úgy tudnád ezt elkerülni, ha barlangba költözöl és offline életet élsz.

Ez sokkal inkább egy raynes:~# systemctl start bullshit-generator.service, mintsem a valóság. A kettő között bőven van rengeteg minden, amit sajnos nagyon szeretsz ignorálni. De még a grafikus felület és a command line között is. Igyekszem az online életemet nem bloated weblapoktól függővé tenni. A mail fiókomat static HTML webmail-lel használom. Ha pedig a nem biztosítanának rá ilyen felületet, akkor IMAP-pel használnám. A static HTML pedig nem bloat. A reklámokat és mindenféle fölösleges JavaScript-eket kiblokkolva nagyjából felezhető az adatforgalom és a CPU használatra is nagyon jó hatással van. Nem olyan szar régi rendszerről böngészni, mint te azt elképzeled. Amit pedig így nem szívesen nézek meg, mert lassítja a gépet, attól gyors gépen is hánynék. Általában a marketing-idealista kinézet miatt. Túl kéne már lépned az "ez a hajbazer csak itt szivatja magát a régi rendszerekkel" kényszerképzeteden és belátni, hogy két okom bőven elég arra, hogy ne upgrade-eljek és egyáltalán nem lesz nekem szarabb attól, hogy nem upgradelek. Az egyik, hogy elvből nem adok ki pénzt hardverért csak azért, mert kínai rabszolgák olcsóbban összerakják, mint a kényelmes nyugati seggű szoftverfejlesztők a hatékony szoftvert. A másik, hogy az újabb hardverre újabb szoftverek kellenek, amiknek egyre silányabb (számomra kezelhetetlenebb) felületük van, egyre több felesleges dolog van bennük és egyre gyorsabban avulnak el, mivel szoftverfejlesztőéknek már Coffee Lake meg Ryzen van, amin írt bloatware-eik már alaposan megizzasztják a 4. generációs gépeket is. Szóval, összességében belehajszolnám magam egy egyre nagyobb léptékű upgrade-idealizmusba, amitől sokkal szarabbul érezném magam, mint amennyi árnyoldala van az XP-használatnak. Nem beszélve arról, mennyivel többe kerülne.

A linkeid nem bizonyítják, hogy multik vannak mögötte. Az első link olyan cégeket sorol, akik használják. A második link meg emleget contributor-okat, de azok vagy pénzzel vagy forráskóddal járulnak hozzá, INGYEN, tehát nincs multiérdek, meg profitmaximalizálás, meg kapitalista idealizmus, amiket írni szoktál. De néha a contributorok olyan apróságokkal is hozzájárulnak, mint a projekt webhosztolása, logójának dizájnolása, több nyelvre történő lokalizáció (interface, dokumentáció), vagy reklámozzák az adott projektet, adnak pénzt rendezvényekre, stb..

Amikor írtam, hogy ebben egyezett ki a szakma, akkor úgy értettem, hogy a fejlesztők. Persze téged jó hogy nem kérdezett meg senki, mivel eleve nem is foglalkozol végfelhasználóként fejlesztéssel, de ez nem nagy baj, mert pl. én sem vagyok fejlesztő. De egymást sem kérdezik meg. Kialakulnak megoldások, beállnak mögé emberek, elkezdik használni, ha tetszik nekik. Mikor egyik megoldás jobban elterjed, akkor ez a hatás fokozódik, még többen állnak be mögé, elkezd kvázi szabvány lenni. Téged nem fognak megkérdezni, mert a véleményed sem érdekli őket, meg beleszólásod sincs. De pl. nem akadályoz meg senki, hogy csinálj saját libeket, frameworköt, és elterjeszd, ha kellően jó, akkor amögé fog besorakozni mindenki, meg ahhoz fognak hozzájárulni kóddal, pénzzel, támogatással. Rajtad áll.

Félre ne értsd, a mai állapotokkal, bloatosodással, meg a buzi flat dizájnolással, grafikus felületek visszabutításával én sem értek egyet. Én is örülnék neki, ha a szoftvereknek csak fele ekkora hardverigénye lenne, és a hardverek is legalább még 2× olyan olcsók lennének, mint most, meg a böngészőben nem kéne 100 millió dolgot blokkolni, hogy a web használható legyen. Ez meg is lenne valósítható, de akkor is álomvilág. A valóságban élünk, nem álmodozni kell. Azt a megoldást kell választani, ami a leginkább előnyösebb. Ha csak sok szar közül lehet választani, akkor a legkevésbé szarabbat kell használni. Ez már régóta a Linux. Nem a Win10, nem a MacOS, de pláne nem a rég elavult, már semmi által nem támogatott XP.

No keyboard detected... Press F1 to run the SETUP

El kell keserítselek, a Qt közelebb áll a multikhoz, mint gondolnád. 2008-tól 2012-ig a Nokia nevű multi kezében volt, ami azt jelenti, hogy ezidő alatt legalább 4 évnyi fejlesztés multi által, multi érdekében történt. Később a Nokia eladta a Digia-nak, ami bár eléggé multi akar lenni (expanding our international presence together with our customers), de jelenleg még nem az a tulajdonosi hátterét tekintve. Persze, nem csak az számít, hanem az, hogy hogyan működik. Az önképüket tekintve egyértelműen multi, ugyanis befektetésként árulják a lelküket (Digia as an Investment). A linkek is azt bizonyítják (bár Neked sajnos megint nem jött át a lényeg), hogy alapvetően multik érdekei mentén fejlesztik a Qt-t. Olyan nincs, hogy egy multi csak úgy, belecommitol egy open-source repo-ba. Azért commitol bele, mert ő is használja és az saját érdekeinek megfelelően alakítja. Olyan se nagyon fordul elő, hogy egy multi "csak úgy" támogat egy open-source projektet. Valamilyen célja biztos, hogy van vele.

De egymást sem kérdezik meg. Kialakulnak megoldások, beállnak mögé emberek, elkezdik használni, ha tetszik nekik. Mikor egyik megoldás jobban elterjed, akkor ez a hatás fokozódik, még többen állnak be mögé, elkezd kvázi szabvány lenni.

Na, ez a legnagyobb szégyene a szakmának, hogy így működik. Pláne, ezek a "kvázi szabványok", amikből Dunát lehetne rekeszteni és így jutunk el oda, hogy a jelenleg adoptált csúcstechnológia egy HTTP-protokollra felültetett, gzip-pel tömörített, minimalizálással olvashatatlanná tett, de mégis interpretált JavaScript bloat, ami még tömörítve is több megabájt, futtatva pedig több száz megabájt memória. Ezt pedig egyeseknek van pofájuk szabványnak csúfolni. Miközben ugyanaz a funkcionalitás egy static HTML-lel is megvalósítható lenne, natív kóddal meg tized annyi erőforrásból. Hány gépet kell belassítani és kidobatni ahhoz, hogy végre észbe kapjanak szoftverfejlesztőék?

Azt a megoldást kell választani, ami a leginkább előnyösebb. Ha csak sok szar közül lehet választani, akkor a legkevésbé szarabbat kell használni. Ez már régóta a Linux. Nem a Win10, nem a MacOS, de pláne nem a rég elavult, már semmi által nem támogatott XP.

Az, hogy kinek mi a kisebbik rossz, továbbra is igény és tapasztalat kérdése. Nem kiálthatod ki önkényesen a Linuxot kisebbik rossznak. Én is megkapom a magamét, ha az XP-t annak kiáltom ki. Neked a Linux, nekem pedig a Windows XP. Ebben tudunk kiegyezni. Azonban, onnantól, hogy a Linux alatt (desktopról lévén szó) értünk csiligány, bloated, tákolmány, designer-diktatúrabuzi CSS-idealista, tabletizált GTK3-at is, onnantól nem kisebbik rossz. Onnantól egy fos szar húgy rakat mocsadék szar.

Valamilyen szinten ebben kezdek veled egyetérteni. Mármint nem a frissítések és patchek fel nem tételében, meg az XP éltetésében, hanem úgy értve, hogy elkezdtem én is hanyagolni ezeket a procis sérülékenységeket, lesz@rom most már. Egyre több CPU security bugot találnak meg, gomba módra szaporodnak, egyre inkább nem tudnak lépést tartani a foltozással, ergo mindenki sérülékeny, értelmetlen bármi ellenállás.

Pont pár napja publikáltak még 3 sérülékenységet, foreshadow, meg stb., jönnek ezek csőstül a jövőben, és mindenki védtelen lesz, mindegy hogy a Spectre Chapter n+1 Patch fent van-e neki, mert a hajára kenheti. Még az sincs, hogy veszel olyan procit, ami ezekben nem érintett, mert általában mind az. AMD-k egyelőre kevésbé, de majd a jövőben azokban is egyre növekvő ütemben fedezik fel a jóságokat. Ezt most mindenki megszívja, nincs mit rajta szépíteni.

Még azt sem mondanám, hogy elég letiltani a spektulatív meg out-of-order végrehajtást, mert pl. az SMT-t is támadják már, meg minden fajta cache felhasználást, és akkor ennyi erővel az összes procicache-t is tiltsuk le, és visszasüllyedünk a végére a DOS korszakbeli, egy szálas 80386-os sebességére. Itt valamit a procigyártóknak kell majd lépnie, valami nagyon gyökereset, hogy ennek a dominóhatásnak az elejét vegyük egyszer és mindenkorra. Valami teljesen más tervezési koncepciót, egy vadi új architektúrát kell ez ellen kitalálni.

No keyboard detected... Press F1 to run the SETUP

Sajnos a W10-en nincsen nagyon alternatívád "nem foglalkozni vele" mert, az MS gőzerővel foltoz "foltozó kedden" és azon túl is..,

Éppen, egy használhatatlanul lassúvá vált gépen kerestem az okot, mivel az "után" állapot egy legutóbbi (22.-i) patch településétől jelentkezett, ezért elkezdtem eltávolítani a legutóbbi hónapokban felrakott frissítéseket. 4-ig jutottam, és a Windows csodák-csodája alaposan meglódult. (Nem is gondoltam volna, hogy ennyi teljesítmény úszott el a proc. hibák mitigálásával.

Hozzáteszem, a "Spectre" hibák kihasználásának valós esélye a gyakorlatban sokkal kisebb. A foltozás lassító hatása viszont nagy. Főleg így van ez a relatíve kisebb teljesítményű, régebbi proc.-okon. (A legújabb generációs "csodák" meg jobban bírják a foltozást.)

(Lehet "Intelék" teljesítmény-fokozásra jobban ösztönzöttek azért, hogy a prochibák a gyakorlatban hatékonyabban kihasználhatók legyenek, mert mihez kezd egy "hárombetűs" ilyen lassan csordogáló bitekkel, az ügynöknek még az élettől is elmegy a kedve, mire a hálózaton keresztül átmegy egy kulcs. Nem véletlenül akarják kiírtani az elavult számítástechnikát, nem lehet ezeken keresztül hatékonyan még kémkedni sem. Valójában minden fejlesztés a hatékonyabb kiberháborút támogatja, akarva vagy akaratlanul. - Ha valakinek megfelel az XP, nekem semmi bajom ezzel. Sok konzervatív életmódot folytató ember "nem tevékenységének" (nem autózásának, túlzottan nem mosakodásának, stb.) hála, hogy még élni lehet ezen a sárgolyóbison. :) erre gondolsz Hajbazer?)

Nem értek veled egyet abban, hogy ezeket leszarod, csak mert mindenki érintett, és mert szerinted mindenki leszarja. Persze megteheted, ha éppen az otthoni rendszeredről van szó, vagy olyan infrastruktúráról, amin nincs semmi érzékeny cucc. Véleményem szerint viszont nem ebben a cipőben jár az üzemeltetők többsége, így - habár hajbazer álláspontja szerintem teljesen valid egyes esetekre - mindenképpen szituációtól függően alkalmaznám vagy vetném el a javítások élesítését.

Az meg, hogy az AMD-k esetében mi lesz, szvsz még fehér folt az emberek 12 kilences százalékának. Én nem lennék abban olyan biztos, hogy itt is találni fognak olyan volumenű sérülékenységeket, mint Inteléknél. Az AMD az Intelhez képest vergődött az utóbbi évtizedben. Talán pont azért, mert nem alkudtak meg, nem akartak kerülőutakat találni, nem csak a sales és a részvényesek irányítottak, többet költöttek kutatásra és hosszabban fejlesztettek, ami magával hozhatja (feltételes mód!) azt, hogy kevésbé lesznek lyukasak, hibásak a procijaik.

Csak remélem persze ez utóbbit, meg őszintén örülnék is neki, ha végre a mindenekfelett álló profithajkurászás nem ülne tort a szakmaiságon. Aztán meglátjuk mi lesz... Egyelőre számomra az Intel pont ugyanabba a cipőbe lépett bele máshogy, mint nemrég a Volkswagen és társai. Emiatt jó időre leírtam őket (ami egyenlő a nullával, de akkor is)...

Pedig biztos lehetsz benne, hogy az AMD-kben is van sérülékenység, csak még nem találták meg. Ami késik, az nem múlik.

Nem lehet sajnos mást tenni, mint leszarni. A 4.18-as kernellel, meg az új Intel mikrokóddal ugyan megérkezett a Spectre 3a, Spectre 4 foltozás is, de elég későn. És jönni fognak újabb sérülékenységek. Egyelőre egy mázli van a szerencsétlenségben, nem tudni olyan rosszindulatú kódról, ami kihasználná ezeket a sérülékenységeket, amin csodálkozok is.

Egyelőre azt tudom tenni, hogy friss rendszert használok, meg csak a hivatalos tárolókból és ellenőrzött helyről szedek kódot, ami nem tartalmaz sérülékenységet kihasználó kódot. Így a gépemen elvileg csak böngészőben futhat le csúnyaság, de mivel az egyéb foltok fent vannak, meg a böngészőket külön is foltozzák, elég gyorsan, így ez kevésbé probléma. De még így sem lehet szavatolni, hogy valaki nem érintett.

Nem adok még 2-3 hetet, megint megjelennek új cikkek, hogy valami amerikai egyetemen még 3-4 másik sérülékenységet is találtak a procikban, vagy a Google Project Zero biztonsági csapat, Travis Ormandy vagy valami holland egyetemről Van der Lóf@sz publikálja, amiből 1-iket a meglévő Spectre-foltok kivédenek, a másik 2-3-at nem. Majd meglásd. Így is illetlenség ezt előre jósolni, mert úriember biztosra nem fogad. Mondom, ez ellen azt lehetne tenni, hogy mindent letiltasz a procin, de akkor már annyi erővel használjunk 386-ost DOS-szal offline, meg abakuszt logarléccel és lyukkártyával, hogy ne legyen sérülékeny. Vicc az egész. Még a Meltdown, Spectre 1-2 idején még reménykedünk, hogy elkészül a folt, és megúsztuk. A folt elkészült, de jöttek az újabb sérülékenységek.

És még így is örülhetünk, hogy ezeket a sérülékenységet legalább publikálják és foltok is készülnek, még ha teljesítményvesztést okozva és sokára is, meg csak a 2. nekifutásra lesznek működőképesek, bugmentesek. Képzeld el, hogy az NSA meg a kínaiak milyen olyan sok sérülékenységről tudhatnak, amit nem is publikálnak, hanem elteszik titkosszolgálati és cyberfegyveres hadititoknak, te meg azt hiszed, hogy milyen secure a rendszered, mert hardened profilos SELinuxszal küldöd Gentoo-n, és minden sor forráskódot van időd átnézni, ellenőrizni forráskódból forgatás előtt, közben meg akkor nem járnak ki/be benne, amikor nem akarnak, csak nem kötik cikkekben az orrodra, meg külön a routered, okostelefonod is tudják támadni akármikor. Windowson meg, ahol automatikusan eldönti az MS helyetted, hogy milyen kód fusson a tudtod nélkül meg milyen adatokat szivárogtasson, ott egy nagyságrenddel rosszabb még ennél is a biztonság, hiába nem töltesz le gányolt szoftvert, meg teszed fel az összes foltot, és fut normálisan bekonfigurált vírusirtó tűzfallal. Ennél már csak az androidos eszközök rosszabbak, amik legtöbbször semmilyen frissítést nem kapnak, így még a publikált sérülékenységekkel szemben is védtelenek maradnak, mert a gyártónak nem éri meg támogatni a régi készülékeket, ha egyszer már nincs belőle bevételük.

No keyboard detected... Press F1 to run the SETUP

( xc0m v | 2018. 09. 03., h – 11:46 )

Szerintetek SAMBA és seed server-en érdemes lehet lekapcsolni a védelmet?
Nagyon ritkán a Firefox is fut rajta, de abban van védelem a javascript-es támadások ellen, ha jól tudom.

( Raynes v | 2020. 12. 31., cs – 18:22 )

Szerkesztve: 2020. 12. 31., cs – 18:29

Ezt a témát zárni kéne. Nem személyes okból, mert tényleg egyes gépeken, egyes felhasználási körökben érdemes lehet kikapcsolni ezeket a foltokat, hanem egyrészt elavult, 2 éves téma, másrészt áttekinthetetlenül hosszúra dagadt, most feljött új hozzászólással, amit kereséssel sem találtam meg, meg ilyen régi hsz.-hez hozzászólni már csak topiknekrofíliának jó. Tudom, most én is hozzászólok, de csak azért, hogy jelezzem.

Az 5.2-es kernel óta, azaz kb. másfél éve már nem kell a kernelnek bootkor beveretni az ibpb rbrkg zsgbi blabla hácé wcsnéni iddqd idkfa bűvszavakat, mitigations=off és el van intézve egy paraméterrel. Persze ezek a konkrét foltok elleni kapcsolók is működnek, igaz csak egy részük, másik részük át lett nevezve. Jó, ezt a mitigations kapcsolót írja is az átszerkesztett nyitóhsz., de eldugva, és eleve nem pontosan, mert nem csak az 5.12-es kernel óta támogatatott. Szerintem már Win10 alatt sem működik az a módszer, amit a szerző említ, mert a MS szándékosan átvariálja minden újabb nagy évszakos upgrade-ben ezeket a hekkeléseket, hogy ellehetetlenítse őket, ami módszer még ment Win10 1909-en, az nem fog menni v2004-en, és ami az alatt ment, az 20H2 alatt nem fog menni. Ez ilyen, a MS nem akarja, hogy a user ura legyen a rendszerének. Tiltható továbbra is, de szerintem csak újabb módszerrel. A Win7 támogatása meg megszűnt már, így nem a foltot kell kikapcsolni rajta, hanem lehetőleg upgrade-elni. Tisztában vagyok a 3×1 éves volume licences extra támogatással, de az magánusernek nem elérhető hivatalosan, bár nem hivatalosan lewarezolható, de ez is már csak ~2 évig járható út, én a még Win7-et használók helyében nem halogatnám a váltást +2 évig, nem lesz már addig semmi, csak kifutnak az időből, aztán menni fog a sírás, hogy szemétmájkröszaft, négyszáztrillió júzörnek megszüntette a támogatást, milyen váratlan, tervezetelavulás, profitmultik minden kidobatnak, möhöhő. Közben meg lehetőségük volt a Win7 usereknek már ~5 éve váltani valami másra, hogy anno az XP-s usereknek is volt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Kellett ebből is a 16 színre butított, óvodás kinézetű laposdizájn, különben nem mondhatják el, hogy innováltak™, meg haladtak™ a korral™.

Legalább lesz korszerű™ emoji, amivel tapicskolóék kifejezhetik bánatukat a Surface-ükről, ha a következő Windows 10 professzionálisan™ tesztelt™ frissítése épp kinyírja a PC-jüket.

Ezt a témát zárni kéne. Nem személyes okból, mert tényleg egyes gépeken, egyes felhasználási körökben érdemes lehet kikapcsolni ezeket a foltokat, hanem egyrészt elavult, 2 éves téma, másrészt áttekinthetetlenül hosszúra dagadt

Láttunk már sokkal hosszabb topicokat itt, amik a mai napig nyitva vannak és 5x ennyi hozzászólással rendelkeznek, pl. Saxus Mérnök Úr Paksi matekja. Értem, hogy bántja a szemed, még ha nem is személyes okokból (persze, persze), hogy vannak, akik másképp gondolkodnak és a számodra elfogadható veddmegdobdki-lépjtovább-frissítsmertezajövő szentháromsági síkon kívül is képesek létezni, de ez egyéni szociális probléma.

most feljött új hozzászólással, amit kereséssel sem találtam meg

Gyengébbek kedvéért, erre kell keresni, kattintás után: [új]

Ha ez nem jött be, akkor: "2020. " (illetve most már "2021. ")

meg ilyen régi hsz.-hez hozzászólni már csak topiknekrofíliának jó

Mit nekrofilkodsz itt akkor? Menjél át szépen a vadonatúj™, korszerű™, nem™ elavult™ topicokba.

Az 5.2-es kernel óta, azaz kb. másfél éve már nem kell a kernelnek bootkor beveretni az ibpb rbrkg zsgbi blabla hácé wcsnéni iddqd idkfa bűvszavakat, mitigations=off és el van intézve egy paraméterrel.

De nem mindenki használ ilyen kernelt és nem is erőszakolhatod rá mindenkire, hogy ilyet használjon.

Jó, ezt a mitigations kapcsolót írja is az átszerkesztett nyitóhsz., de eldugva, és eleve nem pontosan, mert nem csak az 5.12-es kernel óta támogatatott.

5.1.13 lett odaírva, de ne zavarjon és onnantól támogatott. Az, hogy a Home gombbal egy ugrásra előhívható témaindítót sem vagy képes figyelmesen elolvasni az alatta lévő kommentek hossza miatt, szerintem már súroloja a user error határait.

Szerintem már Win10 alatt sem működik az a módszer

Akkor jöhetnek a javaslatok, hogyan módosítsuk a Windows 10-re vonatkozó szekciót. Érdekes, csak akkor vagy nagy open-source huszár, amikor másokat próbálsz rábeszélni, hogy éljenek úgy, mint te és használják ugyanazokat a rendszereket, mint te. Amikor be kéne segíteni valamibe, akkor csak kritizálni tudsz, meg topicletiltásért kiáltozni.

Tiltható továbbra is, de szerintem csak újabb módszerrel. A Win7 támogatása meg megszűnt már, így nem a foltot kell kikapcsolni rajta, hanem lehetőleg upgrade-elni.

Mondd ezt annak a 900 millió embernek, aki eddig sem upgrade-elt, pedig 7 éve rendelkezésre állnak alternatívák (Windows 8, Windows 10, Linux). Nem lehet, hogy esetleg jó okuk van nem frissíteni? Jaj, tudom, persze, a lustaság™, szerinted. Valójában meg az inkompatíbilitás miatt, és hogy ne kelljen kidobni egész munkaállomásokat, nyomtatókat, scannereket, megvásárolt szoftvercsomagokat. Tetszik, nem tetszik, vannak és lesznek még legalább egy évtizedig Windows 7 userek, még Magyarországon is és talán nekik van a legnagyobb szükségük a CPU-belassító Intel-tűzoltások kikapcsolására, az erőforrásban szűkölködő, régi gépeiken.

Gyengébbek kedvéért, erre kell keresni, kattintás után: [új]

Igen, ez nagy segítség, kivéve, amikor tomsolo is hozzászól a témához, mert ő ezt a karakterkombinációt kétszer is szerepelteti az aláírásában (_ [új] - No rainbow, no sugar - [új] _). Írtam neki, kértem, hogy ezeket törölje az aláírásából, de nem jártam sikerrel.

Szerencsére nem túl aktív a humoros fórumtárs, de néha elég zavaró, pl.

https://hup.hu/node/170158

"vannak és lesznek még legalább egy évtizedig Windows 7 userek"

Amíg csak élnek, - mert ha pl. normálisan akarsz különböző gépekből származó - (és időről-időre visszatérő igénnyel,) - merevlemezeket felváltva kezelni, akkor a barátod a W7 nem a 10!!!  :)  Természetesen ez a featúra "egy gép-egy lemez", - laptop, - mellett nem kell senkinek..., de hát különböző eszközparkkal, feladatokkal vagyunk megáldva.

Folyamatos felhasználást feltételezve egy W7 inkább megfelel egy normális oprendszer fogalmának, mint egy W10, - az inkább a felhasználó-szivatás fogalmának felel meg!!! - ( Ha már Win, akkor sok év rendszerek "egymás mellett élésének" tapasztalata... :) )

Nem bírtam ki, - hozzászólás nélkül..., - ezt a nekrofiliát...., :D

semmi gond azzal, ha -számomra- fura dolgokat hordasz össze, csak legalább légy a saját világodban következetes.

pl

 - "Tudom, most én is hozzászólok, de csak azért, hogy jelezzem." -> fck logic? :)

avagy

 - "zárni kéne" -> írj annak aki zárni tudja. bár trey épp megszüntette a modlogot, de ott amúgy eddig pl követhetőek voltak a hasonló cselekmények is és azok okai.