"Megvan, ki a felelős a <Crowdstrike> patchmageddonért: Brüsszel!"

Titkosítás, biztonság, privát szféra
A Microsoft szerint a cégnek nem volt lehetősége blokkolni a kernelszintű hozzáférést a fejlesztők számára, mégpedig egy az Európai Bizottsággal kötött 2009-es megállapodás értelmében, mely oda vezetett, hogy a vállalatnak ugyanazt a hozzáférési szintet kell biztosítania a külső biztonsági szoftverek számára, mint amit a saját fejlesztésű megoldásoknak biztosít.

Részletek itt.

Hagyjuk már ezt a mérnöki felsőbbrendűségi izét, nincs olyan szakma, ahol elvileg mérnökök dolgoznak és a munkájukon nem kap az ember aranyeret a röhögéstől ...

Elkezdjük az autóiparral? Mutassak neked olyan mérnöki teljesítményt, amitől egy szerelő a fejébe baszná a baltát? Pl., hogy egy szar helyre és anyagból tervezett alkatrész cseréje miatt kb. 20 billió alkatrészre kell szétszereli egy autót? :D

trey @ gépház

Hát, akkor tarthatnánk a kőből pattintott keréknél, mert végül is működött, miért kellett vele tovább foglalkozni bárkinek is mérnökileg?

Pontosan, hogy a mérnökökkel rontatják el a működő dolgokat, mert a mérnöknek mára nem az a dolga, hogy valamit tovább fejlesszen (még jobbá tegyen), hanem, hogy "élettartamra optimalizálja" (rosszabbá tegye) a környezetvédelemre hivatkozva (ami ROTFL). És a mérnökök ehhez adják is a nevüket, hogy mindig legyen egyel nagyobb házuk, egyel drágább kocsijuk, egyel több nyaralás évente, stb.

Úgy hülyeség ahogy van. Ha valami tud hatékonyabban olcsóbban és jobban működni akkor hozzá kell nyúlni. Ezt egy mérnök pontosan látja/számolja. Akikről te beszélsz azok nem mérnökök hanem filozófusok. De ők el is vannak egy fa alatt jó estben csak simán rosszabb esetbe betépve a sok fütől.

Semmi bravó nincs benne. Nettó hülyeség. Ami még Win3.1-re íródott azt marha könnyű lenne újraírni, vagy portolni. Eleve a 16 bites Win3.x-es alkalmazások általában nagyon jól futnak Wine alatt, ezt személyes tapasztalatból mondom. Általában mind hibátlanul fut, amelyik nem, az is fut, de 1-2 funkció hiányzik belőle, pl. nincs hang, mert még olyan hangkártyát/drivert keresne, amit a Wine nem emulál, pl. a Midisoft Recording Session igényelne ilyet. Ennek a Southwestnek nincs szüksége ilyen multimédiás malőrökre.

Igazából meg senkit nem érintett, aki nem dugta be a fejét ebbe a Crowdstrike sz*rba. Nem is értem, hogy cégek ezt miért érezték kötelezőnek. Igen, Windowson kell valami vírusvédelem, de a MS beépített megoldásai miért nem elegek a cégeknek? Elég szomorú, hogy ezt a szutykot egyesek Linuxra is feltették, volt is belőle gond, ahogy néztem róla a híreket.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( XMI | 2024. 07. 23., k – 09:37 )

Hát igen, kár lenne ezt a lehetőséget hagyni veszendőbe menni, ritkán adódik ilyen... :)

Régóta vágyok én, az androidok mezonkincsére már!

Tippre: valami ratyi Crowdstrike proprietary blob kernelmodult kell betölteni, amitől azonnal tainted lesz a kernel ... Tehát, pont ugyanúgy ...

Szerk: így legyen ötösöm a lottón:

https://github.com/CrowdStrike/community/issues/24

(Nem baj, ha nem érted amit írok, old school témák)

trey @ gépház

Szerkeszteni akartam a hozzászólásomat, de megelőztél, úgyhogy ide írom:

