"Az AWS szolgáltatásainak leállása azt mutatja, hogy az internetfelhasználók túl kevés szolgáltató kényére-kedvére vannak bízva"

Internet, Közösségi média

Szóval, tegnap komoly leállás volt. A szakértők elkezdték az incidens kapcsán kongatni a vészharangot: 

[...]

Szakértők figyelmeztettek arra, hogy milyen veszélyekkel jár, ha a globális internet üzemeltetése néhány vállalatra támaszkodik, miután az Amazon felhőalapú számítástechnikai szolgáltatásának hibája világszerte alkalmazások és weboldalak leállását okozta.

Az érintett platformok között volt a Snapchat, a Roblox, a Signal és a Duolingo, valamint számos Amazon tulajdonában lévő vállalkozás, beleértve a fő kiskereskedelmi webhelyét és a Ring ajtócsengő céget.

A Downdetector internetkimaradásokat figyelő oldal szerint világszerte több mint 2000 vállalatot érintett a probléma. A felhasználók 8,1 millió problémát jelentettek, köztük 1,9 milliót az Egyesült Államokban, 1 milliót az Egyesült Királyságban és 418 000-et Ausztráliában.

[...]

Az Egyesült Királyságban a Lloyds bankot, valamint leányvállalatait, a Halifaxot és a Bank of Scotlandot érintette a probléma, hétfő reggel problémák adódtak a HM Revenue and Customs weboldalának elérésével is. Szintén az Egyesült Királyságban a Ring felhasználói a közösségi médiában panaszkodtak, hogy nem működnek a csengőik.

Csak az Egyesült Királyságban az egyes alkalmazásokban platformonként több tízezer probléma merült fel. A világ többi részén érintett platformok közé tartozott a Wordle, a Coinbase, a Duolingo, a Slack, a Pokémon Go, az Epic Games, a PlayStation Network és a Peloton.

[...]

Részletek itt.

( trey | 2025. 10. 21., k – 08:32 )

🍿

HUP "mindent is a felhőbe" szakértői?

trey @ gépház

Azért on-premise eléggé SPOF mentesre tervezzük az alapinfrát, pont az ilyen faszságok miatt. Említhetném az alapoktól, hogy rendundáns szerveralkatrészek, RAID, dual kontrollerek, hálózati eszközök, nem egy DC hanem több, nem egy DNS, hanem több, DHCP load balance-ban vagy failover-ben, a virtualizáció cluster-ben stb.

Számomra megdöbbentő az, ami most itt történt. Mármint, hogy egy ilyen alapszolgáltatás, amitől ennyien függenek, ennyire egy lábon álljon.

trey @ gépház

Nálunk külsős-belsős szakérők kéz a kézben frissítettek volna switcheket a HA egyik lábán. Saját bevallásuk szerint valamit benéztek és a frissítés az összes switchre futott le. 400+ VM alól rúgták ki a diszket. 3. nap végén már egész sok VM lett visszahozva mentésből... Szerencsére több cluster is van így "csak" az egyiket sikerült elszurni.

Human error. Mindent el lehet baszni, ha kellően nagy az igyekezet. Ami itt volt, az nem human error volt, hanem tervezési hiba / spórolás.

Lefordítom üzemeltetés nyelvre:

Az AWS esetén a fontos szerverben redundáns tápegység helyett egy szem táp volt. Ha redundáns lett volna és egy balfasz kitépte volna azt egyiket menet közben, semmi sem történt volna. Sajnos itt az egy szemet tépte ki valami balfasz.

trey @ gépház

Én is imádom amikor spórólnak: pl., ha egy portos FC kártyákkal üzemeltetnek szervereket (jó lesz az alapon!) és kevesebb FC switch port kell hozzá(az még főnyeremény). És ilyenkor utálják az IBM Storagekat amik ezt nagyon nem díjazzák, ergő dupla annyit kell venni belőle belőlük. Spólóltak is meg nem is.