Ja, meg így jól belegondolva, akkor a MS önszántából kevésbé jó terméket szállított Amerikába, Ausztráliába, meg úgy nagyjából mindenhova máshova, ami nem Európa. Pedig tudott volna, ha akart volna, hiszen mi gátolta volna meg? Nem volt hajlandó annyi pénzt áldozni, amivel fenntarthatott volna egy külön branchet egy ilyen nemes cél érdekében? Forintosítva mennyit keresett azon, hogy szándékosan gyengébb minőséget szállított az EU -n kívül mindenhova, mint amit tehetett (és ezek szerint akart is) volna?

Baszki, ha már hazudni kezd egy ilyen nagy cég, legalább annyi energiát tegyen bele, hogy ne egy olyan közép balkáni utolsó számtekes srác, mint én vegye észre a baromságot abban amit mond. Szánalmas hazugság, szánalmas cég?

A Microsoft neve forgott napokig és forog most is a híroldalak címoldalán, mémek közepén. Mégis mit vársz tőlük? A befektetők mit várnak a cégtől?

Hogy a Crowdstrike szara miatt ők vigyék el a balhét?

Hol van most az a duma, hogy a Windows nem kékhalálozik, csak ha szar a driver vagy dilettánsok írnak kódot hozzá?

Sok kérdés merül fel ...

trey @ gépház

Ki szerint hazudott? Ez nem így működik. Jogi úton tudsz érvényt szerezni a sérelmednek, már ha van. Pontosan a problémád sem értem ... mit hazudott? Nem az a kérdés, hogy megfelelt-e a hatályos szabályoknak? Nincs 3 napja, hogy azzal jöttek nekem itt a HUP-on, hogy a Fanta nem szar Magyarországon az 5%-os gyümölcstartalommal, csak megfelel a szabályoknak. 🤷‍♂️

trey @ gépház

Nem fejlesztek kernelt (meg mást sem), de felmerül bennem a kérdés, hogy nem lehetne olyan automatizmus (ami benne is van a Windows-ban már most is...), hogy ha megborul egy kernel modul (amiről nyilván tud a rendszer, mert szép kék képernyőn erről aránylag részletesen tájékoztatja a júzert), akkor a következő indításnál azt egyszerűen nem tölti be? Problem solved, és az ügyfelek mehetnek a CS-hez reklamálni, hogy nem fut a szarjuk, mert a Windows a benne lévő hiba miatt nem tölti be. Így az MS jó fej lenne automatikusan, megvédte a júzert a csúnya gonosz külső fejlesztőtől.

De nyilván egyszerűbb nem csinálni semmit, ha beborul a gép bármi miatt, hanem azt mondani, hogy "ha mindenből MS terméket veszel, akkor ilyen nem fordul elő" (ami meg egyszerűen nem igaz, de ezt sose fogják elismerni).

A levelezéssel is ezt csinálják jó ideje. Nagyjából semmi szabványnak nem felelnek meg az M365-tel, és ha valaki onnan kifelé, vagy oda befelé nem tud levelezni, akkor a választ az, hogy mindenki fizessen náluk elő, és akkor nem lesz gond a levelezéssel többet... (és ez sem igaz, mert nem példa nélküli, hogy két MS tenant nem tud egymással levelezni, de erről sem beszélnek nyilván...).

Ezek a nagy cégek monopolizálni akarják a világot, maguknak, minél több téren. És erre mindig kitalálnak valam populista dumát, hogy elérjék. És az egyik ilyen a másik ellen azért lobbizik csak, hogy a másik ne tudja jobban monolopizálni, mint ő, nem a környezetet, nem a fejlődést, nem a fogyasztót védik igazából...

Aztán jönnek az ilyen vélemények, hogy a hülye EU-s szabályozás tesz rosszá mindent. Holott, lehet, hogy a szabályok nem tökéletesek/ideálisak, de legalább valaki (szervezet) próbál az ellen tenni, hogy maximálisan ki legyünk szolgáltatva ezeknek a kizárólag a befeketetőknek megfeleni akaró multiknak.

Az egyébként az egy jó felvetés, hogy ha kizárólag az EU-ban érvényes ez a kötelező kernel modul beengedés külsősöktől, akkor a világ többi részén miért nem zárt a Windows kernel? Ha ott jogilag lehetne az, és ezzel szerintük megvédenék a fogyasztókat az ilyen hibáktól? Nem hiszem, hogy akkora nagy munka lenne egy flag, hogy "no, itt nem telepítheted ezt a szoftvert"... Elvégre fejlesztés akkor volt, amikor lehetővé kellett tenni a külső modul használatát, az nem igényel (már további) fejlesztést, hogy ne lehessen ilyent használni.