Egy adott cég szempontjából ez igaz, de a társadaloméból nem. A homogén rendszerek az élet minden területén életveszélyesek.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Az egyik kliensen volt valami DNS feloldási hiba egy újonnan telepített nyomtatónál (amit egy ipcinfig /flushdns megoldott volna), ehelyett az észlény fogta és átírta a GPO-ban a default domain policyban a primary dns suffix-et mert szerinte az volt a hiba(ettől a jogtól hamar meg lett fosztva), pár percen belül már másoknál is volt dns feloldási hiba…

( Nyizsa v | 2025. 10. 21., k – 08:41 )

Ennyire népszerű az az eszement forgatókönyv, hogy valaki becsönget, ez az esemény szépen elmegy Kaliforniába, onnan pedig visszajön, hogy ding-dong?

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Akkor jól értettem, ezek szerint megnyomom az "IoT csengőgombot" valakinél és az elmegy AWS-be, hogy az ajtón belül megszólaljon az "IoT csengő"?! :O

Azért ez már tényleg beteg így!

Proton:
https://pr.tn/ref/HBNPNCFFG8N0

"Bithang-Yoo Rádió, az élvezet, ami a Zenéhez elvezet!"

https://bithang-yoo-radio.com

Ha már okos otthon, akkor nagyobb a bizalmam az on-premise "Home Assistant" féle megoldások felé.

Ergo, ha nincs pénzem az ehhez szükséges és ezzel kompatibilis perifériákra, akkor inkább lemondok róla! :)

Proton:
https://pr.tn/ref/HBNPNCFFG8N0

"Bithang-Yoo Rádió, az élvezet, ami a Zenéhez elvezet!"

https://bithang-yoo-radio.com

Hát pont ilyen gondolkodás után lett HA nálam. Amúgy használhatóságban és képességekben nem sokat tudok hasonlót. Konkrétan egyet, de az meg horror árral jön.

Az okos otthon (és nagyobb méretben az intelligens épület) tipikusan nem felhőbe való. Max a backup vagy a failover.

A világ szoftvereinek túlnyomó többsége nem egymillió usernek van szánva, hanem jó esetben max párszáznak, mivel belső céges szoftver, jól definiált felhasználói körnek. Nem kell mindenre cloud meg nem kell mindenre georedundáns működés.

Jo, igen. De ebben a szalban az a tema, hogy miert kell akarmilyen tavoli (cloud/on-prem) management az IoT eszkozhoz, miert nem eleg a lokalis vezerles.

Egyebkent az LG termekek tenyleg AWS fele forgalmaznak. Gondolom az benne a racio, hogy olyan sok termekuk van mar kint ugyfeleknel, hogy erdemes regiokban kezelni oket, annyi DC-t pedig nem akarnak fenntartani. Meg hat van ilyen managed szolgaltatas, egyszerubb hasznalni, mint nullarol lefejleszteni.

miert kell akarmilyen tavoli (cloud/on-prem) management az IoT eszkozhoz, miert nem eleg a lokalis vezerles.

Mert mondjuk a munkahelyről akarom hazainduláskor megmondani, hogy na, akkor elkezdheted felfűteni/lehűteni a lakást az elvárt hőmérsékletre. Vagy távolról akarom megnézni, hogy tényleg lekapcsoltam-e minden lámpát, és ha nem, akkor le tudjam kapcsolni. Vagy távolról ránézni arra, hogy a garázskapu szenzora bejelzett, akkor mi is történt ott. Sokféle használati esete van annak, hogy működjön a távelérés.

 És itt jön közbe az, hogy ezt egy egységsugarú, IT-hoz nem értő usernek is kell tudnia. Nem megoldás az, hogy azt mondod, hogy figyi, legyen egy otthoni szervered Home Assistanttal, meg egy VPS-es, amin fut egy VPN szoftvert és azon keresztül eléred. Még ha IT-s is vagy, ehhez sok ember lusta már, egész egyszerűen nem akar ilyen szinten foglalkozni vele. Adsz neki áramot és menjen, kész.

Ez nem otthoni használat, inkább kereskedelmi.

Otthonra akár egy ilyen is jó lehet, akár egy külön rpi-vel. Tetszőleges módon lehet kezelni, akár napszaktól függő hangerő is beállítható, vagy e-mailben értesítés, bármi. Felhő nélkül.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Erre én azt mondom, hogy vagy rászánom az időt és erőforrást és megoldom VPN+VPS megoldással, esetleg VPN+dyndns-en keresztül (bár CGNAT-nál ez nem opció), vagy maradok a lokális használatnál. (bár pl. a redőnyt, légkondicionálót elérem felhőn is, akkor is, ha nem akarom, mert ilyen az alapműködése, ahhoz kéne plusz energia, hogy letiltsam a gyártóhoz kapcsolódást). Jelenleg a lokális használatnál tartok, bár mivel túlnyomórészt itthon vagyok, ez nem is gond.

Nagyon helyes. Amennyiben a szüleidnek igénye van arra, hogy pl. a munkahelyen hazaindulás előtt interaktívan feljebb vehessék a fűtés hőmérsékletét, akkor valóban ez a követendő megoldás. Ha erre nincs igény, akkor sem árt, ha másért nem, edukációs szempontból.

van, aki időmilliomos és hónapokig építgetheti az otthoni szuper rendszerét és emellett még pénz sem sajnál, hogy saját vpn szervert üzemeltessen valahol egy szerverhotelben, hogy azon át be tudjon jutni az otthoni hálózatába távolról, mivel nincs publikus befelé irányú kapcsolat a netszolgáltatón át.

Más meg kifizeti az 50 dolcsit és használja a telefonjával. Őket hívják ügyfeleknek.

Csak azt magyarázza meg már nekem valaki, hogy a kettő miért zárja ki egymást...

Nem egy cég jutott nagyon messzire azzal, hogy mindkét megoldást támogatta, és valahol ez volt a sikere egyik fő kulcsa. A local API igazából nem kér enni, csak legyen, minimális plusz funkcionalitást kell csak fejleszteni, hiszen a dolog oroszlánrésze a cloudos vezérlés miatt már megvalósul. Csak le kellene másolni a Shellyt, Philips HUE-t, vagy bármely hasonlót, de egyszerűen nem éreznek rá, vagy sokkal nagyobb a félelem attól, hogy ezzel elveszik a teljes kontroll.

Másrészt ne felejtsük el, hogy van egy másik piac is, az pedig a független integrátoroké, telepítőcégeké. Ők azok akik Gipsz Jakabnak megoldják az egészet, ha fizet érte, így Jakabnak nem kell értenie semmihez, csak használja a kész megoldásokat. Ezek a gyártók erről a piacról is kiírják magukat a cloud only megoldásaikkal.

Mit lehet csinalni, ha vki mondjuk CGNAT-olt halozatot kap az ISP-tol? Talan vmi specko VPN-t (Tailwind?) kiepit, amibe belep az IoT eszkoz es a mobil app is. De annak is kell legyen vmi kozponti managementje, ami le tud allni. Plusz nem ingyenes.

Ez valid probléma, de a cloudot lehetne korrektül is használni és nem mindent IS abban intézni.

pl hogy a mobilapp haza találjon, de az automatizmusnak nem ott (lenne) a helye.

Lásd: a HA esetében a Nabucasa megoldását, vagy a Homey-t (asszem, azt nem teljesen ismerem). Mellesleg ez a CGNAT-ot is megoldja.

ez oké, de otthoni szervert is meg kell venni, üzemeltetni kell, elromolhat. A csupa felhősnél meg ha eléri a netet, akkor működik. Az, hogy évente van pár óra vagy max 1 nap, amikor nem működik, az jóóóval kisebb macera, mint millió külön rendszert üzemeltetni. És költséghatékonyabb is a központosítás.