hogy ha megborul egy kernel modul [...], akkor a következő indításnál azt egyszerűen nem tölti be?

Sajnos nem ilyen egyszeru, kernel modul az kb mint egy .dll vagy .so, egy address spaceben fut a kernel tobbi reszevel, egy rossz kernel modul tulir egy buffert vagy use after free miatt felulir valami unrelated memoriateruletet, aztan valahol a kernel teljesen masik reszen ami megrpobalja az igy felulirt adatot hasznalni crashel. Vagy hogy meg egyszerubb legyen, C a random unchecked pointereikkel meg tarsaival, van egy A fv ami meghiv egy B fuggvenyt ami crashel. Most a B fuggvenybe van a hiba, vagy mondjuk az A adott be neki szar parametereket (pl egy invalid pointer)?

Nyilvan, lehet heurisztikakat gyartani ami sok esetben mukodik, de tokeletes nem lesz. Aztan vannak az ilyen nagyon jo dolgok, mint pl. a windows startup recovery vagy mi a tok, ami tobbet art mint hasznal (pl. felulirja a gepedben levo diskek particios tablait mert nem talalt rajta windows altal tamogatott filerendszert...)

M365

Jaj az a masik formedveny, nem tudom mar melyik website regisztracios formjan lattam leirva, registraltal, nem jott meg a confirmation mail, es outlook.com-os emailed van? Hasznalj egy rendes mail szolgaltatot.

I hate myself, because I'm not open-source.

Sajnos nem ilyen egyszeru, kernel modul az kb mint egy .dll vagy .so, egy address spaceben fut a kernel tobbi reszevel

Ennek nem feltétlenül kell így lennie. Jellemzően a monolitikus kernelek működnek így. (Bár személyesen nem ismerem részletekbe menően a hybrid NT kernel architektúráját.)

"hogy ha megborul egy kernel modul (amiről nyilván tud a rendszer, mert szép kék képernyőn erről aránylag részletesen tájékoztatja a júzert), akkor a következő indításnál azt egyszerűen nem tölti be?"

Egyrészt felröhögtem az "aránylag részletesen"-en :) "Something went wrong." És még oda is tesz egy szomorú smiley-t, a részletesség jegyében... :) Hiszen, aki ért hozzá az úgyis tudja, hol találja a hiba részleteit a windows event viewerben... ohwait!

Másrészt fentebb megválaszoltad a saját felvetésedet: "(ami benne is van a Windows-ban már most is...)"

Igen, ez egy létező feature. Egyetlen baj vele, hogy Crowdstrike-ék szándékosan megakadályozzák, hogy működjön, hogy a user ne tudja hibainjektálással leszedni a rootkitet a gépről. Bizonyos szempontból logikus is, inkább legyen egy támadás denial of service, minthogy a cég adatai kikerüljenek az ellenőrzés alól.

Grafitember után szabadon: Ez egy nagyon jó kis rootkit. Csakhát beszart.

Régóta vágyok én, az androidok mezonkincsére már!

Amit írsz az szerintem általánosabb követelmény, mint ami létezik.

Olyan van, hogy a bootloader rögzíti, hogy a boot folyamat megkezdődött, feljebb lök egy számlálót, és a már sikeresen bebootolt OS lenullázza a "boot megkezdődött" számlálót. Ha a számláló elér egy határértéket, akkor a bootloader automatikusan valami recovery módban próbálja indítani. Volt ilyen ubuntu-n is, van windows-on is.

Az újabb windows-ok elvileg tudnak olyat, hogy amelyik driver miatt crashelt legutóbb a kernel amelyik driverben járt éppen a végrehajtás amikor a crash-t kiváltó hiba történt (ha még le tudja logolni a crash közben), akkor a következő bootnál azt a drivert letiltja. Kivéve, ha a driver "boot-required" vagy "boot-critical" vagy hasonló nevű flaggel van beregisztrálva. Ez nyilván érthető, hiszen mondjuk az NVMe vagy az NTFS driver crashelt és a következő bootnál a windows letiltaná, akkor nincs miről bootolni. Crowdstrike-ék ezt a mechanizmust abuzálták, hogy letilthatatlanná tegyék saját magukat.