Értem, hogy privacy probléma és függőség a hátránya. Csak két fillérből átlagembernek ez ilyen.

( Friczy v | 2025. 10. 21., k – 08:46 )

Ezek szerint délutánra helyreállt, mert a Duolingo nekem működött.

( joco01 v | 2025. 10. 21., k – 09:22 )

Csak tisztában kellene lenni a failure domainekkel. Ha jól olvastam, csak egy zónával volt baj, tehát aki redundánsan többet használ, az túlélhette gond nélkül.

Teljes us-east-1-et érintette, tehát egy egész régió volt, nemcsak egy AZ.

Az autentikációjuk is köhögött nap közben és az minden régióra közösen us-east-1-ből megy. Általában retry megoldotta, de ez lehetett volna sokkal rosszabb.

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

Docker Hubot, meg Maven Centralt illik tükrözni, mert nem nagyon szeretik azt, hogy mindig mindent tőlük töltesz le újra és újra, Docker Hubon van is rate limiting.

Főleg az imagek esetén nincs értelme újra és újra letölteni, egy adott verzió az nem fog megváltozni már. És alap, hogy latest taget nem használunk.

Security szempontbol kivanatos az `imagePullPolicy: Always`, aminek az a kovetkezmenye, hogy a image registrynek mindig elerhetonek kell lennie. Persze, lemirrorozhatjuk vhova, de akkor meg az lesz a SPOF.
Ha nem ezrevel futtatunk Podokat, akkor a Docker Hub rate limitje nem szokott zavaro lenni. Plusz elo lehet oda fizetni es akkor nincs rate limit.

Security szempontbol kivanatos az `imagePullPolicy: Always`

Miért is? Normális esetben fix az, hogy pontosan melyik imaget használod (és nem meta tageket). Ahol igazán fontos az, hogy csak jóváhagyott image települhet/indulhat,  ott amúgy is SHA hash-sel hivatkozol az image-kre.

Ugyebár az a dolog, hogy "csak ellenőrzött, jóváhagyott image futhat" security szempontból ellentmond a "mindig legyen a legfrisebb, abban biztos be van foltozva a biztonsági rés" nézetnek.

Nem is értem, hogy az 'imagePullPolicy: Always'-nek fejlesztői környezeten kívül hol van értelme, pont egy ilyen pull policy hozhat be nem kívánt biztonsági rést, mert eszetlenül lehúzod az újabb image-t.

Ahogy szokták mondani, az új verzió és a régi között az a különbség, hogy az újban több az imeretlen hiba.

Szeritnem felreerted, az `imagePullPolicy: Always` nem arrol szol, hogy mindig a legfrissebbet huzod le (ami valtozik). Hanem arrol, hogy a container runtime engine minden alkalommal rakerdezzen a hivatalos registrynel, hogy mi is a checksum, nehogy vki a local docker cache-ben kicserelje az image-et egy malicsuszra azonos taggel. Legalabbis en igy tudom, hogy ez az ertelme.

Az egy relative uj feature, hogy az image tag utan be lehet irni az sha256 checksumot is, korabban csak a tag volt.

> nehogy vki a local docker cache-ben kicserelje az image-et egy malicsuszra azonos taggel.

Hozzáfér bárki is a local docker cache-hez kontroll nélkül?

Meg nem is csak a latest tagre gondolok, hanem arra, hogy ha mondjuk ilyen taged van, hogy eclipse-temurin:21-jre-jammy, akkor ez időben változhat, mert a 21-jre-jammy az egy meta tag, időben előrehaladva több image is ezzel a taggel fut. Ilyen és ehhez hasonló esetben az imagePullPolicy: always eredményezheti azt, hogy olyan image települ, amit te nem akartál.

zero trust security concept :)

Persze, arra is "jo", de nem az a fo celja szeritnem, hanem amit leirtam fentebb.

Tobb cloud audit tool pampog, ha nem Always-on van.

Lasd: https://www.fairwinds.com/blog/kubernetes-devops-tip-5-why-setting-imag…

Tobb cloud audit tool pampog, ha nem Always-on van.

Ezek a toolok akkor érnek valamit, ha mondjuk egyben ellenőrzik is, hogy nem meta tageket használsz vagy latestet. Mert akkor az Always szigorúan ellenjavalt.

Pont ez a példa: 

For example, many projects will release version 1.2.3 with the image tags 1, 1.2, and 1.2.3.  With regards to Kubernetes configuration, it is possible to specify tag 1.2, so when 1.2.4 is released with a security patch, it automatically flows in the next time that pod is rescheduled or restarted. However, if imagePullPolicy: Always is not specified by the user, the Kubernetes cluster will continue to use the cached 1.2 tag, which still points to 1.2.3. 

 

Nem biztos, hogy az a jó, hogy 1.2 vagy 1 van megadva tagnek, én mindig konkrét verziót adok meg, amikor definiálom a használandó image-t. Ha belső image, akkor főként. Ugyanis az nem mindig garantált, hogy az a.b.c esetén a c változtatása csak visszafelé nem kompatibilis bugjavítást jelent, nem mindenhol használják jól a semvert, sem upstream projektekben, sem esetleg saját projektekben.

 

na meg ez a mondat: "You can avoid problems with images by ensuring imagePullPolicy is set to Always. " Bullshit, ugyanúgy problémákat is okozhat, pont a fentiek miatt, amikor is a specifikált image az igazából időben változó image-t jelent.

De ha vki megis vmiert valtozo image-re hivatkozik (tudom-tudom ellenjavallt, de ha megis), akkor is jobb az Always, mert akkor kevesbe all elo az a helyzet, hogy egy helm upgrade utan az egyik node-on regi cache-elt image-bol fut a Pod, mig egy masik Pod mar frisset futtat (mert azon a node-on korabban nem futott, igy le kellett toltenie az aktualisat).

Ha jol ertem, akkor az Always garantalja, hogy egy Deploymenten belul biztos hogy azonos image legyen minden Pod.

Egy secu scanner tool nem tudja ellenorizni, hogy egy image tag-et overwrite-olnak-e idonkent. Mondjuk ECR-ben beallithato, hogy immutable legyen egy tag.

Amit mondasz csak abban az esetben igaz ha külső image-ről van szó.

Belső, cégen belül készült image-ek esetén normális meta tag (pl. "stable") használata, mivel tudod mi van az image-ben, le van tesztelve, stb.

Nem kell semmit átírni gitben, nem változik helm value tehát nincs forced rollout, szépen organikusan kimegy az új image.

Ephemeral, de közben mégis immutable deploymentekhez tökéletes megoldás.
Jó példa erre ha mondjuk nagy tételben futtatsz self-hosted github runnereket K8S-ben. Ha hozzányúlsz a value-hoz akkor a K8S leállítja az összes futó runneredet is rolloutkor, nem számít hogy éppen egy build közepén vannak, és egy nagy cégnél nem fogsz találni quiet periodot. Floating tag + imagePullPolicy: Always használatával már meg is oldódott a probléma.

A security teamnél meg úgy mondják hogy a régi és az új verzió között az a különbség hogy a régit ha továbbra is használod akkor előbb-utóbb valagba leszel rúgva :D

( KoGa v | 2025. 10. 21., k – 09:38 )

Igen, a felhős infra hátránya. Ezt kb. az első témába vágó órán tanítják, valakit meglepett?

Ismerve a laikusok vélekedését és képzeleteit a csoda "felhőről", szerintem egy csomóan most rácsodálkoztak. Arra is rá szoktak, amikor éppen idézem nekik egyik-másik felhős szolgáltató SLA-ját, hogy az csak 99,5%, vagyis 43 óra 48 perc is lehet akár egyhuzamban egy évben kötbér vagy egyéb nélkül. Aztán csak megy a pillázás ... 🤷‍♂️

trey @ gépház