Linux-on elvileg létezik egy hasonló systemd feature, "Automatic Boot Assessment" néven. Nem tudom mennyire elterjedt, hogy az egyes disztrókban használva lenne.

Régóta vágyok én, az androidok mezonkincsére már!

Fentebb volt ez a felvetés, arra válaszoltam. Kernel panic/kékhalál esetén semmilyen rendszer nem ir/módosit semmit, kivéve a memory dump-ot, ami egy nagyon speciális része a kernelnek és fix helyre ir.

Az általad felvetett megoldással kapcsolatban is vannak kételyeim. Egyrészt párhuzamosan is indulnak modulok, ami már lehetetlenné teszi, hogy egy sima betöltési státusz naplóból ki lehetne szűrni a hibát okozó modult, másrészt az, hogy a modul betöltése kernel panic nélkül lefutott nem jelenti azt, hogy 2 ms-al később az első betöltés utáni kódsorral kinyirja a rendszert, miközben már a következő modul töltődik.

Én nem ismerek ilyen metódust, hogy ilyen alapon letiltana a windows kernel drivert, linkelj erről valamit okulásul.

Amit ismerek, hogy x db sikertelen betöltési kisérlet után (amit valóban a boot napló alapján vizsgál) bejön a recovery console, ahol lehetőséged van safe mode-ot vagy egyéb javitást lehetővé tevő rendszert betölteni.

EDIT: az az érzésem, hogy nagyon kisarkítod ezt a "crashelő kernel konfigurációt módosít" dolgot. Amikre én gondolok azok nagyon best-effort jellegű próbálkozások arra, hogy a user valahogy mégis elinduló gépet kapjon.

Ugyanakkor abban igazad lesz, hogy itt több anekdotális állítás van, amiket elhittem, de valójában technikailag lényegesen kevesebb van mögötte.

Megpróbáltam elkezdeni utanákeresni ennek, hogy a windows egész pontosan milyen recovery feature-t is tud, ha már mindenki emlegeti, hogy a windows "automatikus recovery" képességét megakadályozta, hogy CS-osok "boot-start driver"-nek jelölték. Igazából senki nem fejti ki, hogy egész pontosan mi is volt az elvárás. Safe mode-ban el tud indulni a gép, ez a működő fix, ezt nem akadályozza meg. A boot last known good configuration-nél elvileg van többféle próbálkozás inkrementálisan egyre több dolog visszagörgetésére, de nem igazán látok egzakt utalást arra, hogy a kernel crash dump meglétét/tartalmát valami hintként felhasználná, hogy melyik drivert hagyja ki. Technikailag amúgy szerintem ez megvalósítható lenne, és az esetek jelentős részében a stack trace releváns találatot adna, de nem látom, hogy meg lenne valósítva.
Más részről meg a jelen problémánál a driverek nem módosultak semmit, registry sem módosult, erre szintén figyel a windows. Egy adatfájl módosult, amit a driver interpretálva próbált volna futtatni. Ergo a windows-szerinti rögzített utolsó helyes konfig pontosan ugyanúgy nem tudott volna elindulni, függetlenül attól, hogy boot-start driver-e a falcon sensor vagy nem.

Sajnos ugyanez a helyzet Pöttering systemd-s Automatic Boot Assessment feature-ével, Most Pöttering nagyon elkezdte tolni és teljesen azt a benyomást próbálja kelteni, mintha ebben valami nagy okosság lenne (én meg elhittem). Végigolvasva: https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ valójában ez a windows-os last known good configuration-höz képest is kevés. Ez aztán garantáltan nem fogta volna meg a CS elcseszett channel-file-os update-jét, ha az történetesen Linuxon történik.

Régóta vágyok én, az androidok mezonkincsére már!

Ha a kernel modulok betöltése determinisztikus, akkor lehet jegyzetelni, melyiket kezdte meg, és ha siker van, akkor lehet jegyzetelni, hogy sikerült. Amikor meg belehal, akkor a követketző indítás máris látja, hogy melyik modulnál volt kezdet, de vég nem, és ha a modul egyéb paraméterei ezt engedik, akkor kihagyja a folyamatból. Így nem elvárás, hogy a pánik állapotban lévő kernel feljegyezzen bármit...

Azért ez nem egy ördöglakat, amit ne lehetne megoldani, ha akarnák.

Természetesen vannak olyan helyzetek, amikor ez sem oldja meg a problémát (pl. az általad említett sikeres betöltés után összeomló modul), de az simán megoldható szerintem, hogy ami el sem indul, azt a következő boot folyamat tudja.

Az meg, hogy egy külső gyártó kihagyhatatlannak jelöli meg a modulját, a MS kezelheti valami feltételrendszeren belül nem kötelezően. Nyilván ennél a vizsgálatnál figyelembe kell venni minden szempontot, hogy csak akkor legyen kizárva, ha tényleg működésképtelen, és ez nem egyszerű (vagy nem is állítható össze ilyen feltételrendszer).

Isten hozott a populizmus világában. Egyszerűen csak másolják, ami a politikában már alaposan kitesztelve bevált. Egyszerű hangulatkeltés, ami nem a számtekes srácnak szól, hanem Bözsi néninek, aki elhiszi a Brüsszel szabályozza az uborka görbületét is c. mesét is. Nyilván azt remélik, hogy ezzel politikailag kizsarolhatnak valami puhítást az EU-s szabályokon.

Régóta vágyok én, az androidok mezonkincsére már!

Valóban nem értem, mert én azt feszegetem, hogy egy MS és EU közötti megállapodás miért van hatással egy nem MS cég általi Linux platformra kiadott kódra?

Tegyük fel, a te céged a Crowdstrike és éppen te kódolod le az adott programrészt Linux alá.

Kész a forráskód, lefordítod, és kiadod a blobot, annak rendje és módja szerint. Oké, belekötnek, hogy nincs ott a forrás, te ezt leszarod, vagy mellékeled, ebben a tekintetben ez édesmindegy, hiszen ez a forrás rohadtul nem az lesz, ami Windowsra is forgatsz, lévén az egy kicsit más kernel.

Ergo nekiállsz (nyilván nem nulláról) az Windowsos kernelmodulnak, és amikor kész, azt is kitolod. Ez eddig végig a Crowdstrike, vagyis jelenleg a te felelősséged, például illene tesztelni, meg ilyenek.

Namost, ha a MS megállapodott a Brüsszellel, hogy puhább rendszert terít az EU -ban, attól még a MS a te modulodat beültethetné más jogosultsági szintre is, oda, ahova eleve akarta, hogy szigorúbb legyen, és teríhetné ezt a verziót mindenütt máshol, ahol messiáskánt biztonságot szeretne, mondjuk az USA -ban. De nem tette.

És fura módon, a linux kernelbe került rész is ugyanúgy nyekkentette a gépet, mert ez nem attól lesz jó-vagy rossz, hogy milyen jogosultsággal fut, hogy van-e felette még egy réteg, hanem hogy ki van tesztelve, vagy sem?

Nem tesztelték. Ennyi.

( asch v | 2024. 07. 23., k – 10:34 )

Annyiból igazuk van, hogy a "zemberek" úgy jegyzik meg ezt, hogy a Windows tönkrement frissítéstől. Ami nekik nagyon rossz marketing és nem is igaz, mert nem a Windows ment tönkre, hanem a Crowdstrike rontotta el.

Autós hasonlattal olyan mintha betennél egy kínai piacos ECU-t a Toyotádba, majd mikor tönkremegy, akkor mindenkinek elmeséled, hogy a Toyotád tönkrement garanciaidőn belül.

Mi itt szakmabéliek vagyunk, értjük, hogy miről van szó, de az átlag user számára tényleg úgy jön le, hogy a Windows szar. És ezt a kernel kinyitós dolgot tényleg az EU kényszerítette rájuk, ha ez igaz (nem elemeztem még ki magamnak), ha nem lenne EU szabályzás, akkor a Defendert kapná mindenki, ami vélhetően annyira azért ki van tesztelve, hogy mindig elindul vele a gép. Legalábbis most nem romlott el, induljunk ki abból, hogy működött volna.

Szóval Microsoft ellenzék létemre azt kell mondjam, hogy most igazuk van.