Microsoft Online szolgáltatások - Exchange Online stb. - jóváírásai:

Százalékos Rendelkezésre Állás

Szolgáltatás-jóváírás

< 99,99%

10%

< 99%

25%

< 95%

100%

Ez nekem nem azt jelenti, hogy az üzemeltető maga nagyon bízna akárcsak a 99%-ban is. Ja, a jóváírás a havi díj említett százaléka. 

trey @ gépház

( XMI | 2025. 10. 21., k – 09:56 )

A timeline egyébként nagyjából az volt, hogy:

- először "DNS hiba" (legalábbis ezt mondták, "it's always the DNS")

- aztán DynamoDB

- aztán nem lehet új EC2 instance-ot indítani - ez amúgy lehet hogy már következmény volt a korábbi API hibák miatti healthcheck failure hatására sok ügyfélnél végtelenciklusban elkezdhettek terminálni/újra létrejönni a gépek (ASG ilyet alapból tud)

- és végül (mikor az előzők látszólag megjavultak) jött egy nagy Cloudwatch kiesés

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

( mavericko | 2025. 10. 21., k – 10:02 )

Ezt már máshol is kifejtették, de a fő probléma az, hogy az us-east-1 nem egy "sima" régió, hanem gyakorlatilag a fő régió, ahová az AWS rengeteg core szolgáltatása is be van huzalozva, így amikor az kiesett, az mindent is vitt magával, autentikációtól kezdve egy csomó core szolgáltatáson át, régiótól függetlenül. Ha valakinek csak mezei ec2 instance-ai voltak más régiókban, és semmi egyéb szolgáltatást nem használ (még DynamoDB-t sem), az valószínűleg nem érezte meg, mindenki más igen.  

( prion | 2025. 10. 21., k – 10:45 )

És akkor érintőlegesen EU USA függés is bejön, amiről másik témánál volt szó. Nyilván off kicsit, de azért gondolom ez is felvillan ilyenkor az érintett cégek tulajdonosainak fejében.

( bra | 2025. 10. 21., k – 11:30 )

Kíváncsi vagyok, hogy az idei reinventre készülnek-e egy "sorry, ezt csesztük el, és ezt tesszük, hogy többet ne legyen ilyen" vészelőadásra. :)

Kizárt dolog. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( andris05 | 2025. 10. 21., k – 11:55 )

A szél szétfújja a felhőt, a tulaj meg nem tud bemenni a saját lakásába... :-)))

( gyuri23 | 2025. 10. 21., k – 12:16 )

Azon gondolom senki nem agyal, hogy néhány orosz kinzsal és nincs nyugat. Nem is kell mást szétlőni, mert a katonáink nem tudnak kijönni a laktanyából, mert nem nyílik az ajtó.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( nagyjoco | 2025. 10. 21., k – 13:10 )

Egy jó kis ChatGPT kiesés lesz még a buli. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

A kirúgott és éájra cserélt embereknek sem. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Nekem sokkal inkább az elbasztam a business oldalt, de most jó mentség a mese arról, hogy AI-ra cserltem az embereket tipusú mesélésnek tűnik, amihez túl öreg vagyok, hogy elhiggyem.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( nagyjoco | 2025. 10. 21., k – 13:10 )

Szerkesztve: 2025. 10. 21., k – 13:10

-dupla-

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( YleGreg | 2025. 10. 23., cs – 11:11 )

Ha már ennyire köztudottá vált, hogy a felhő az mekkora Single Point of Failure, akkor jó lenne észrevenni azt a tényt, hogy Föld bolygó redundanciája is elég siralmas, és éppen most tesszük tönkre azt a példányt, ami minket futtat. Vajon egy AI mennyivel jobb döntéseket hozna nálunk?

( azbest | 2025. 10. 23., cs – 16:36 )

Szerkesztve: 2025. 10. 23., cs – 16:37

hmm 8 milliárd emberből csak pár milliót érintett? Cégek millióiból csak 2 ezret? Akkor ez semmi.