Én ezért is nem olvasom már a kapcsolódó híreket azóta, hogy lement a "nagy nap": rohadtul felbosszant, hogy magukat komolynak tartó oldalak is microsoftos hibaként hivatkoznak erre az egészre (már a cikkek címében is; gondolom, több kattintást hoz), holott pont az ő feladatuk is lenne, hogy az emberek kicsit jobban megértsék, itt kb. az MS volt a legkevésbé hibás az egész történetben, a CS és a céges policy-k kitalálói és végrehajtói annál inkább.

USA-ban miért telepíthető külső kernel modul, ha ez a lehetőség csak az EU-ban kötelező?

Ha nem telepíthető külső kernel modul az USA piacon Windows-ba, akkor hogyan hathatott ennyi amerikai cégre ez a hiba? Hogyan működik mégis a CS szoftvere olyan Windows-on, aminek nem kell megfelelnie az EU-s követelménynek, ergo nem kötelező külső kernel modult futtatnia?

"És ezt a kernel kinyitós dolgot tényleg az EU kényszerítette rájuk"

Az EU csak annyit kényszerített ki, hogy nem csinálhatnak a Defender (vagy bármi más saját termékük) számára saját titkos API-t. De még itt is voltak a szövegben gumiszabály-kivételek, hogy nem kötelező ledokumentálniuk, ha egy interfész a rendszer biztonságát veszélyeztetné.

Ha úgy döntöttek volna, hogy teljesen és egységesen bezárják a kernelt külső driverek előtt, abba az EU nem tudott volna belekötni. Persze ha ezt meglépték volna, akkor megnézem hogyan futnak a legújabb játékok a legújabb csillivilli Nvidia GTX 4090-en... szóval nem olyan egyszerű ez a döntés a MS számára sem. Csakhát kényelmes, hogy most van kire fogni...

A másik, hogy a WHQL aláírást azért egy jó ideje már megkövetelik... de valahogy az nem akadt fenn a szűrőn, hogy Crowdstrike-ék egy (nulla bemenet-ellenőrzéses) interpretert raktak bele a kernel driverükbe, ráadásul pontosan azért, hogy kijátsszák a WHQL-t.

Régóta vágyok én, az androidok mezonkincsére már!

( deje | 2024. 07. 23., k – 11:37 )

Brüsszel egy város, kíváncsi vagyok, az átlag magyar pedofidesz szavazó ezzel vajon tisztában van-e...

( m.informatikus | 2024. 07. 23., k – 11:40 )

https://hup.hu/node/185815

https://news.ycombinator.com/item?id=41033579

https://www.brendangregg.com/blog/2024-07-22/no-more-blue-fridays.html

In the future, computers will not crash due to bad software updates, even those updates that involve kernel code. In the future, these updates will push eBPF code.

For Linux systems, the company behind this outage was already in the process of adopting eBPF, which is immune to such crashes. Once Microsoft's eBPF support for Windows becomes production-ready, Windows security software can be ported to eBPF as well. These security agents will then be safe and unable to cause a Windows kernel crash.

Tisztelem Brendan Gregg munkásságát, az eBPF egy nagyon jó technológia.

Azonban tisztán emlékszem, hogy 1995-ben a Sun azzal hirdette a Java-t, hogy a garbage collector a memóriakezeléssel kapcsolatos hibákat megakadályozza, nem kell velük foglalkozni. Az azóta eltelt ~30 évben szerintem milliárd dollárban mérik a Java-t használó rendszerekben memóriakezelési hibák (és javításuk) által okozott költségeket.

( joco01 v | 2024. 07. 23., k – 11:44 )

Itt fentebb láthatóan a technikai része senkit se érdekel, ezért akkor én megkérdezem: mégis mit jelent ez? Minden más antivírus, meg minden hardver meghajtó kernel szintű, és képes BSOD-t generálni. És nem az EU rendelete óta, hanem mondjuk a 90-es évek óta.

( Friczy v | 2024. 07. 23., k – 12:13 )

"A Microsoft szerint a cégnek nem volt lehetősége blokkolni a kernelszintű hozzáférést a fejlesztők számára, mégpedig egy az Európai Bizottsággal kötött 2009-es megállapodás értelmében, mely oda vezetett, hogy a vállalatnak ugyanazt a hozzáférési szintet kell biztosítania a külső biztonsági szoftverek számára, mint amit a saját fejlesztésű megoldásoknak biztosít."

Ez alapján - ahogy a cikkben is van - ha a Microsoft is biztosított volna egy API-t, amelyet a saját fejlesztésű programja is használhat meg bármelyik másik biztonsági software, akkor a Crowdstrike nem tudta volna összeomlasztani a Windowsokat, és az EU-szabályozásnak is megfelelt volna (lásd az Apple megoldását, amelyet a cikk leírt). Szóval kár az EU-ra mutogatni.

( MaDog | 2024. 07. 23., k – 12:26 )

Romlik a HUP szinvonala.

Az Erő Legyen Veled!

Tovabbra is fenntartom, hogy ebben a formaban ez a cikk erosen bulvaros, mert nem szakmai oldalrol megnyilvanulassal van kirakva, nincs rajta vicc jelzo, ellenben privatszfera es biztonsag igen. Etc.

A meglatasom szerint ujabban tulsagosan beengeded szerintem a nem szakmai, hanem szemelyes serelmeidet, a nem szakmaval kapcsolatos vilagnezetedet a hirekbe es a kommentjeidbe is. Ami szerintem karos. Regebben is voltak, foleg almas temaban ilyenek, de kevesebb volt belole. Bar azt is karosnak tartottam. :)

Az Erő Legyen Veled!

Mert szemmel láthatóan beszopta, hogy nem a HUP-tól származik a cím, az itt csak egy idézet. De, mivel lövése nincs mi a különbség, ezért azt a HUP-nak tulajdonította.

Segítek neked (és neki is):

Amikor este az RTL Klub-on Szellő István beolvassa - mondja is, hogy idézem - "<foobar>", akkor az(t)

  • nem Szellő István híradós mondta
  • nem Szellő istván híradós állította
  • Szellő István híradós nem feltétlen ért vele egyet, csak beolvasta a történést

Vagyis, amikor a HUP-on az olvasható egy másik oldalról és szerzőtől származó idézetben, hogy a Microsoft szerint Brüsszel (piros posztó szó a ballib szemében) a hibás, akkor az(t)

  • nem a HUP mondta
  • nem a HUP állította
  • és a HUP nem feltétlen ért vele egyet, csak kitette a történést

azt hiszem, ennél világosabban nem tudtam megvilágítani, de remélem diplomás embereknek ennyi is elég lesz (de, nem biztos).

trey @ gépház

hogy nem a HUP-tól származik a cím, az itt csak egy idézet

Te biztos vagy abban, hogy mit gondol a masik?

Mellesleg meg, az idezgetes is resze a tartalomnak. Mint amikor egy onnline hirportal nagymellu nok mindenfele posztjait idezgeti, es szepen lassan szennylap lesz belole.

De ez igy jo. Ezert jarunk az online hirportalokra. Meg ide is (megjegyzem, keves a nagymellu no a cimlapon).

( Rhiannon | 2024. 07. 23., k – 13:51 )

Admirális-generális like this. Megvan az új biztonsági csúszerződés kedvezményezettje. Nagy siker ez a magyar családoknak.

izé

( ssikiss | 2024. 07. 24., sze – 08:52 )

:DDD

A jó öreg monopólium építés meg zártság téma...

Néhány napon belül ez a második (szerintem) röhejes "biznisz érdek+politikai odaszúrás" manőver (helló elon).

( laysoft v | 2024. 07. 24., sze – 09:14 )

Szerkesztve: 2024. 07. 24., sze – 12:59

🤓

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

( logan85 | 2024. 07. 24., sze – 11:45 )

Enyhén kötődik ide, de azért leírom, kiváncsi vagyok a véleményetekre.

Valószínűleg többen ismeritek a 80/20 as Pareto/Zipf törvényt, ami programozásban az, hogy a feladat 80% át az idő 20% ban meg lehet oldani.

Újabban több óriás cégnél trend volt a programozók leépítése, Szerintetek ez a bug nem az elbocsátási hullámok egyik következménye/nem lett volna megelőzhető több programozóval?

 

Az EU hülyesége már nem is meglepő...

( PDA_FAN | 2024. 07. 24., sze – 17:12 )

A Microsoft érvelése pont olyan, mintha azt mondaná valaki, hogy azért nem épített korlátot az erkélyre, mert az EU-ban nem lehet korlátozni a munkaerő szabad áramlását.