Mennyire kellene felelősnek lennie a szoftverfejlesztőknek, a fejlesztő cégneknek a produktumukért?

Szoftver

Apropó:

A 2024. július 19-i Crowdstrike incidens miatt rengeteg cég IT-ja borult meg. Ez közvetett és közvetlen károkat is okozott minden szektorban (közlekedés, állam, bankok, EÜ stb.). Az IT egyre jobban beépült mindenki életébe. Megkerülhetetlen. Ezért a szoftverek és működésük mindenkire hatással van - csecsemő, nyugdíjas is. A mai szoftverek minőségét semmi nem biztosítja, garantálja. Úgy kapnak plecsniket, hogy azok legfeljebb elméletben, papíron felelnek csak meg. Több gyártónál is előfordul, hogy csak n-1 vagy n-2 verziójú szoftver rendelkezik plecsnivel.

Azok a verziók meg már nem támogatottak (EOL/EOS).

Lásd például: CC EAL minősítési rendszer hiányosságai.

Maradjon a status quo (EULA felelősség kizárás), jó ez így ...
14% (103 szavazat)
A fejlesztő / cég (soha) nem lehet felelős.
1% (10 szavazat)
Mindig más a felelős a hibákért (Microsoft, 3rd party, gyíkemberek, napszél stb.).
12% (91 szavazat)
A fejlesztő / cég teljes felelősséggel tartozik, legyen végre szabályozva a szoftverek minősége!
62% (469 szavazat)
Csak az eredmény érdekel / Nem használok szoftvereket / Nem érintenek a szoftverhibák
11% (85 szavazat)
Összes szavazat: 758

( snq- | 2024. 07. 24., sze – 15:29 )

a "közlekedés, állam, bankok, EÜ" it-ja teszteletlenül szar ki élesbe szoftvereket? ez a produktumuk?

a kedves vásárló vásároljon olyant, amihez elérhető "teszt jegyzőkönyv", ha ilyenre van igénye

a "közlekedés, állam, bankok, EÜ" it-ja pedig ne szarjon ki teszteletlenül élesbe szoftvereket, se "teszt jegyzőkönyvvel", se anélkül

A piac most is képes lenne jobb minőségű termékeket előállítani, de nem™ éri™ meg™ neki, mert túl milliárdosak hozzá a multik a kínálati oldalon. Ez a jogszabályok szempontjából annyit jelent, hogy túl hosszú pórázon van tartva a törvények által. Ilyen esetekben a pórázt kell rövidíteni és a piac megoldja a többit. A silány minőségű, etikátlan szolgáltatásokat (vagy ahogy OP fogalmazott: a kuruzslókat) kell kiszórni a rendszerből és máris lesz helye és kereslete a minőségi munkának. Egy kicsit sírnak-rínak az extraprofitkájuk után, néhány hónappal később meg már azzal reklámozzák magukat, amit a törvény elvár tőlük. Így működnek.

Szerinted, ha lenne színvonalas és hatékony egészségügyi rendszerünk, el tudott volna terjedni a homeopátia, az oltásellenesség, a fényevés, meg az összes ilyen áltudományos szirszar?

Hát, amikor a számlázó progit muszáj frissíteni azonnal, mert holnap életbe lép egy NAV vagy törvényi változás (azért mostanában volt ilyen kedd éjszaka megjelent közlöny szerda reggeli hatályba lépéssel és/vagy a fejlesztők meg az utolsó utáni pillanatig húzzák a módosítás kiadását), akkor ott nem nagyon lehet staging környezetben tesztelgetni...

Sajnos a KKV szinten az egyik legnagyobb ganajdombok a one-man-show fejlesztésű számlázó és ügyviteli rendszerek (a drágák jó része is).

Tényleg, ilyen kedd 23:59-es bejelentés, szerda 0:00 érvénybelépős agyfaszokat a hazai könyvelő-szakma meg a programjaikat írók hogy kezelik le?  Csak tudjàk már előtte pár héttel h. lesz ilyen v. olyan dolgot érintő módosítás.

Azt senki ne mondja nekem h. a hazai könyvelőszoftvert programozó emberek soha nem feküdhetnek le éjfél után 1 percig, h. tuti ne jöjjön ki aznaptól hatályos lófasz, ha meg igen akkor éjféltől induló sprintben programoznak hajnal 6-7ig.

Részben tévedsz sajnos. A helyzet rosszabb.

Itt a HUP-on is van pár fejlesztő, akik tudnának mesélni, hogy mekkora orbitális káosz is van az ilyen fejlesztéseknél. Ritka mázli, amikor hetekkel korábban tudják, hogy mit és hogyan kellene lefejleszteni - pl: NAV sémamódosítás.
No meg hiába a törvény. Ha a végrehajtási rendelet hatályba lépés előtt 1-2 nappal jön ki, akkor néha tervezhetik újra a módosítást.

a kedves vásárló vásároljon olyant, amihez elérhető "teszt jegyzőkönyv", ha ilyenre van igénye

és ha nincs ilyen?

és ha lenne ilyen, de ahhoz a törvénynek elő kéne írnia?

Tipikusan az a gondolkodási csapda, hogy az olcsóbb áru szarabb minőségű és kevesebb rá a garancia, ígyhát feljogosítva érzi magát az olcsó szart gyártó multi, hogy bekussoltassa a termékét kritizálókat (dehát "olcsóbb", dehát "ingyen van" stb.). Na, az ilyen piaci magatartást kell elsők között kiirtani a rendszerből és máris mindenki jobb minőséget fog gyártani és nem pazarolja el a Föld és az egész gazdaság erőforrásait szar-húgy termékek gyártására.

( pepelopez | 2024. 07. 24., sze – 15:33 )

bugos hardvereken, bugos szoftverek, ez már csak ilyen lesz :))

Ne terelj, kezd zavaro lenni, hogy szandekosan nem azt akarod hallani, amit mondani akarunk. Mikozben ugy tunik, egyetertesz, csak "pontatlanul"(?) fogalmazunk. :)

Amirol beszelunk, az fontosabb, mint egy nyelvforditasi reszletkerdes.

Kb. mintha annyit kifogasolnal, hogy:

-mernokurak
+babzsakfejlesztok

nem tudsz minden cpu-t 1 evig tesztelni a gyarban. vagy kiszurod, hogy szar, eloxalt a QC-n, vagy nem. ez vezet hosszabb tavon a degradacio fele: eszkalalodik az eloxacio, elkezd "lefolyni"/"leszakadni" a vezeto a helyerol terheles alatt, aka: elektromigracio.
most ugy tunik nem sikerult.
en ezt mondom. te meg a forditason lovagolsz. :)

Ha egy ilyet valóban nehéz™ tesztelni, azt a QC-nak ugyanúgy figyelembe kell vennie a tervezési fázisban. Tudod, akkor, amikor a fősodratú mérnök urak épp úgy döntenek, hogy kispúrkodják a minőségi alapanyagot a processzorból, mert úgy 5 Ft-tal olcsóbban legyártanak egy lapkát, amit aztán eladnak százezrekért, az olcsó kínai szar alapanyag meg (hát ki gondolta volna) hamarabb oxidálódik. A QC-nak az lett volna a feladata, hogy a lompos bozontos helyett a szélsőségesen idealista, fősodratú mérnök urak asztalát (vagy fejüket a falba) verje addig, amíg el nem felejtik hatalmasabbnál™ hatalmasabb™, de annál tarthatatlanabb innovációjukat™.

mrie gondolsz? idezzem be az egesz wikipedia article-t vagy tartsak arrol altalanos iskolai kemiaorat, hogy a rez leszarja melyik orszagbol jott, akkor is ossze fog boronalodni az oxigennel? :D
kosz, nem. meghagyom nektek a hazi feladatot. ha nem gond. :)
a vitakultura ott baszodott el, hogy valaki kinai foshugyszarozik... :) annak ellenere, hogy helyes iranyba allitottam merre kell elinduljon, ha a temakorben informalodna.

Nem, az üzlet azt mondja hogy legyen olcsóbb. A mérnök pedig megoldja, hogy az adott termék olcsóbb legyen. A mérnök követelményeknek megfelelően tervez/épít terméket (legyen az egy cipő, ház, vagy szoftver). A döntése teljesen rendben van, mert teljesíti az üzleti követelményeket. Az, hogy neked ez személy szerint nem tetszik, nos, egyéni probléma. Válassz másik terméket. 

Te most kivel vagy?

Kicsit olyan stilusu ez a hozzaszolas, mintha minden vasarlot/fogyasztot gyoker parasztnak tekintenel, aki megerdemelte az "uzletember altali nyomas alatt levo mernok" "nemhibajat". Sot, a vasarlonak tudnia kellett volna azt, amit a fizetett soktagu QC nem deritett ki.

Borzaszto hozzaallast tukroz a hozzaszolasod, es a problema resze vagy. Az ilyenek miatt, mint te, nagy monopol cegek barmit megtehetnek a tobbsegunkkel.

Oké, próbálom elmagyarázni. A mérnök nem magában dolgozik, és nem azt csinál amit szeretne, hanem adott követelményeknek megfelelő rendszert épít. Ezen követelmények jöhetnek az üzlettől (ügyfél igények és a cég igényeinek valamilyen halmaza), valamilyen szabványból, szabályozásból, és még ezer más helyről. A mérnök pedig előjön egy- de inkább több - olyan megoldással amely lefedi ezeket a követelményeket. Ezek utána meg lesznek vitatva, és majd végül létrejön egy termék. A mérnök semmilyen hibát nem csinál és nem is gondolom hogy hibáztatni kellene bármiért, ő ellátja a feladatát, az adott kereten belül hoz egy megoldást.

Te, mint fogyasztó, pedig eldöntheted, hogy számodra az adott megoldás megfelelő-e, vagy nem. Ha nem, akkor dönthetsz hogy el tudsz-e engedni a saját követelményeidből, vagy mégis ki akarod őket elégíteni, és ezért mondjuk inkább a konkurrencia termékét választod, vagy esetleg saját termék fejlesztésbe fogsz, és csinálsz egy olyat, ami kielégíti a te igényeidet.

A mérnöknek nem feladata a TE személyes igényeidet és elvárásaidat kielégíteni, ugyanis nem te fizeted neki a bért. Majd ha ez megváltozik, akkor lehet verni az asztalt. 

( gelei v | 2024. 07. 24., sze – 15:34 )

En aszerint vizsgalnam a kerdest, hogy meddig van a vendornak befolyasa a kornyezetre. Nalunk van olyan termek, ami (fizikai) appliance formajaban erkezik, bele kell dugni 1 db tapot meg 1 db ethernetet, es kesz van. Meg van olyan, hogy itt az .msi, csinalj vele, amit akarsz. Most akkor a szabalyozas melyiket vegye inkabb figyelembe?

Aztán a fizikai appliance-re (legyen az router, switch, tűzfal, bármi) jön hetente/havonta az upgrade, és természetesen a gyárilag benne lévő sw-re már EOS van. Többnyire ez a realitás, attól, hogy fizikai appliance van, még ugyanúgy sw van benne. Az egyetlen különbség, hogy a gyártó jobban ismeri a hardware-t.

Hehe. Az egyik 'appliance' típus, amivel dolgoztam, tele volt mindenféle valami rpm-ekkel, de legalább ősrégi kernel futott alatta :D Ebből a szempontból még kevésbé bíztam benne, mert egy így-úgy kiherélt redhat futott alatta, csak épp hozzágányolták a saját cuccukat, valamint csináltak egy rossz értelemben redundáns (értsd: több azonos adat itt-ott, amit jó esetben konzisztensen volt képes módosítani a rendszer, rossz esetben nem feltétlenül), így a legváltozatosabb hibát képes produkálni.

Tény: így legalább nem hivatkozhattak arra, hogy a sw jó, csak a hw hibázik :)

Mindkettő produktum. Nyilván egy appliance sokkal jobban kezelhető gyártói oldalról is (életciklus menedzsment).
.msi-ért is lehet ám felelősséget vállalni - többek között legyen hozzá normális telepítési leírás, előkövetelmény ellenőrzés, frissítés stb.

Nem ilyen szempontbol fontos, hanem hogy az egyiknel a teljes szoftveres kornyezet a tied, a firmware-tol az OS-en es drivereken at a userlanding, a masiknal meg feltelepited valahova, amihez esetleg a gyarto ad egy listat, amibe bele van irva, hogy szigoruan csak RHEL 8.x, de ezen felul senki nem mondja meg, hogy pl. a bugos hulladek kernel modulod valami masik bugos hulladekkal ossze fog-e akadni, vagy sem. :)

( gelei v | 2024. 07. 24., sze – 15:39 )

Több gyártónál is előfordul, hogy csak n-1 vagy n-2 verziójú szoftver rendelkezik plecsnivel.

Ja, de mondjuk egy EAL4 az also hangon masfel, de inkabb 2 ev, es a userek baromi nagy reszenek (beleertve govt es enterprise is) nincsen ra szuksege, meg csak megkozelitoleg sem, akkor meg mar adja magat a kerdes, hogy miert ne legyen kozben uj release annak a 99,99%-nak, akinek jo lesz EAL cert nelkul is :)

Dolgoztam SAM modulon, ahhoz hogy átnyomjuk egy CC auditon elképesztő mennyiségű munkát kellett berakni úgy, hogy volt szamárvezető (protection profile), domain tudás, és egyébként is már modell alapon fejlesztettünk (full traceability a követelményekhez). Ez valójában egy kis modul volt, messze egyszerűbb mint akár egy webshop.

Csináltam CC EAL auditot - igaz, hogy csak 2+ szintűt. Igen, iszonyatos munkát bele kellett tenni - 1-1,5 évünk ráment a cégnél. Onnantól fogva drasztikusan javult a szoftver megbízhatósága, kezelhetősége, karbantartottsága. A kódzárás után 1 héttel ment a fejvakarás, mert a fejlesztők újabb feature-t akartak belepréselni + 1-2 hibát javítani az auditált verzióban.

És igen, szükség lenne az átgondoltságra, a tervezésre, a jó minőségű munkára. Nem csak összehányni a biteket ("jó lesz az úúúúgy....").

Egyetertek, de az ugyfelek nagy reszenek az a plusz koltseg (es ido!), ami nem eladhato. Neki kell egy feature tegnapra. Meg van a masik ugyfel (ezek vannak sokkal kevesebben), akiknek meg inkabb az audit szamit, es ezert van regi es uj verzio parhuzamosan, utobbi plecsni nelkul.

( _Franko_ v | 2024. 07. 24., sze – 15:40 )

A kérdés az, hogy ki fogja megfizetni mindezt és mitől lesz jobb, ha teljes felelősségvállalást írunk elő.

Másrészt a fő probléma az volt, hogy a change nem volt tesztelve. Végtelen sok cégnek van papíron tesztrendszere és most kiderült, hogy csak papírmasé, patyomkin, pipa egy rublikában vagy egy vonás az audit folyamatban, de nincs érdemben használva, ha kimegy change az élesbe tesztelés nélkül.

https://iotguru.cloud

Ai által kreált black box jellegű kreálmányoknál még kritikusabb lesz. Szerintem tényleg elkön az, hogy tesztekkel kell specifikálni.

 

Amúgy nekem néha olyan érzésem, hogy olyan szinten vannak összdrótozva a dolgok, annyira egymásra épülnek, hogy folyamatos karbantartás nélkül már nem működne semmi, mert folyamatosan utána kell húzni valamit, mert valami más megváltozik. és mindenbe egyre több okos funkció kerül, sokszor teljesen feleslegesen. Valahogy az van, hogy a marketingnek kell a sok csilli villi és ez győz azzal szemben, hogy válasszuk a legegyszerúbb, legkevesebb karbantartást igényelő megoldást. valahol kész csoda, hogy csak néha vannak nagyobb gondok.

Igen, ettől drágábbak lennének a szoftverek, lelassulna a fejlődés. Egyben a versenyt is javítaná véleményem szerint hosszú távon.

A jelenleg elszenvedett károkat ki fizeti ki? Mert nehogy azt hidd, hogy az ügyfelek, az ügyfelek alkalmazottai (pl: Mancika) nem szívnak XY szoftver miatt. Csak sajnos én még nem találkoztam olyan kutatással, ami ezt feldolgozná - mennyibe is kerül egy hibás szoftver munkaidőben, stresszben, energiában stb.

A stressz, energia, egyéb random humán-faktort leszarja minden cég. Azért kapja a dógozó a munkabérét minden hónap 10.-ig, h. cserébe kitapossák a belét is. Ha beledöglik, nem kár érte, majd találnak a helyére másik hülyét a munkaerő-piacon. Az ember feláldozható, az igényei pedig leszarandók.

1. A hatékonyságot is lehet mérni, igaz, hogy nehezen. Ha a bugos szoftver miatt mondjuk 10 %-kal csökken a hatékonyság, akkor az versenyhátrány és árfelhajtó tényező. Ennek árát pedig valakik kifizetik - nem, nem csak a munkavállalók.

2. Másik embert addig lehet találni, amíg
- van szabad ember a piacon
- nem járatta le magát a cég annyira, hogy senki ne akarjon hozzájuk menni dolgozni (egyre több ilyen céggel találkozom)

ki fogja megfizetni mindezt

A multi, aki eddig elspúrkodta, meg az önző, mohó, jachtos-golfos befektetőcskék, akik irreális növekedést akartak és nyomást gyakoroltak, hogy a multi spúrkodjon.

Másrészt a fő probléma az volt, hogy a change nem volt tesztelve.

Mert a multi elspúrkodta.

Végtelen sok cégnek van papíron tesztrendszere és most kiderült, hogy csak papírmasé, patyomkin, pipa egy rublikában vagy egy vonás az audit folyamatban, de nincs érdemben használva, ha kimegy change az élesbe tesztelés nélkül.

Ha van felelősségvállalás, a multi kénytelen olyan tesztrendszert üzemeltetni, ami nem csak papíron létezik.

( carlcolt | 2024. 07. 24., sze – 15:49 )

Szerkesztve: 2024. 07. 24., sze – 15:53

Egyeb: az osszes valaszlehetoseg hibas.

Jelenleg tul konnyu szoftverfejlesztokent kovetkezmenyeket meguszni (altalaban), de amilyen iranyba ment mas teruleteken a "szabalyozas", inkabb maradjon igy.

Remalmaim kozt szerepel egy szoftverfejlesztoi kamara es tagsaghoz kotott munkakorok fogalma. Remelem sose valosul meg, pedig akar jol is jarhatnek vele.

Hagyjuk meg a szoftverfejlesztest zavarosban halaszos szabadabb szakmanak: ahol meg kell fizetni, hogy a szoftverfejleszto nem (jo esetben csak) szerzoi jogot sorozatosan serto projekteket uzemeltet inkabb a konnyen hozzaferheto torvenyes munka helyett.

Amugy reszben letezik megoldas: ha olyan a munkakor, hogy nem eleg jo, hogy munkavallalo vallal erte felelosseget, akit nagyobb hibak eseten is jobban vedi a munka torvenykonyve, szerzodj dupla akkora napidijert contractorral, es az majd bearazza a mas jellegu felelossegvallalast. Akar a csapata neveben, es onnantol a "munkavallaloi jogok serthetetlensege" is az o problemaja es az o kockazata.

( heckles04 v | 2024. 07. 24., sze – 15:50 )

Szerződésbe kellene bele foglalni, hogy a gyártó miért és meddig vállal felelősséget.

 

IT oldalról ha valamit tesztelés nélkül ki küldök és kiderül, hogy hibát okoz akkor az az én saram.

Normál esetben ezért kéne backup illetve lehetőség a relatíve gyors roll back-re.

 

Viszont ha kiad a cég kiad egy hibás SW-t és az mondjuk javíthatatlan hibát okoz. Pl hardware hiba az az ő hibájuk.

 

Itt lehet elővenni mondjuk a szerződést :)

Nem, de lehetne.

Ez már meg is van. Benne van az összes szoftver felhasználói feltételében, amiz a felhasználó elfogad vagy írásban (nagyobb rendszerek), vagy automatikusan a szoftver használatba vételével, hogy abszolute semmilyen felelősséget nem vállal egy fejlesztő sem a szoftver működéséért és az esetleges okozott kárárt.

Ezért merik megcsinálni, hogy teszteletlen verziókat adnak ki. Így nekik nincs dolgik a teszteléssel, a felhasználónál majd kideül, jó-e, és ha nem jó, az a fejlesztőre nézve semmilyen következménnyel nem jár. Még csak a hiba javítást sem kell semmilyen határidővel vállalnia. És, mivel az összes így működik, nagyon nincs is kire váltani a felhasználónak, hogy jobb legyen a helyzete.

azert tegyuk ossze a ket kezunket, ha en feldobok a githubra egy 3 soros bash scriptet, azt egy nagyvallalat elkezdi hasznalni es valami gebasz miatt kimarad az rm -rf /$DELETE_THIS-bol a parameter, hozzam ne jojjon senki, hogy bukott 1234 mrd USD-t, es teritsem szepen meg neki :D
ugyanez igaz a paraszt uti F8-ra mondjuk egy *commander eseten.
felkeszul: az rm prancsot implementalo emberke :) lehet lennenek almatlan ejszakai :D

Nem, semmiképp sem a mirror. Illetve nem mondtam azt sem, hogy a CE egy az egyben ráhúzható lenne a szoftverre, de természetesen vannak elemei, amik ráhúzhatók lennének.

Ahogy egy CE-nek is többféle módon lehet megfelelni (ez mondjuk termékkategróiánként eltér), úgy ezt itt is be lehet bevezetni.

Pl. ahogy vannak előírások elektronikus eszközökre, gyerekjátékokra, nyomástartó edényekre, mérőeszközökre, ugyanúgy be lehetne vezetni egy "kritikus szoftver" kategóriát.

Én akkor tartanám kritikusnak, ha:

1) olyan helyen használják, ahol a hiba végzetes, mint kritikus infrastruktúra, járművek vezérlőrendszerei, bank, stb.

2) az elterjedtsége miatt kritikus (pl. windows).

Ezeknél már megkövetelhető egyfajta minőségbiztosítás.

Ha open source komponenst használ, nincs azzal baj, csak akkor tessék végigvinni ugyanazon a validáción, mint amin amúgy a saját megoldását is.

 

Az beb*szna, ha a hobbiból fejlesztett open source szoftver fejlesztőit kezdenék el cseszegetni.

Nyilván a hibrid open source megoldásokkal más a helyzet, ahol gyakorlatilag pénzért árulják, de adják a forráskódot is. Ugye ezekkel már kötsz szerződést, ő rajta már valamit le is lehetne verni.
 

( the_manni | 2024. 07. 24., sze – 16:02 )

Nyilván valamelyest a cégnek, aki szállítja a szoftvert, annak is a felelőssége kéne legyen, de annak sokkal jobban, aki a kritikus infrastruktúrát üzemelteti, és mégsem próbálja ki a frissítést tesztkörnyezetben mielőtt élesben kimegy.

A legtöbb gyártó semmilyen iránymutatást nem ad, hogy a produktumát hogyan lehetne és kellene tesztelni. Se kézileg, se automatikusan. Én 2024-ben - a Kubernetes, CI/CD, konténerizáció, devops évében - elvárnám, hogy a gyártó adjon egy rendes tesztrendszert az ügyfélnek (leírással, doksival, image-ekkel akár), amin ő is le tudja futtatni a gyártó által adott és customizált tesztjeit is. Tudom, bilibe lóg a kezem....

( nagyjoco | 2024. 07. 24., sze – 16:23 )

Oké, mondhatjuk, hogy a szoftver fejlesztője  kizárólagos felelős. De ha mondjuk egy third party lib okozta a hibát, akkor mi van? és ez csak egy viszonylag könnyen végiggondolható abból a számos szcenárióból, ami felmerülhet és jópár eset nem is egyszerűen felvázolható. Mit kezdünk azzal, ha a Copilot vagy Davin írta a rossz kódot? 

A világ komplexitásának kezeléséhez  komplex szabályozásra van szükség, a komplex szabályozás meg ellentmondásokat szül és innen nincs egyszerű kiút, talán semmilyen kiút nincsen.

( Caro | 2024. 07. 24., sze – 16:31 )

Nem kellene feltalálni a spanyolviaszt.

Megint jövök trey kedvencével, a mérnöki területtel: van felelős tervező. Igen, ő felelős, ő írhat alá. Annak megvannak a feltételei, hogy ki válhat ilyenné.

Nem ő készíti feltétlenül az összes tervet természetesen.

Persze nem minden terület követel meg felelős tervezőt, pl. én a magam hardverfejlesztői területemen ilyen nem létezik.

 

Aztán vannak olyan területek, ahol így egyéni felelősség nincs, de van komoly minőségbiztosítás meg eljárásrend, pl. a biztonságkritikus termékek fejlesztése. De ott sem egyéni felelősség van a fejlesztő részéről. Hanem az a mondás, ha az eljárás be van tartva, akkor ott a biztonságot úgy véljük hogy megüti az előírt szintet. Ettől persze még lehet benne hiba, de ha a cég meg tudja mutatni, hogy ő pedig a processz szerint járt el, akkor nem támadható.

( dorsy v | 2024. 07. 24., sze – 16:37 )

Szerkesztve: 2024. 07. 24., sze – 16:47

Erre szokas normalis helyeken ugynevezett biztositast kotni.
Mind a SW-t hasznalo ceg, mind a SW-t krealo ceg eseten.

Ha a biztosito vegre "forintositja" pl. a disaster recovery plan meg a business continuity plan "josagat" es "sebesseget", akkor egybol nem az lesz, hogy az uzemeltetes egy hetig 0-24 kezimunkazik egy egyszeru visszaallitast.
A toketlensege vagy a vezetes "jolvanazugy" mentalitasa miatt, vegeredmeny szempontjabol kb. lenyegtelen.
Az nem erv, hogy azt mondogatjuk, hogy "nem keszultunk kekhalalra". Ne legyunk mar a magyar kozutkezelo, akit minden telen varatlanul er a hideg es a ho meg, hogy katyu keletkezik az uton ami nem volt TMK-zva...

Hiba van/volt/lesz. Nem az a kerdes lesz-e, hanem mikor.

Erre szokas normalis helyeken ugynevezett biztositast kotni.

Szerintem nincs az a biztosító, aki a Windows kockázataira biztosítást kínálna és ha lenne, nem lenne felhasználó, aki annak a díját meg akarná fizetni. 

A minősítő az másik káposzta. A minősítőnek kellene legyen felelősségbiztosítása. Ha a minősítők ténylegesen felelnének a pecsétjeikért, a Microsoft lehúzhatná a rolót, az Apple és a FOSS meg bepótolná a helyét a piacon, viszonylag rövid idő alatt. Sok Windowsos mérnöknek át kellene képeznie magát open-source üzemeltetőnek. Lehet, hogy szebb világ lenne és mindenki jól járna.

Te egyébként csináltál már ilyen minősítést? Egy ilyen minősítés arról szól, hogy egy adott cég egy adott szabványnak megfelel, mind a szabványban megszabott, termékkel kapcsolatos követelmények, mind annak létrehozása/dokumentálása tekintetében (folyamat + configuration management). A termék fejlesztő oldaláról az a feladatod, hogy elegendő bizonyítékot szolgáltass az auditor cég felé, hogy az nagy valószínűséggel meg tudjon győződni arról, hogy rendben vagy-e. 

És ezt tanúsitja egy auditor cég. Nem azt, hogy a termék hibamentes, hogy abban nem mehet tönkre soha semmi, örök élet, ingyen sör....

Ha a norma úgy konzisztens, hogy megengedi, hogy kernel módban futassanak a rendszereden mindenféle kódokat, akkor az a norma rossz. De szerintem ilyesmiről nincsen szó, a minősítő feladata lenne, hogy az ilyesmit norma eltérésként értékelje, de baszik rá, mert a Windows ugye "biztonságos".

Még mindig nem erről szól egy tanúsítás. Értem, hogy mit szeretnél - nagyobb biztonságot - csak akkor magasabb EAL tanúsítással rendelkező megoldást kell választani, és kifizetni ennek a költségét:

  • EAL1: Functionally Tested.
  • EAL2: Structurally Tested.
  • EAL3: Methodically Tested and Checked.
  • EAL4: Methodically Designed, Tested and Reviewed.
  • EAL5: Semiformally Designed and Tested.
  • EAL6: Semiformally Verified Design and Tested.
  • EAL7: Formally Verified Design and Tested.

Ha EAL7-es szintre auditálták volna, akkor a hiba nem jöhetett volna elő. Elvileg annó tanultunk ilyen szinten auditálandó rendszerekről, de ezek nevében általában szerepelt az atom szó.

Egyébként én úgy állnék neki a témának, hogy fognám a kernelben futó részt, azt annyira leminimalizálnám amennyire csak lehet funkciók tekintetében, és teljesen újratervezném már egy magasabb EAL szintű auditra készülve. Meg valószínűleg nem C-ben, vagy hasonló alacsony szintű nyelven kódolnám le. 

Oké, a gyártói oldalon egy ilyen minősítés elképzelhető, hogy megfogta volna a hibát, de ha felhasználói oldalon akarod ilyen szinten auditlni a rendszeredet, az talán más helyzet. Én nem hiszem, hogy felhasználói oldalon ez a Crowdstrike / Windows Update for Business megoldás megbukhatna akármilyen szintű auditáláson, mert akkor az a Windowst kizárná arról a piacról, ahol most tarol. Olyan minősítési rendszert pedig nem nagyon tudok elképzelni, amelyik ilyet lépne - de lehet, hogy tévedek.

Felhasználói oldalon te mondod meg hogy mi az a biztonsági és megbízhatósági szint amit meg akarsz ugrani, és ehhez megfelelően választasz beszállítókat, és rakod össze a rendszeredet. Ez a te (mint megrendelő) feladatod és felelősséged. 

Az, hogy azok a cégek, akik ezt a csodát használták, single point of failure-t hoztak létre, nos, ez egyes egyedül az ő felelősségük volt. Biztosítani kellett volna hogy ezek az update-ek belső tesztelés nélkül ne futhassanak le, sőt, akár párhuzamosan használhattak volt párhuzamosan több különböző rendszert is, biztosítva, hogy ha az egyikkel gebasz van, akkor a másik működésbe lép. Ha ezt megcsináljuk redundáns hálózatok esetén, akkor valójában mindenre is meg lehet, a kérdés, hogy ezt kifizetik-e, vagy azt mondja a cég, hogy olcsóbb helyt állni a károkért az ügyfelek irányába, mert ez olcsóbb, mint a plusz rendszerek összerakása, működtetése, stb.

Ott még kicsit lehet turkálni, hogy mit ajánl/vállal a szállító/integrátor az update-k végrehajtásával és az SLA-val kapcsolatban és ehhez képest mi volt, tehát a szakmai felelősséget lehet/kell? megosztottan vizsgálni. De igen, végül a pénz dönt szerintem is.

Igy van, nagy megbízhatóságú rendszert csak párhuzamossággal lehet építeni. Hogy ebből a Crowdstrike-nak mit kell fizetnie, az jó kérdés, illetve az is, hogy kimásznak-e a gödörből. Szerintem itt az járt jól aki szolgáltatásként használt Crowdstrike érintett rendszert és az update miatt bukott az SLA.

Szerintem ilyen nincs, egyszerűen azért mert annyira drága egy formális módon történő tervezés és audit hogy ezt senki nem fogja bevállalni. Látszik is hogy nagyjából diódákat meg hasonlókat auditáltak erre a szintre.

Egy EAL4-et esetleg meg lehetne ugrani, de ehhez is át kell alakítani az egész fejlesztési folyamatot.
 

meg arra is van biztositas, hogy egy balfasz beled hajt az autojaval. :)

navarj, hol olvastad, hogy egy kernel [insert any open source SW here] hiba miatti leallas/adatvesztes eseten en elballaghatok Linus urhoz [insert any opensource developer here] es kompenzacioert kopogtathatok?

itt arrol beszelgetunk, hogy hiba van/volt/lesz. opensourceban is. hardverben is. nem a kod nyiltsaga fog megmenteni egy ceget ha beut a sz*r, hanem a HA meg a DR.

hardverhiba eseten se szaladhatsz oda a diszk/memoria/cpu/alaplap gyartojahoz, hogy "jaj, elveszett", pofanrohog es azt fogja kerdezni, "hol volt a backup?" :)

es ez meg csak az IT resz, ennel sokkal tobb dolog tud felremenni egy ceg eleteben. :) amire ha nem keszultel, beszophatod. (eleg ha egy beszallitod leall es nincs mas helyette, megall a transzport, barmi...)

Igen, ebben egyetértek, CASCO biztosítás van. De miből gondolod, hogy arra biztosítást lehet kötni, hogy te megveszel egy programot, ami kernel módban turkál a gépeden és elkúrja a rendszeredet? Ez szerintem egyfajta vagyonbiztosítás kellene legyen, amit nem tartok valószinűnek, hogy létezik.

Abban is egyetértünk, hogy hiba létezik, de az a megrögzött és szilárd véleményem, hogy ez nyílt forráskodú szoftver és átgondolt bevezetés estén valamivel alacsonyabb kockázatot jelent az IT számára, mint egy Windows Update for Business-re bízni az egész rendszeredet.

megrögzött és szilárd véleményem > ott a pont, annyit is er.
feltettem a kerdest, hogy szerinted vallal-e az openszosz kommjuniti vagy a projectek lead-je barmilyen (vagy tobb/kevessebb, mint egy fizetos, zart SW vagy HW eseten) anyagi felelosseget (netan supportot) a munkaja irant. csak valaszt nem kaptam ra :)

en tenyek alapjan formalok velemenyt. ahhoz pedig ezt a fenti kerdest kell(ene) tisztazni :)

Hát szerintem itt az ideje hogy tedd tisztába a tisztáznivalókat. A nyílt forráskódú szoftverek esetében az alkalmazás teljes felelőssége a felhasználón van, ez nagyjából nyilvánvaló. A Microsoft szoftverei esetében pedig ezzel szemben teljes egészében a felhasználó felel mindenért. Ez lényeges különbség.

tehat az alacsonyabb kockazat marad velemeny. mivel alatamasztani - a hiteden kivul - semmivel nem tudod. szivesen. :)
ez egy lenyeges kulonbseg :)
ha lattal volna messzirol mukodo windows alapu rendszereket (en is csak kb. a partvonalrol, de azert latok), akkor nem mondanal olyan ordas baromsagokat, minthogy "egy Windows Update for Business-re bízni az egész rendszeredet" :D

Egyelőre a kockázatról nem volt szó, a felelősséget kérdezted. A kockázat nem a felelősség miatt csökken vagy nő. Nyílt forráskód esetén megismerheted, hogy az az alkalmazás, amiről szó van, mit csinál, hogyan működik, zárt forráskód esetén - mint látjuk - csak azt ismerheted meg, hogy mit kellene csinálnia. Szerinted melyiknél nagyobb a kockázat?

amelyiknel vegigauditaltad (auditaltattad) es letesztelted (leteszteltetted) a rendszered osszes komponenset. hardverrel egyutt.

ha azt szeretned mondani, hogy amikor berakod a debian netinstall-t, akkor vegignyalazod az osszes kodot, magad, kezzel, ujraforgatsz mindent, majd ha ezzel megvoltal es nezel egy md5sumot a binarisokra es az is rendben van, akkor - persze - van elonye az open source-nak is. kezdd a kernellel, az csupan par millio sor.

Előbb felelősségről, aztán kockázatról pöszétünk. Itt arról van szó, hogy az elvi lehetősége megvan, hogy a nyílt forráskódú szoftvereket alkalmazás előtt megvizsgáld, de általában ezt a community elvégzi helyetted. A dolog lényegéhez tartozik, hogy nyílt forráskód esetén a szakmai munka a felhasználó oldalára kerül az implementáció során. Nem olyan nagyonbonyolult ez, persze az ehhez értő munkavállalót meg is kell tudni fizetni, mert az alacsonyabb kockázatnak is ára van. A múltkor megszámoltuk, nálunk több tucat ilyen szoftver működik, némelyik évtizedek óta. A tapasztalat az, hogy azért egy Debiannál, Proxmoxnál, OpenZFS-nél nem kell nagyon nagy meglepetésekre számítani. Ezzel szmeben, hogy egy Windows frissítés után mi történik, arról lila fingod sincsen előre, korábban kikapcsoltuk ezt a feature-t, aztán eldobtuk a Windowsokat, mert semmi hasznuk nincs. 

es ez pont az, amire semmilyen metrikat nem tudsz mutatni :) epp az az altalanositas, hogy majd a manyeyeballs megoldja. nem, nem oldja meg, ha epp nem a bug fele nez. vagy kommitolni sincs joga a projectbe. vagy nincs olyan HW/SW stackje, mint eppen neked, stb...

"Debiannál, Proxmoxnál, OpenZFS-nél nem kell nagyon nagy meglepetésekre számítani"
https://security-tracker.debian.org/tracker/data/json
https://bugzilla.proxmox.com/buglist.cgi?chfield=%5BBug%20creation%5D&c…
https://github.com/openzfs/zfs/issues

hat persze :)

ha ugy mukodne, ahogy mondod - "nem nagyon kell semmire szamitani" - nem lenne open bug open source szoftverben. foleg nem remote CVE-k evekig, olyan szoftverben ami a linux szerverek 99.999%-an fut. :)

amikor meg kiderul, hogy vannak, akkor megy ugyanaz az uzemelteto macis "jajveszeklo futkosas", mint a kladsztrajknal.
metrikusan szolva 1:1...

onnan jottunk, hogy "Hiba van/volt/lesz. Nem az a kerdes lesz-e, hanem mikor." tokmindegy, h open, closed, gpl, C, java, php. altathatod magad, mert te a debianban hiszel, es, hogy teged megment a meniajbolsz, csak mivegre :)

Apró kiegészítés, hogy nem azt írtam hogy semmire sem kell számítani a Debiannál, hanem azt hogy nagy meglepetések nem igazán érik ott az üzemeltetőt. Szó nincs hibamentességről, üzemeltetési biztonságról van szó. Ebben a Debian kifejezetten jó választás. 

Egyébként te hány Debian szervert üzemeltetsz a cégnél? Te láttál már Debian okú jajveszékelő futkosást, amiről írsz? Mesélj, érdekel. Szeretek tanulni.

SSL Debian bug. Bar ott sem futkostak ennyire, azert eleg sok egyeb rendszert is erintett. ld. Meister tortenete

szerk: ettol egyetertek, a Debian tenyleg korrektul kezeli ezeket a frissiteseket

A strange game. The only winning move is not to play. How about a nice game of chess?

nem futkostunk, fel voltunk keszulve. :) ssh szinte sehol nincs publikban, amit a kollega is, en is irtunk, insta fixaltuk. szazas nagysagrend.
ha publik ssh-k lettek volna, lett volna futkosas! nem a meniajbolsz meg a debilany miatt nem volt! :)

ezt irtad szo szerint: "nem kell nagyon nagy meglepetésekre számítani". azert a mellekelt abra es a cve/buglista es a sajat tapasztalatok sem ezt tamasztjak ala... te is olyan vagy, mint az egyszeri autos, aki csodalkozva konstatalja, hogy "hat, de eddig nem volt semmi baja!" :D jah, a dolgok igy szoktak elromlani, hogy elotte jok voltak.

ezt irtad szo szerint: "nem kell nagyon nagy meglepetésekre számítani"

Úgy van. Ezt illusztráltad is szépen a listáiddal. Arról szó nem volt, hogy minden tökéletes és soha nem romlik el semmi. Ha így lenne, felkopna az állatok és mehetnétek mind kapálni....  ;^)) Szerencsére ettől nem kell tartani, de a Debian üzembiztonsága, nem utolsó sorban a nyílt forráskódja miatt, jól közelit egy elméleti optimumhoz. Szeirntem mindenesetre jobban közelít, mint bármilyen más zárt kódú megoldás.

Abban egyetértünk, hogy ettől még sok minden más is szükséges a biztonsághoz.

nem kozelit jobban. semmivel nem tudtad eddig ezt igazolni, es a peldak sem ezt mutatjak. hinni hihetsz a meniajbolszban meg a debianban tovabbra is... viszont a velemey meg a hit meg jezust se tudta megmenteni a kereszttol. de legalabb neki volt backup planje es feltamadt :)
a debian ugyanannyira (nem) vallal semmit, mint barki mas. mondhatjuk vegulis - a szavaiddal elve - elmeleti optimumnak is :D

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Ahhoz kell jajveszékelve odafutkosni a frissítés kedvéért ám...

;-)

erről jut eszembe, nekünk van még kinn üzemben 2003-ban kitett Debian, fsprotect-tel, nagy dicsőségére a vasnak, amin ma is fut, hibátlanul. Sose kellett frissíteni jajveszékelve. Mondjuk mára már nincs üzemben, de elérhető, működik csak senkinek sem volt kedve hozzá, hogy begyűjtse.

Félreértettél valamit, nem vindóz van a gépen, hanem Debian, RO filerendszeren, áramszünetre immunisan. Éppenséggel lehetett volna frissíteni is, ha kellett volna.

Van a windózos képzettségnek azért egy olyan mágiája is, hogy a számítástechnika és a security update szorosan összenőttek egymással.

attol fugg, hogy a jajveszekelo futkosas a normal frissitesi folyamat resze-e. :)

ha igen, akkor minden rendben, ha nem, akkor az oszlop tetejen levo gepbe csak akkor tennek ki frissitest, ha a laborban legalabb ujraindult frissites utan, meg be is lehet lepni, ha ilyen is van rajta.

neked aztan fura humorod van...

3-2-1, meg high availability... nem (annyira) bonyi dolgok ezek, csak be kene tartani. :) es nem lesporolni. jahogy draga... hat igen, minden ujabb 9-es egy rendelkezesre allas eseten, egy nagysagrenddel meg tudja novelni a koltsegeket. ez ilyen.

Elvárom, hogy bizonyos szektorokban ezek ne csak elvárt dolgok legyenek, hanem legyenek ki is kényszerítve. Elfogadhatatlannak tartom, hogy ezek a fogalmak tudatosan nincsenek beépülve a vállalati IT-ba.
Sajnos találkoztam olyan CTO-val is, akiknek a fenti fogalmak semmit sem mondtak. Ez a szomorú helyzet. :(

CxO: "Igen, tudunk róla, hogy ezek vannak. De mi még az 1970-es évek szerint működünk. A saját bónuszunk fontosabb."

ugyanmar, ennel sokkal durvabb SPOF-ek vannak, es IT sem kell hozza:
viz? villany? gaz? kaja? :)
ma mar nem tudsz odasetalni a sarki furt ivovizkuthoz merni egy kis vizet, ha a kozponti rendszert eppen elkaszalta valamelyik jo kepessegu felujito brigad... ebbe fogsz eloszor beledogleni (ha addigra nem fagytal meg) :)
csak, hogy ilyen eletbenmaradashoz valamivel fontosabb dolgokrol is megemlekezzunk, minthogy "kesett a repulom a nyaralasra" meg "nem megy a feszbuk" :D

( zdesigner | 2024. 07. 24., sze – 16:39 )

Még több bürokráciát a világnak! 🙂

Egyik oldalról annak tűnik, de mit szólnál hozzá, ha mindennapos lenne hogy valaki áramütést kap, mert a gyártó nem tartotta be a szabványokat, és nem megfelelő szigetelést használt?

Vagy amikor telefonálsz, elsötétedne a monitorod, mert megzavarta?

És ezek ellen nekünk küzdenünk kell, meg rengeteg tesztet, elemzést elvégezni, hogy ezeket kizárjuk. De ezeknek megvan az eredménye. És MINDIG derül ki valami, pedig nem zöldfülűek tervezik, de az első prototípusból mégsem nem lesz soha sem termék.

Nyilván vannak területek, ahol nem szükséges. Szoftvernél sem kell mindenhol. De azért a kritikus infrastruktúrában én elvárnám.

Mit értesz kritikus infrastruktúra alatt? Itt a nagy hajcihőben a legnagyobb problémát amit hallottam, hogy emberek repteteken ragadtak meg nem tudták nyaralni menni. Jah volt ahol megállt a termelés is. (Ott azért IMHO az IT ezt megérdemelte - van aki a saját kárán tanul...) 

Akkor nekik is csak gratulálni tudok. Ott sem csak a CrowdStrike a hunyó. Amúgy ilyenről is csak elszigetelt eseteket írtak...

Én ilyesmire gondoltam: https://net.jogtar.hu/jogszabaly?docid=a1200166.tv

 

Szerk: https://hu.m.wikipedia.org/wiki/L%C3%A9tfontoss%C3%A1g%C3%BA_Magyar_V%C3%A1llalatok_Biztons%C3%A1g%C3%A1%C3%A9rt_Felel%C5%91s_Akci%C3%B3csoport

tthon a légkondikkal küzdöttek.

Jaja. Külföldön nem hibásodik meg légkondi.

BTW: hallottunk 3 esetről, volt sipárgás, de arról nem, hogy

  • az ország összes kórházának összes klímájából hány százalékot tett ki ez a 2-3 felfújt ügy?
  • mi okozta a hibát, volt-e tervszerűen karbantartva az a meghibásodott klíma?
  • ki volt a felelős
    • TMK vezető
      • megtörtént-e a nyári szezon előtt a kritikus eszközök azonosítása
      • rendelkeztek-e tartalákalkatrésszel
      • volt-e azonnali javítást biztosító szerződésük
    • CFO
      • a kórház időben betervezte-e a régi klímák cseréjét a TMK vezető által jelzett szükséges dolgokra való pénzkeret elhatárolást

Kérlek, nem 47 fokban kell pingvinezni, ha megáll egy klíma, hanem már márciusban (legkésőbb) neki kell állni felmérni, javítani, felkészíteni, sajtóban sipárogni, hogy nincs rá pénz (lett) ....

Az adott kórház vezetése a hibás abban, hogy nem volt működő klíma. Akárcsak a CrowdStrike-nál. Ott is az volt a hibás, amelyik beszerezte, üzemeltette, nem tesztelte ....

trey @ gépház

Ahogy a végén írod is. Ugyanezeket/hasonló a kérdéseket felteheted a CrowdStrike Falcon esetében is.

Amúgy ilyenekt írtak: https://sg.news.yahoo.com/medical-appointments-surgeries-axed-u-173806109.html?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAACVbo3yMY35gf7vkO8yynsLkmJjELHLYkCArx9VpJuUHKVdRNm2DMlZS9F16X2PsmNWtWoHeucJGN-S2lBYoGwIqUXfOF5vJ680an3_7e8EYS1rcwrQngmyPr4bn-TPyFuDGn0OkWzzOrTFtZxDA2jZrIg-LBikbH6BT4ZUHkkQ8

Many hospitals and medical centers appeared to be operating as usual or recovering after earlier disruptions.

Meg: https://www.washingtonpost.com/business/2024/07/19/crowdstrike-microsoft-windows-outage-travel-impact/

A Providence spokesperson later said fewer hospitals were impacted than originally thought, and the elective procedures will be rescheduled.

Lehet meghibásodik ott is légkondi, csak nem kell sírni a sajtónak, hogy legyen rá pénz...

Ha az üzemeltetés nem írt a feletteseinek időben vagy a felettesei nem kértek pénzt időben a fenntartóktól, akkor ki a hibás? Szeretnéd ha megkeresném a leveleim dátumát, amik kimentek a gondnokság felé az éves szerverterem klímakarbantartásra és a pénzügy/cégvezetés felé, hogy tervezzék be a cserét?

Ha lerohad, kire fog szerinted majd rárohadni az ügy?

Tudtak egyáltalán róla, hogy extra pénz kell rá?

Megannyi kérdés.

Kérdezem még egyszer: akkor kell sírni, amikor már megdöglött 47 fokban, vagy már tavasszal elébe kellett volna menni a problémának? Mérnöki választ várok, nem politikait.

trey @ gépház

Csak idéznék: https://telex.hu/belfold/2024/07/22/korhazak-klima-kanikula-mutetek-korterem-felujitas-hutes-egeszsegugy

Rásky László, az Orvostechnikai Szövetség főtitkára elmondta, hogy bár a klímák nem közvetlenül hozzájuk tartoznak, a most látható jelenség őket is érinti. Felidézte, a Közbeszerzési és Ellátási Főigazgatóság (KEF) tavalyi létrehozása előtt az volt a jellemző, hogy mikor valami elromlott, akkor a kórház főigazgatója megkereste a szervizt, tehát ő intézkedhetett.

A KEF alá tartozó kórházakban ez a jogosultság már nincs meg, szinte minden esetben a Főigazgatóságot kell értesíteni. „Ez nemcsak a bürokrácia általános időigénye miatt hosszabb, hanem azért is, mert a KEF-nek ezekre többnyire közbeszerzést kell kiírni.”

A főtitkár elmondta, hogy még a KEF dolgozóit is meglepte, milyen állapotok uralkodnak egyes egészségügyi intézményekben. Ez szerinte visszavezethető oda, hogy

a legutóbbi nagygépbeszerzések a kórházakban lassan 10 éve voltak.

A mostani állapotok egyik oka, hogy nincs országos koncepció például a nagyobb gépek beszerzésére, de a klímákra sem. Másrészt pedig nincs rá pénz sem, az amortizáció nincs is beépítve az egészségügyi intézmények finanszírozásába.

És a helyzet rendezésére kinek kéne vernie az asztalt? Nem a kórházak vezetőinek? Ja de ... ahogy nekem is nekem kell, ha nem akarok éjjel azzal szopni, hogy 70 fok van a szervekek körül.

Külónbség: én elvégzem a feladatom

Bocs: én időben elvégzem a feladatom

trey @ gépház

Hol:

  1. Te kaptál pénzt - ezt te írtad. Gondolom pénz nélkül nem oldódott meg nálatok sem a karbantartás/csere.
  2. Ők nem - ezt tényleg feltételezés. Azon alapszik, ha kaptak volna nem mentek volna tönkre a légkondik több helyen is. (~rendszerszintű a probléma nem egy-egy igazgató problémája)
  3. Most megnyílik a pénzcsap - benne van a telex cikkben. Hirtelen került pénz a javításokra.

Kásler meg odamondja a tutit: https://telex.hu/belfold/2024/07/25/kasler-miklos-korhazi-klima-mutet

30 éve én 50 fokos műtőkben végeztem 10 órás műtéteket

A klímahiszti betette a lábát 😉

Hoozzászoktak a jóhoz mi? A 30 évvel ezelőtti állapotok mennyire jogosak mint hivatkozási alap?

 

Van arra is hivatkozás:

A Magyar Kórházszövetség öt évvel ezelőtti felmérése is azt mutatta, hogy kevés klíma van a kórházakban, és a meglévő rendszerek is jelentős mértékben elavultak, elhasználódottak. „Egyes kórházfelújításokat úgy kellene kezdeni, hogy jön egy csapat buldózer” – mondta a kórházak állapotáról Svéd Tamás.

 

Még statisztika is van: https://ec.europa.eu/eurostat/en/web/products-eurostat-news/w/ddn-20231127-1

Az egészségügyre fordított források tekintetében Magyarország a sereghajtók között kullog: a 24 országból a legkevesebbet Bulgáriában költik, ők a GDP 4,2 százalékát fordítják egészségügyre, Írország 4,6-ot, Magyarország és Litvánia pedig 4,7-et.

 

Mondjuk kezdjük egy Káslenrenk adott frappáns válasszal: https://24.hu/belfold/2024/07/25/kasler-miklos-kulja-andras-valaszt-50-fokban-operalni-mutet/

Nem az a kérdés, hogy lehet-e 50 fokban operálni, hanem, hogy túléli-e a beteg

Én '83-ban voltam utoljára műtöben, de kórházban és magánrendelésen sajna idén is.

Székesfehérváron a belgyógy traumatológián áldatlan állapotok voltak. Diagnózis után a fertőzőre tudott volna felvenni a doki de nagyon nem ajánlotta. Jártam már azon a fertőző osztályon. Omladozó épület, szintenként a sok fertőző betegnek két közös WC - egy női egy ffi.

Idéznék: http://www.fmkorhaz.hu/osztaly/Infektol%c3%b3giai_Oszt%c3%a1ly (3 megyét látnak el innen)

Osztályunk a kórház „U” jelzésű épületében található, mely 1932-ben épült, műemlék jellegű.

A fertőző, majd infektológia  osztály 1950 óta ebben az épületben kap helyet. (még 2024-ben is!!!)

u.i.: elmentem magánba ahol profin kiderítették mi a bajom: nem fertőzés.

Mondjuk kezdjük egy Káslenrenk adott frappáns válasszal: https://24.hu/belfold/2024/07/25/kasler-miklos-kulja-andras-valaszt-50-fokban-operalni-mutet/

Tereléssel.

Én '83-ban voltam utoljára műtöben, de kórházban és magánrendelésen sajna idén is.

Akkor tudod, hogy kb. klíma nem volt, zöld csempe, '56-ban még használt műtőságy, meg szovjet, horpadt alumínium üstlámpa volt a plafonon.

Amikor meg 10+ éve voltam az államiban, már akkor hipermodern műtőkben jártam (munkaügyben is, beöltözve és betegként is) ...

Sok a duma. Ahol meg régi szar kórház van, ott át kell menni egy másikba, ad absurdum egy másik város kórházába. Nem az elsőbe, ami útba esik.

trey @ gépház

Jaja mozogjon a beteg, attól jobban lesz, meg szívesen is fogadják máshol. :D Ekkora demagógiát.

A kórházi halálozási arány mutat egy "szép" bizonyítványt (tragikus) trendet. Az okok nyilván komplexek, de nem előre megyünk - az látszik.

https://www.ksh.hu/stadat_files/ege/hu/ege0018.html

Jaja mozogjon a beteg

Mert én mi a faszt csinálok? Amelyik nem akar, az vessen magára. Nyugodtan sírjon folyót, hogy neki a saját érdekében épp úgy tennie kellene valamit, mint másnak.

Mi lesz a következő? Menjen házhoz a sebész, nem?

Vagy minden szarfészekben építsenek szuperkórházakat közpénzen! Minden tanyára CT-t meg MR-t!

trey @ gépház

Olyanról még nem hallottál, hogy akkora gondban volt valaki, hogy utaztatás közben halt meg?

Tudom, hogy nem lehet ideálisat csinálni, meg a megoldást se tudom, csak próbáltam utalni arra, hogy amit leírtál annál embereknek lehet nagyobb problémája is és mutattam egy életbevágó ;) statisztikát, ami szerint nem jobb a helyzet. (Sőt összehasonlításban is szar, de nem akarok újabb flame-t nyitni.)

Azt hogy előre megyünk, hogyan tudod megítélni, ha nem jártál 2010 óta állami kórházban műtéten?

Illetve miért kellett magánt választanod, ha 2010 óta előrébb járunk? Ha 2010 előtt jó volt az állami, és azóta előrébb léptünk, most mi szükséged volt magánra?

Szarok a kérdések.

'89-től biztosan folyamatos a fejlődés, magam ellenőriztem. Ott vannak az évszámok a mintavételezésre.

Illetve miért kellett magánt választanod,

Mert megtehetem.

Ha 2010 előtt jó volt az állami, és azóta előrébb léptünk, most mi szükséged volt magánra?

Mert 4 csillagos szálloda (ami az átlag embernek teljesen megfelel, de soknak még a 3 csillagos is) mellett van, aki hajlandó felárat fizetni az 5 csillagosért, sőt, én az vagyok, aki az 5 csillag Superior-t választja. Ettől még nem jelenti azt, hogy a 4 csillag ne lenne jó. Főleg annyiért, amit a legtöbb fizet érte.

trey @ gépház

Azt ugye tudod, hogy egy vezetőnek nem csak a jutalom felvétele (Karácsonyi minapi történések mostanság :D) a feladata, hanem az is, hogy mindenáron biztosítsa a működést, aztán ha nem tudja, akkor kb. erkölcsi kötelessége felállni, majd utána amikor megkérdezték tőle az objektívfüggetlenek, akkor lehet majd rinyálni? Nem csak a jutalmat felvenni az el nem végzett melóért?

trey @ gépház

Állami intézményekről beszélünk. Ha erre neveli a rendszer a kádereit...

Gondolj bele a felállók vagy eleve nem vállalják vagy már felálltak. Maradtak a jutalom felvevők. (tisztelet a kivételnek) Őket időnként kirúgják -> jobb kussban ülni nekik és felvenni a jutalmat.

Aztán jönnek akik akarnak valamit (remélhetőleg javítani). Központosítanak. Ez plusz bürokráciát és lassúságot hoz magával a forráshiány mellé és meg is érkeztünk a jelenlegi helyzetbe.

Ha meg kellemetlen kérdés merül fel jön az arrogancia meg a visszamutogatás 30 évvel ezelőttre...

Sajnos középszinten mindig elakadnak az ilyen feljegyzések, jelentések, figyelmeztető levelek. Mindig.

Par eve volt egy kis falfeheren reszketes, amikor a friss CEO permafrostnak nevezte a kozepvezetoi reteget, es a mondokajaban tobbszor szerepelt az "accountability", mint elotte 20 evig osszesen.

A segélyhívó rendszer részleges leállása (ha jól emlékszem, akkor USA-ban vagy Új Zélandon történt) smafu?

Reptereken ragadáshoz csak egy apróság (gondolatkísérlet): Tegyük fel, hogy krónikus beteg vagy, gyógyszereket szedsz, nagyon fontos betartanod a napi rutint (alvás ideje, étkezések ideje stb.). Egy ilyen zűrzavar teljesen felborítja a napod / napjaid. Jobb esetben csak rosszul érzed magad, rosszabb esetben SBO-n kötsz ki. 1-2 nappal tovább tart az utazásod. Akkor is ilyen picinek tartanád a problémát?

A segélyhívók leállása már jó példa kritikus infrastruktúrára ha azoknak voltak minősítve. USAban tuti alvállalkozók végzik piaci alapon változó minőségben...

A második például nem jó, mert kisszámú eset és a hatás bár bosszantó igazából csak nem várt kellemetlenséget okozott.

( pirate | 2024. 07. 24., sze – 16:48 )

Errol ket dolog jut eszembe:
1. Egy adott termekben mukodo szoftverert kit teszel felelosse? Pl. ha lezuhan egy repulo szoftverhiba miatt akkor a gep gyartoja vagy a szoftver gyartoja (tegyuk fel mas ceg) felelos?
2. Hogyan lehet auditalni a dinamikusan valtozo nyilt forraskodu szoftvereket? Minden yum/dnf/apt update elott valaki kiad egy "plecsnit" az adott 10-20-300 komponenshez?

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

1. Mindkettő. A mértéken lehet csak vitatkozni.

2. Adott release-ket lehet auditálni, plecsnizni. Ezek szigorúbban ellenőrzött verziók. Nyilván nem 5 évente kell az adott szoftverből kiadni egy ilyen verziót és nem is naponta. Komoly helyeken csak ilyen szoftvereket lehet / kell kötelezően használni.

2. Adott release-ket lehet auditálni, plecsnizni. Ezek szigorúbban ellenőrzött verziók. Nyilván nem 5 évente kell az adott szoftverből kiadni egy ilyen verziót és nem is naponta. Komoly helyeken csak ilyen szoftvereket lehet / kell kötelezően használni.

Ezt hogyan kell elkepzelni egy biztonsagi/antivirus/stb. szoftvernel? Napi szinten valtoz(hat)nak a tamadasi formak ami ellen ved.

A masik: "the part that runs validation checks on new updates prior to release — ended up allowing the software to be pushed out “despite containing problematic content data.” " (ezt a crowdstrike-rol irtak), szoval mi tortenik ha a "plecsnizo-szoftver" engedi at a hibas verziot?

Arra akarok kilyukadni, hogy nem tudom mennyire kivitelezheto ez olyan kornyezet(ek)ben ami(k) gyakorlatilag ra van(nak) kotve napi 24 oraban 2-3-50-100 frissiteseket tolo csatornara.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( trey | 2024. 07. 24., sze – 18:19 )

Szerintem nem fair a fejlesztőktől olyat kérni, hogy működő dolgokat adjanak ki a kezeik közül, hiszen nagyon keveset keresnek.

trey @ gépház

Én eddig azt hittem - és itt a HUP-on is végig azt hallgattam -, hogy a szoftverfejlesztés az egy nagyon komoly, sok tanulást igénylő, intellektuális mérnöki TUDOMÁNY, nem pedig kuruzslás. Amit ezért átlagon felüli fizetéssel honorálnak.

Erre most kiderül, hogy ennek a high-profile tudományágnak a produktumával kapcsolatban még annyi működési garanciát sem várhatok, mint egy doboz gyufától :(

trey @ gépház

ami még romba is döntötte a rendszereiket

Ez azert tulzas... Ugy tudom Windows 10 es Windows 11 rendszerek alltak le, egyik sem szerver OS. Ha Marika nem tud belepni a rendszerbe megnezni/kinyomtatni/stb. a beszallokartyat az nagyon komoly gond (foleg az utasoknak), de attol meg nem dol romba pl. a foglalasi rendszer, csupan nem elerheto.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Azért arra is marha kíváncsi lennék, hogy mi indokolja a Windowst ott, ahol beszállókártyát kell megnézni, kinyomtatni stb. Én még abban a rendszerben szocializálódtam, amikor HP UX-on karakteres képernyőn minden elérhető volt, a világon mindenütt, ami a beszálláshoz szükséges a CHECK-IN pultnál. A tájékozató táblák még ma is karakteresek a 16m szín ellenére is, mert olcsóbb a szines panel (egyáltalán, van még monokróm panel?). Nyilván azóta a világ változott és komplett oprendszer kel mindehhez 250GB SSD-vel és 8GB RAM-mal mert ezt az IT szakma meg tudja indokolni. Aztán lerohad az egész a felelősségteljes szakmai döntések súlya alatt.

Tisztelt ügyfelünk!
Bankunk hálózatának fejlesztése keretében, valamint a költségek csökkentése érdekében atm-jeinket linux operációs rendszerre állítjuk át.
Készpénzfelvételhez mostantól használja a getcash parancsot. Szintaxis:
getcash -ac szamlaszam (hexaban) -c kártyaszám (hexaban) -p pinkod (MD5 hashként) -a összeg (hexaban) -b bankazon (128 bites egyedi számlavezető bankazonosító)
Ha bizonylatot szeretne kapni a tranzakcióról, akkor irányitsa a getcash parancs stdout-ját az lpt1-be, szükség esetén grep-ezze le az értékes sorokra.

:D

Windows Serverek is érintettek voltak, amennyiben feltelepítették rájuk a Crowdstrike ipari hulladékot. Ugyanúgy BSOD-t okozott - csak szerver oldalon.

Errol van valami info/link? En is igy sejtettem, de nem talaltam semmi ilyen informaciot, a MS honlapjan csak Win10/11-hez van segitseg, szerverek eseten nem tettek volna ki segitseget a javitashoz?

[szerk.] Megtalaltam a szerverekre vonatkozo linket is (nem tudom korabban miert nem dobta fel, mondjuk lassan toltodott, lehet nem vartam ki)

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Az igazán csodálatraméltó szerintem az a szakember, aki a Linuxos verzióját frissítgette a CrowdStrike-nak. Biztos van olyan környezet, ahol az ilyen fajta védelemnek van értelme Linuxon pl. én is olvastam valakitől aki hallott valakiről, akinek valami NGO szervezet Linuxos szerverén gond volt a CrowdStrike telepítéssel még áprilisban. Mintha a CrowdStrike funkcionálisan egyenjogú lenne a Windowsos és Linuxos szervereken. Lehet, hogy jog szerint igen, de kétlem, hogy technikailag sok érelme lenne ilyen típusú védelemnek Linuxon. Köpködjetek meg ezért a feltételezésért.

Én eddig azt hittem - és itt a HUP-on is végig azt hallgattam -, hogy a szoftverfejlesztés az egy nagyon komoly, sok tanulást igénylő, intellektuális mérnöki TUDOMÁNY, nem pedig kuruzslás.

En ugy tudom barmifele tudomany ugy mukodik, hogy van egy jelenseg/esemeny es arra keres egy magyarazatot a jelenlegi tudasunk alapjan amit kiserletekkel alatamaszt. A programozas szerintem nem igy mukodik es nem hallottam meg senkit programozot tudosnak nevezni, igy nem hiszem, hogy a programozas tudomany (a tobbi dolog igaz ra).

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Computer science, data science

"There is still no consensus on the definition of data science, and it is considered by some to be a buzzword." (forras)

Szerintem az adatbanyasz vagy a data analyst jobban fedi az elvegzett munkat.

Egy programozo pedig szoftvermernok lehet, nem "programozo tudos" :) (programming science kifejezes sincs tudtommal)

A computer science-el egyetertek, a "matematika tudomanybol" fejlodott ki, de mostmar sokkal tobbet jelent, valoszinuleg nem kategorizalhato be abba a "definicioba" amit en felvazoltam.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( mraacz | 2024. 07. 24., sze – 21:24 )

Ez szerintem a jogban alaposan szabályozva van. A szoftverfejlesztő felelős azért a kárért, amit maga okozott. Kimentési okai lehetnek és üzletszabályzatban korlátozhatja a saját felelősségét. Ha megteszi, onnantól az általa okozott kárért csak korlátozottan, vagy semmennyire sem felel és az, aki pénzt ad az ilyen szoftverért, az a saját kockázatára alkalmazza a megvásárolt programot. Ezzel megoszlik a felelősség a szoftver gyártója és felhasználója között. 

(Konkrétan, aki olyan szoftvert használ,, amelyik kernelmódban matat a gépén vagy olyan operációs rendszert, amelyik megengedi, sőt, egyenesen szükségessé teszi ezt, az szerintem felel a saját káráért. Forduljon a kára rendezése érdekében ahhoz a szakemberhez, aki ilyen rendszer beszerzését megnyugtatónak tartotta, amikor a vételről a döntés született.)

A szándékos károkozás (vagy az azzal egyenértékű gondatlanság) másik eset, ott aki gondatlanul jár el, gyártó vagy felhasználó, korlátlanul felel a az okozott kárért, akármit is zár ki pl. a saját üzletszabályzatában. Ezt persze alaposan bizonyítani kell.

Szerintem itt a szoftver vagy vállalati minősítők felelőssége az igazán szabályozatlan. Az a kérdés, hogy a minősítő milyen normák alapján dolgozik és a megállapításaiért mennyire felel. 

Az a kérdés, hogy a minősítő milyen normák alapján dolgozik és a megállapításaiért mennyire felel. 

Olyan minősítőkre gondolsz, akik például a 2008-as lakáspiaci lufit is fújták? Mert akkor az IT minősége lefelé száguld véleményem szerint. Nagyon elválik a valóság a papíron lévő állapottól.

( hory v | 2024. 07. 24., sze – 21:26 )

Szerkesztve: 2024. 07. 24., sze – 21:28

en dev vagyok, de szerintem is teljesen jogos elvaras a minosegi munka vegzes. sot, az agile/scrum/... is ezt celozza, csak tobbnyira abuzaljak arra, hogy eszetlenul "ship it" gombot tudjon nyomkodni a """vezeto""".

Az epitotol, epitesztol elvarjuk, hogy a haz, amit veszunk, stabilan alljon, ha egzenges, foldindulas van is. A hid megmaradjon, az ut eros legyen. Es igy is van.

A mutetek, diagnosztikai szoftverektol elvarjuk, hogy mukodjenek. Ne oljon meg a CT (NB: meg tudna, es meg sok mas egeszsegugyi eszkoz is). Elvarjuk, hogy 100milliobol 100millioszor helyesen adagolja az infuziot a beagyazott szoftver. Es igy is tortenik (*)

Autot tervezok kepesek megcsinalni olyan szenzorokat es beagyazott rendszereket, amik karbantartas nelkul, utve-vagva is mukodnek evtizedeken at (*),

 

Mernokok az elet minden teruleten teljesitenek, es megbizhato, tartos dolgokat csinalnak.

 

Es mit csinalunk mi, IT-sok? ... Tomoren, szart. Tisztelet a kivetelnek. Minden tegnapra kellett volna, sosincs mindenre eleg ember es par ev utan mar ugyis elavult legacy lesz.

Es ez nem kis reszben a developer/engineer-ek sara.

 

(*) tobbnyire - de joval tobbnyire, mint egy atlag "shipped" szoftver :(

( Nyosigomboc v | 2024. 07. 24., sze – 22:55 )

Szerintem a legrosszabb lenne egy csoportba venni az open source programokat meg a kritikusakat. Mas kategoria az, ha mondjuk egy netrol letoltott zene konverter hibazik, es mas, amikor a Therac-25. Utobbinal mindenkepp legyen felelos a gyarto! Elobbinel meg nem lenne jo.

Egyebkent teljesen mas bonyolultsagu mernoki szempontbol egy mai software, mint mondjuk egy epulet.

A strange game. The only winning move is not to play. How about a nice game of chess?

( laysoft v | 2024. 07. 24., sze – 23:28 )

🤓

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

( Raynes v | 2024. 07. 25., cs – 00:58 )

Szerkesztve: 2024. 07. 25., cs – 00:59

Szabályozni kellene, hogy teljes legyen a felelősség, és ne lehessen kizárni, hacsak nem valami ingyenes FOSS projektről van szó, vagy csak szórakoztató jellegű szoftverről (játék). Egyébként kereskedelmi szoftvernél nem engedném kizárni a felelősséget, ha valakinek kárt okoznak, fizessék meg.

A forráskódokat is beszabályoznám, hogy szoftver csak úgy forgalmazható, úgy kérhetnek érte pénzt, ha a forráskódját egy erre szolgáló szervezetnél letétbe helyezik (a későbbi frissítéseket is), akik x év múlva megnyitják, és a fejlesztő kérelmére ez egy ízben meghosszabbítható y évvel, de ennek lejárta után mindenkinek megnyílna a kód GPL licenccel, automatikusan. Így sikeres szoftverek egy idő után közkinccsé válnának, meg könnyű lenne őket portolni, nem kéne emulátorozgatni.

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

A felelősségkorlátozás a jogban általéban azért hasznos dolog, mert sok olyan termék van, amelyiknek az előállítója nem rendelkezik akkora vagyonnal, mint amekkora kockázat fűződhet a termékéhez. Alap példa a szekérfuvaros, akinek a rakománya egy mázsa arany. Hiába gondolod, hogy a fivaros felel azért a mázsa aranyért, a szekere, a lovaival, a házával és az asszony seggével együtt sem éri el a rakománya századrészének az értékét. Aki egy terméket megvesz, annak tisztában kell lennie azzal, hogy a termék gyártójának a felelőssége meddig terjed és annak tudatában kell saját maga gondoskodjon a saját maga biztonságáról. 

A forráskód "letétbe helyezése" szerintem fölösleges lépés. A megoldás a nyílt forráskód általánossá tétele. Ez átcsoportosítaná a szoftveripar jövedelmeit a gyártóiról az üzemeltetői felelősség irányába. Nem a Micorosoftnak kellene a sápot megfizetni, aki egyébként sem felel semmiért se, hanem a saját szakértődnek, aki a royalty ellenében beszerzett kód alklmazásáért felel a vállalkozónál. Maradna a fejlesztőnek jövedelem, több is, mint most a zárt kód esetén. És akkor dönthetsz magad, hogy olyan oprendszert választasz-e, amelyiknek a működéséhez kernel módban működő "védelem" kell.

Jó, de érted, jelenleg az a gyakorlat, hogy több tizenezertől több millióig terjedő árú szoftvereknél a fejlesztők kizárják teljesen a felelősséget. De a pénzt bezsebelik érte. Valahogy nem arányos. Főleg olyan méretű cégeknél, mint a Google, Oracle, Apple, Microsoft, trillió dolláros cégek, ezek azért nem szekeres kategória, ne sarkítsunk.

A letétbe helyezés kényszer lenne. Olyan nincs, hogy nyílt forráskód általánossá tétele, mindig lesznek emberek, akik nem hajlandók megnyitni a kódjukat, vagy mert valami ipari vagy katonai titok van benne, oké, legyen, de akkor ne hozhassa forgalomba, csak ő használhassa belső használatra, úgy teljesen rendben van a titkolózás. Viszont ha a publikumnak kiadják, akkor adják meg az esélyét, hogy később, azt a kódot valaki gondozza, arra az esetre, ha a platform kiöregszik alóla, vagy lenne olyan sérülékenysége, súlyos bugja, amit később a fejlesztő nem javít, vagy mert nem akarja, vagy mert már megszűnt. Plusz ha x év után megnyílik közkincsnek, akkor az általános technológiai színvonalat is emeli a későbbiekben, meg a később piacra lépő szoftvereknek is felstrófolja a versenyt, mert jobbnak kell legyenek, mint az ingyenessé, nyílttá vált alternatíva.

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

A sarkítást csak azér tettem ide, valóban meg nem engedhetően, mert az ember az igazságérzetétől vezéreltetve hajlamos abban a jogi alapvetésben szilárdan megbízni, hogy aki másnak kárt okoz, az felel az okozott kárért. Ez ugyan jog szerint igaz, de a valóság sajnos szarik a jogra. Hiába felelne a kár okozója a kárért, ha az okozott kárt nem lehet vele szemben érvényesíteni. És lássuk be, a rossz kódok előállítói humán erőforrások, valahol ebbe a kategóriába tartoznak, a Google-nél és a Microsoftnál is. Azon, aki elkúrta a kódot, vagy aki eleresztette a teszteletlen frissítést, nem lehet sokszázmillió dolláros kártérítést behajtani. A munkáltatóján persze lehetne, az igaz, de annak meg van hozzá gazdasági ereje, hogy megtehesse, hogy kizárja a saját felelősségét. Teljesen jogszerűen. A fostalicska Windows rendszereket így is megveszik, sőt, képzett szakemberei lelkesen hirdetik, még egy ilyen eset után is, hogy nem a rendszer a ludas, hanem "hát ugyi vannak még hibák elvtársak". Én hajlott koromnál fogva még emlékszem erre a kitételre.

Nem is a munkavállalóval, programozóval kell ezt megfizettetni. A sok hájfejű befektetővel, akik a dollármilliárdokat zsebre teszik. Bezsebelnek annyi pénzt, hogy van miből.

A munkavállaló felelőssége mindenhol korlátozott, kivéve a szándékos bűncselekményt. Amúgy sem a programozó felelőssége, mert oké, eltol valamit, hanem azé, aki nem ellenőrzi a munkáját, meg nem vezet be kellő tesztelési folyamatokat kiadás előtt. Az egész cégen kell ezt leverni, nem az egyes alkalmazotton.

Félre ne értsd, amit javasoltam, az nem csodaszer. A kártérítésért való felelősséget bizonyítani is kell, meg a kár mértékét is, ami adott esetben elég nehéz. Egy csomó buktató van, mások és a károsult közrehatása (nem támogatott környezetben futtata, nem volt backup, stb.), ok-okozati összefüggés, annak erőssége, ez is csak általában sok év pereskedés után sikerül.

Ennél a Crowdstrike-nál sem az a baj, hogy hibáztak, hanem hogy ez már nem az első hibájuk, nem is a második, és nem vezettek be a múltbeli esetek után sem védelmi mechanizmusokat, hogy ez ne ismétlődjön meg. 

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

Vagy nem, ha kellően monopolhelyzetben van és/vagy nehéz tőle megszabadulni, mert nincs triviális alternatívája.

A vállalati arroganciát csak és kizárólag szabad versenyben árazza be egy csak és kizárólag racionális döntéseket hozó keresleti oldal. Egyik sem adott a tech-piacon.

( nns v | 2024. 07. 25., cs – 01:59 )

Nem vagyok biztos benne, hogy a CrowdStrike szoftvert árul. Nagy valószínűséggel szolgáltatást lehet tőlük venni.

( ssikiss | 2024. 07. 25., cs – 08:38 )

Azért na... ilyen khm színvonaltalan bevezetővel és választási lehetőségekkel elereszteni egy szavazást...

( htmm v | 2024. 07. 25., cs – 10:39 )

Hogyha en gyartok egy fizikai termeket es a termek nem alkalmas a feladatara, akkor minimum, hogy a vasarlonak visszajar a penze (illetve bizonyos esetekben buncselekmeny is felmerulhet). Ha a termekem egy szoftver, akkor ez elintezheto egy vallranditassal.

Ha a fizikai termekem masnak kart okoz es egyertelmu, hogy nem jartam el a gyartasnal kello gondossaggal (peldaul a fizikai termekem nem felel meg az erintesvedelmi szabalyoknak es valakit megraz az aram), akkor felelossegre leszek vonva. Ha a termekem szoftver, akkor ez van, a vasarlo rosszul fogta.

Nem mondom, hogy minden bugert vonjuk felelossegre a szoftver gyartojat, de ha kiderul, hogy senki sem tesztelte (mint peldaul a Crowstrike-nal), akkor akar mit mond az EULA, szerintem karteritesre kellene kotelezni a fejlesztot, akkor is, ha ebbe tonkremegy a ceg. (A maximalis karterites osszeget a licensz dij tobbszoroseben kellene meghatarozni, hogy az ingyenes/szabad szoftverek fejlesztoit ne lehetetlenitsuk el)

( miq | 2024. 07. 25., cs – 12:54 )

Szerkesztve: 2024. 07. 25., cs – 13:07

Az egyik ami eszembe jutott, az az magasabb árért magasabb felelősségvállalás.
Ugyan nem szoftver, de szolgáltatás terén voltam már olyan helyen, ahol az árajánlatadás előtt megkérdezték a megrendelőt, hogy mekkora anyagi felelősségvállalást szeretne, és ez alapján árazták a szolgáltatást. Kb. műhiba-biztosítás jelleggel.

Jellemzően sajnos a megrendelő sokszor saját maga sem tudja, hogy mire van szüksége. Pl. indít egy 99.999%-os rendelkezésre állási igénnyel, aztán mikor meglátja az ajánlatokat, akkor kiderül, hogy jó lesz oda a 99% is. Utána meg persze veri az asztalt, hogy mi az, hogy egy évben 3 nap kimaradás :)

---

De... szoftvernél nagyon sok múlik a környezeten. Mondjuk csinálsz egy webapp-ot php-ban, pythonban, rubyban, akármiben. Vagy kikötöd, hogy csak a.b linux c.d verziója, e.f webszerver g.h verziójával, php i.j alatt  x.y lib v.w verzióval vállalod, vagy beleszaladhatsz, hogy a kedves megrendelő/vevő valami miatt 3 verzióval régebbi disztrót használ, vagy fél év múlva befrissít egy újabbra, vagy egyébként is Windowson futtatná.

OK, csinálhatsz konténert, vagy komplett VM-et, adhatod azt is a megrendelőnek, azzal már kicsit közelebb vagy ahhoz, hogy csinálhass valami kiszámíthatót, de még akkor is ki vagy szolgáltatva az alattad lévő rétegeknek.

---

Azt is megértem persze, hogy nulla felelősségvállalásra törekszenek, mert mondjuk jön a valaki, és azt mondja, hogy lett 500 csilliárd EUR vesztesége a program miatt, amit behajtana. És akkor rögtön kezdhetjük etetni a jogászokat, hogy 5 év alatt kitalálják, hogy az az 500 csilliárd az valójában jó ha 500 ezer, megy hogy az okozott kárért hány százalékban felelős a szoftver fejlesztője, hány százalékban az OS fejlesztő, hány százalékban a hardverfejlesztők, hány százalékban az üzemeltetés, hány százalékban az architect, aki úgy tervezett hogy 100%-ban megbízott a szoftverben, stb. stb.

Klasszikus ügyvédetető: 50es táblánál karambolozik két kocsi, mindkettő 90-nel ment, az egyikben nem működött volt a fék, pedig aznap hozták ki a szervizből, ráadásul a sofőrnek nem volt jogsija, a másikat meg eltiltott pasas vezette bepiálva. És egyébként is csak azért ütköztek, mert a 95 éves Pista bácsi kezéből kitépte magát a 3 éves dédunokája és kiszaladt az útra, ezért az egyik sofőr elkapta a kormányt.  Osszuk el a felelősséget...   Kb. ilyen lenne a szoftver-kártérítés is. Csak a jogászok járnának jól vele.

( gelei v | 2024. 07. 25., cs – 12:58 )

Off-the-shelf termekeknel mennyire jellemzo ez a felelossegvallalas? Vagy miert a szoftvergyartokat vettuk most elo?

Fodrasz vagyok, veszek egy fasza hajvago gepet, lerohad, nem tudom levagni a vendeg hajat. Megteriti a gyarto a karomat?

Fodrász példád rossz. Először is egy fodrásznak nem csak 1 gépe van. Legrosszabb esetben marad a jó öreg olló, fésű. Tud egyszerűen és gyorsan vésztervre váltani.

A Crowdstrike-nál mi volt / lehetett a vészterv, ha nem működik / rendszerösszeomlást csinál? Ezt vajon az ügyfelek tudomására hozta a szállító?

Szoftverfejlesztőként beárazod a munkaeszközeid is. Akár úgy, hogy több hardvert veszel, akár úgy, hogy jobb minőségű laptopot.

Egy hardver hibát viszonylag egyszerűen lehet kezelni és nem okoz tömeges hibát a vásárlóknál, ügyfeleknél - leszámítva mondjuk a Samsung fiaskót. Egy szoftvernél viszont a hiba mindig megjelenik annak összes példányában. Nem tudod elkerülni. Kivéve, ha lecseréled az adott szoftvert más verzióra vagy váltasz másik gyártó másik termékére.

Az egyik legfontosabb tanulság az hogy jól vannak-e ezek a rendszerek kategorizálva? Mert úgy néz ki, hogy ezeket a rendszerekre sokszor pont úgy tekintették mint a Mariska néni gépére, hogy hát ha nem megy, akkor majd Pistike megszereli, addig Mariska meg kávézgat. Miközben ezek sokszor kritikus rendszerek voltak az üzletmenet szempontjából.

( XYBeR | 2024. 07. 25., cs – 13:54 )

Csak halkan jegyzem meg, hogy lehet a fejlesztőket nevesíteni, de a fejlesztések környékén legtöbbször vannak pl tesztelők, product ownerek, projektvezetők, tanácsadók, miegyebek, a cégeknél meg mindenféle (állítólag) felelős vezetők, sőt: tulajdonosok is ;)

A nagy kérdések:
- Ők biztos, hogy vannak? Nem spórolják le őket?
- Egyáltalán hogyan végzik, a munkájukat? Milyen séma alapján?
- Az illetékesek miért nem merik kimondani, ha valami nem jó? Miért nem teszik fel a STOP táblát?

Amíg a folyamatok nincsenek kidolgozva, hiányosak, nem tartják be őket, addig nincs miről beszélni.

( wELDER v | 2024. 07. 25., cs – 16:32 )

Szerkesztve: 2024. 07. 25., cs – 16:37

biztosító

vagy az automatikus softverfrissítést kötelezővé tévő szolgáltatást nyújtó szerződött cég, ami nem feltétlenül azonos a szoftverfejlesztővel

I have your source code, should I open it?

( dorsy v | 2024. 07. 25., cs – 18:24 )

Szerkesztve: 2024. 07. 25., cs – 18:27

https://stackdiary.com/linksys-velop-routers-send-wi-fi-passwords-in-pl…

The consumer organization conducted these tests using the latest firmware available at the time. Despite warning Linksys in November, no effective measures have been taken.

Linksys released a firmware update after the initial warning, but it did not address the concerns raised. “We regret the lack of response from Linksys and expected more from such a renowned brand,” Testaankoop expressed.

Testaankoop suspects the security issue might stem from third-party software used in the Linksys firmware. However, they emphasize that this does not excuse the vulnerability. For those who already own the affected routers, they have recommended changing the Wi-Fi network name and password via the web interface instead of the app. This precaution prevents the SSID name and password from being transmitted in readable text.

Akkor most ki a hibas es mennyit is kene fizetnie mindenkinek, aki ilyen eszkozt vett, hogy legyen (mesh) wifi az irodaban? :) 
A szomoru/vicces, hogy - gondolom - ez pont egy halozatbiztonsagi eszkoz kene legyen: AP/router/firewall?

Szerinted ki legyen buntetve es mivel? Alkalamazott, aki a kodot irja? Aki a sprintet priorizalja? CEO? Product owner? Minden reszvenytulajdonos? Vagy "legyen egy sima corporate expense a polgari peres karterites" es az egesz ceg koltsegoldalahoz adodik es csa, aztan birosag mondja meg mekkora a kar (ha mar tortent)?

Mert szerintem epp ez a legutobbi a status quo, csak vannak 70 eves tech analfabeta birok, meg elhuzodo birosagi dontesek, sot, peren kivuli megegyezesek is... aztan a product ownernel es a scrum masternek el kene tudnia magyarazni a CEO-nak ezt a "jogi kockazatot" ilyenkor, hogy "4 ev mulva lehet, hogy karteritest kell fizetnunk, ha nem ezt a ticketet priorizaljuk".

Kerdesem: biztos jo otlet szabalyozasi oldalrol valtoztatni ezen? Vagy corporate szokasjog modszerrel valtoztatni ezen, miszerint nagycegek csak akkor szerzodnek masik nagyceggel, ha az alkalmazottak idejenek harmadat elvihetik az auditorok az aktiv munkaakadalyozasi kiserleteikkel? Ugyanis ez utobbi is kezd megtortenni.

A cég vállalja az anyagi felelősséget, az extraprofitjából, amit a folyamatok elspúrkodásán realizált. Ennyit kell törvénybe iktatni és nem többet. A belső folyamatokat majd megoldja a cég, hogy jobban menjenek és mindamellett gazdaságosak maradjanak. Pl. kevesebb megélhetési babzsákfejlesztőt vesz fel.

( khiraly | 2024. 07. 25., cs – 19:01 )

Lári-fári, új emodzsi mikor lesz?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( elod v | 2024. 07. 26., p – 08:14 )

Megfordítanám a kérdést. Mennyire lehet felelőtlen egy szoftverfejlesztő cég? Nem egy fejlesztő hibája ez, teljes processz failure.

( dyra | 2024. 07. 27., szo – 11:16 )

Be kéne fejezni hogy ingyen teszteltetik a cucaikat velünk. Nem kicsi anyagi és humán erőforrás kell ahhoz hogy a váratlan hibákat kiküszöböljük ami egy rossz fejlesztés eredménye. Agilis fejlesztés mindig ez a duma. No meg a marketing. PL mikor a skypot felvásárolták rögtön fejlesztettek rajta. Az addig jól használható Skype egy rakás hulladék lett. A telepítő 30 - 40 magáról. 200 fölé hízott. De.meg kismillió ilyen volt. Amig üzemeltettem az utolsó években már teszt szervert használtunk. Ami az éles tükörképe volt. Előbb azt frissítettem mert már untam a frissítési bugokat. Ha jól ment dobtam fel az elesre. 

Pont ezaz, ami felháborít:
- A fejlesztőnek kerül a tesztelés X €-ba.
- Az n számú ügyfél által végezett tesztelés legalább n*X €-ba kerül. Globális szinten ez jóval drágább (több energia, humán erőforrás stb.)

Nyilván a képlet picit összetettebb, de még mindig olcsóbb makró szinten, ha a fejlesztő tesztel.

ha az n szamu ugyfelek mind osszedobjak a fejlesztonek az osszes altaluk hasznalt hw/sw kombinaciot es permutaciot a tesztekhez :) en tavolrol sem latom ennek eselyet es imho nem is a fejlesztol dolga az XY infrat "megvedeni a gebasztol".

akkor csinalod jol, ha ugy tekintesz az osszes hardverre es szoftverre, hogy az el fog b*odni. mert el fog. a kerdes csak a mikor es a mennyire.

Nem az ügyfél feladata, hogy ezeket összedobják. A fejlesztő saját hatáskörben végezze el a munkáját rendesen. Ebbe beletartozik a tesztelés is. Ha erre nem képes, akkor menjen kapálni.

akkor csinalod jol, ha ugy tekintesz az osszes hardverre es szoftverre, hogy az el fog b*odni. mert el fog. a kerdes csak a mikor es a mennyire.

Ez így megmosolyogtató. :D Mert akkor semennyire se lehet megbízni az IT-ben. Egy tákolmány katyvasz az egész. Megbízhatatlan.

Ismerek olyan (magyar) szoftverfejlesztőt, amelyik a termékét más garanciális feltételekkel értékesíti akkor, ha az ügyfél a fejlesztő által kiválasztott hardvert is tőle veszi meg, és más feltételekkel, ha a vasat a szoftver alá az ügyfél választja magának. Az első esetben nagyjábl minden (!) felelősséget elvállal a szoftver hibátlan működéséért, a második esetben nyilván a vasra semmit nem vállal, a következményes károk lehetősége miatt a szoftverre csak korlátozott a felelőssége, üzemeltetési support meg nincsen. 

Egy tákolmány katyvasz az egész. Megbízhatatlan. > innen indulunk. aztan meg szepen korbejarjuk az osszes SPOF-t es ha mar (joreszt) mind megszunt, akkor johet a disaster recovery...
meg1X: ha te elhiszed barmilyen szofrverrol vagy hardverrol, hogy az soha nem fog megallni, szarul csinalod.

( hajbazer v | 2024. 07. 27., szo – 16:43 )

Akármit is mondanak a fősodratú multimosdatók, átszőtte már a társadalmat és a gazdaságot annyira az informatika, hogy ne a 40 évvel ezelőtti szintnek megfelelő törvényi szabályozás vonatkozzon rá.

Ha a CrowdStrike elbassza egy bank, repülőtér, pláza, mozi stb. működését, fizesse ki a kárát és ez jogszabályban legyen garantálva. Van miből kifizetni nekik. Vagy ha nincs, kössenek felelősségbiztosítást, és a biztosítónak is érdeke lesz, hogy a multika garantálni tudja a kódminőséget.

Véget kell érjen az áldatlan állapot, hogy babzsákfejlesztőék kényelmesen tákolgatnak, aztán százmilliók számítógépét, nyomtatóját, szkennerét, okostelefonját kell kidobni egy szándékosan gerjesztett inkompatíbilitás miatt / vagy fogyasztanak több áramot holnaptól / vagy válnak bootolhatatlanná, és a cég, meg a Stockholm-szindrómás véleményvezérek, talpnyalók is csak annyit tudnak mondani "dehát nem kötelező használni".

Ugyanakkor minden lehetséges módon meg kell akadályozni, hogy ilyen malőrökért kisembereket (tehát egyszerű mérnököket) tegyenek kizárólagosan felelőssé. Az fizessen és az vállaljon felelősséget, aki milliárdokat kaszál a szutykán. Vállalja be a kockázatot, ha már adott neki a lehetőség, hogy egy 0 Ft költséggel lemásolható szoftvert pénzért adhat el, gyakorlatilag végtelen mennyiségben és ezen eredendően sokkal nagyobb profitokat kaszál, mint más, kézzel fogható terméket gyártók.

egy 0 Ft költséggel lemásolható szoftvert pénzért adhat el, gyakorlatilag végtelen mennyiségben és ezen eredendően sokkal nagyobb profitokat kaszál, mint más, kézzel fogható terméket gyártók

Nagyjabol egyetertek, viszont a zero koltseggel masolhato program manapsag mar nem igaz. Ebben a konkret esetben (es sok masban is) a tamogatasert kell fizetni foleg, nem (csak) a szoftverert.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Nagyjabol egyetertek, viszont a zero koltseggel masolhato program manapsag mar nem igaz.

De igen, igaz. Akkor is, ha az a szoftver telepíthető egy ügyfélnél futó gépre. Akkor is, ha az a szoftver telepíthető egy, a szolgáltatónál futó gépre (SaaS).

Ebben a konkret esetben (es sok masban is) a tamogatasert kell fizetni foleg, nem (csak) a szoftverert.

Ez az üzleti modell sajátossága és nincs köze ahhoz, hogy mekkora költséggel másolható le a szoftver. Van olyan szoftver, aminek külön kell fizetni a licenszéért és a támogatásáért. Van olyan, amelyiknek csak a támogatásáért kell fizetni. Ettől még minden szoftver 0 költséggel sokszorosítható.

hogy ne a 40 évvel ezelőtti szintnek megfelelő törvényi szabályozás vonatkozzon rá.
hint:

GNU GENERAL PUBLIC LICENSE

Version 2, June 1991

nincs annak semmi baja. 30-40 eve, sot elotte is voltak mission critical rendszerek. :)

Vállalja be a kockázatot > egy nagy lof*szt. csokkentse a kockazatot, aki az adott infrat uzemelteti, legyen recovery plan es business continuity plan. ne sporolja le. ha egy repter megall egy egyszeru szoftverhiba miatt, az nem a szoftver hibaja, hanem az uzemeltetese (vagy a babzsakvezetese, aki lesporolta a koltsegeit). ugyanilyen erovel HW-hiba miatt is megallt volna. ha erre nem keszultek fel, az a sajat nyomoruk. elhittek, hogy a szoftver nem lehet hibas.
(zarojelben jegyzem meg, h egy ransomware-t beszopni es backupbol visszaallni miatta, egy nagysagrenddel nagyobb ido/szopasfaktor, mint egy koszos file-t kitorolni, vagy megnyomni a reset gombot X-szer, hogy a win blacklistre rakja a .sys-t)

nincs olyan, h hibamentes SW vagy HW, akkor sincs, ha nem a babzsakbol jott elo. es 30 eves. :)

GNU GENERAL PUBLIC LICENSE

A GPL nem törvényi szabályozás, hanem egy licenszszerződés de nyilván nem futja többre, mint egy orbitális csúsztatással indítani.

ha egy repter megall egy egyszeru szoftverhiba miatt, az nem a szoftver hibaja, hanem az uzemeltetese

Helyesen: Ha egy reptér megáll egy szoftverhiba miatt, az együttesen a szoftver és az üzemeltetés hibája, de elsősorban a problémát okozó, frissítést kiadó multié, aki egyértelműen elspúrkodta a tesztelést és egyébként is túl milliárdos volt olyan failsafe rendszert összerakni, amit nem tud hazavágni egy általa kitolt szar frissítés.

ugyanilyen erovel HW-hiba miatt is megallt volna.

Ami meg a hardvert gyártó multi hibája lenne, rendeltetésszerű használat esetén. A szoftverfrissítés rendeltetésszerű használat.

ha erre nem keszultek fel, az a sajat nyomoruk.

Igen, az ő nyomoruk, mert ők szenvedtek el kiesést, de nem csak a saját hibájukból, hanem a szoftvermulti hibájából is.

elhittek, hogy a szoftver nem lehet hibas.

Ezen a reklámok betiltása tudna sokat segíteni (mivel mindenhonnan az folyik marketingmilliárdokból, hogy a frissítéstől csak jobb és stabilabb lesz a szoftver, ami nyilvánvaló hazugság), de ez nem menti fel a szoftvermultit, pláne, hogy azt a frissítést a támogatásért fizetett pénzért adta. A frissítés gyakorlatilag egy visszahívott terméknek tekinthető. Nehogymár a vásárló szülő legyen a hibás azért, ha a mérgezett bébitápot odaadja a gyereknek, és az meghal tőle, mert nem várta meg, amíg esetleg a NÉBIH véletlenül, szúrópróbaszerűen ráakad, és visszahívatja, hiszen a múltban már történt ilyen visszahívás. Ez így áldozathibáztatás.

egy orbitális csúsztatással indítani. > hany eves a kapitany?
amit nem tud hazavágni egy általa kitolt szar frissítés. > nem ez a kerdes, hanem ha hiba van, az mivel jar. hiba van/volt/lesz.
a hardvert gyártó multi hibája lenne > mutass mar egyetlen diszk gyartot, operacios rendszert (GPL, 30+eve nem vallal lofaszt se, helloka! fel kene ebredni!), aki felelosseget vallal adatvesztesre. csak egyet! :) ez nem igy mukodik! ugy mukodik, hogy: hol volt a backupod? mennyi ido alatt alltal vissza az uzemszeru mukodesre? az ilyenek miatt, mint te kell rairni a mikrora egyes orszagokban, hogy nem szaritunk benne macskat...
de nem csak a saját hibájukból > dehogynem, lasd egy sorral fentebb. teljesen mindegy a hibat ki/mi okozta. el kell haritani, vissza kell allni uzemszeru mukodesre. ez ilyen magyar mentalitas, hogy a tel a hibas, mert nincsenek befoltozva a katyuk, meg, hogy telen nem keszultunk hora, nyaron a melegre... mutogathat ra a kozutkezelo, de ha le van sporolva a TMK, elbaszodik az ut. :)
Ezen a reklámok betiltása tudna sokat segíteni > faszsagokat beszelsz. rendszertervezesi hianyossagok vannak olyan helyeken, ahol nem szabadna. neked ette ki az agyad a reklam, ha ugy erzed ennek barmi koze van ahhoz :D
mivel mindenhonnan az folyik marketingmilliárdokból, hogy a frissítéstől csak jobb és stabilabb lesz a szoftver, ami nyilvánvaló hazugság > mutass 1 marketingmilliardos reklamot, ami a security update-eket hirdeti! mindenhonnan! :D pls!
ez nem menti fel a szoftvermultit > nem menti fel az uzemeltetest/ceget, aki nem keszult fel a hibara. hiba van/volt/lesz. 30 eve is volt. pont annak az intel hibanak koszonhetjuk, hogy mara letezik a microcode update, es CPU hibakat lehet szoftveresen befoltozni... :)
a támogatásért fizetett pénzért adta > a diszk se ingyen van a bo'tba! lasd par sorral fentebb. kevered a biztositas intezmenyet a vasarolt termek meghibasodasa esetere adott (csere)garanciaval. :) a termekre van garancia, az adatodra, vagy annak visszaallitasara, a rendszered ujra mukodokepesse tetelere nincs, az kulon "termek", van olyan is, ahol 4 oran belul ottvannak nalad on-site a szerelok. van az a penz. a backupot te intezed. ha akarod. ha nem akarod, akkor ugy jarsz, mint a repteresek...
és az meghal tőle > "Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."
Ez így áldozathibáztatás. > egy nagy lofaszt. az aldozat az, aki ottragad a repteren. a hibas pedig a tarsasag, akinek a szarul megtervezett, szetsporolt infrastrukturaja egy SW bugtol lehal napokra/hetekre. nem is az utasokat hibaztatom, ha nem tunt volna fel :)
az kellene legyen a tanulsagod a sztoribol, hogy kritikus infrastruktura eseten kiemelten fontos a backup recovery plan es annak ideje. mert hiba van/volt/lesz... 3/30/300/3000 eve es ev mulva is.

nem ez a kerdes, hanem ha hiba van, az mivel jar. hiba van/volt/lesz.

Mindkettő kérdés.

GPL, 30+eve nem vallal lofaszt se, helloka! fel kene ebredni!

A GPL még mindig egy licenszszerződés, ráadásul ingyenes szoftverek licenszszerződése. Nem kéne csúsztatni.

aki felelosseget vallal adatvesztesre. csak egyet! :)

Vannak ilyen opciók Western Digital-nál, Seagate-nél, csak kitakarja a szemellenződ. [1] [2]

ez nem igy mukodik!

Ez úgy működik, hogy egyszerre kérdés az, hogy hol volt a backup, meg az, hogy a gyártó hibájából, garanciaidő alatt miért ment tönkre az a hardvereszköz. Ilyen esetben, ha nem volt backup, és rendeltetésszerű használat mellett ment tönkre a HDD, akkor az üzemeltető és a hardvermulti is hibás. Ha volt backup, akkor csak a hardvermulti a hibás. A backupot vissza is kell állítani, ami idő, a kiesett idő pedig pénzben mérhető veszteség, a hardvermultika hibájából.

Tudod, dorsyka, a ok-okozati összefüggéseket marhára nem érdekli, hogy melyik multi vágyik most éppen extraprofitra és zárja ki apróbetűs részekben a saját felelősségét. Attól még a HDD-t gyártó hardvermulti is okozója lesz a kiesésnek, ha műszakilag bizonyíthatóan az ő hibájából ment tönkre a HDD.

teljesen mindegy a hibat ki/mi okozta. el kell haritani, vissza kell allni uzemszeru mukodesre.

Az elhárítás szempontjából van olyan helyzet, hogy tényleg mindegy. Azonban mi arról beszéltünk, hogy ki a hibás érte, és ez által kinek lenne a felelőssége egy üzletileg etikus felállásban.

ez ilyen magyar mentalitas, hogy a tel a hibas, mert nincsenek befoltozva a katyuk, meg, hogy telen nem keszultunk hora, nyaron a melegre... mutogathat ra a kozutkezelo, de ha le van sporolva a TMK, elbaszodik az ut. :)

https://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio

faszsagokat beszelsz.

Nem. Elsősorban a reklámok hazudják le a csillagokat az égről és igyekeznek mindenkivel elhitetni, hogy a szoftverek egyre jobbak és jobbak, hibátlanabbak lesznek.

rendszertervezesi hianyossagok vannak olyan helyeken, ahol nem szabadna.

Ez továbbra sem mentesíti a szar szoftverfrissítést kiadó multit, hiszen nála is rendszertervezési hiányosságok vannak, ha kimehet tőlük egy szar frissítés.

neked ette ki az agyad a reklam, ha ugy erzed ennek barmi koze van ahhoz :D

Azoknak ette ki, akik elhiszik, hogy van hibátlan szoftver. Én nem hiszem el.

mutass 1 marketingmilliardos reklamot, ami a security update-eket hirdeti! mindenhonnan! :D pls!

https://a.te.ervelesi.hibad.hu/mazsolazgatas

Minden olyan reklámot ide értünk, ami a szoftver minőségéről pozitív állításokat fogalmaz meg.

Itt találsz is bőven ilyet: https://www.youtube.com/@CrowdStrike/videos

nem menti fel az uzemeltetest/ceget, aki nem keszult fel a hibara. hiba van/volt/lesz. 30 eve is volt.

Nem menti fel az üzemeltetőt, de a szoftvermultit sem. Más kérdés, hogy egy biztonsági szoftver esetén hogyan sakkozol a frissítésekkel, amiknek a fel nem telepítése jelentheti akár azt is, hogy a biztonsági szoftver nem fog meg egy zsarolóvírust. Így az üzemeltetés alapvetően döntési csapdában van, ha a biztonsági szoftverre hagyatkozik.

pont annak az intel hibanak koszonhetjuk, hogy mara letezik a microcode update, es CPU hibakat lehet szoftveresen befoltozni... :)

Ami elhozta nekünk a processzorok utólagos belassítását (a felhasználó beleegyezése nélkül), és a hátrányok kiszervezését a vásárlóközönségre. Tapsikoljunk, dorsyka? Szerintem nincs rá okunk. Ha nem lenne frissíthető a microcode, vajon megengedhetné magának az Intel a szarul-húgyul implementált microcode-dal üzemelő processzorokat? Lófaszt. Kénytelenek lennének normálisan összerakni és letesztelni, vagy csődbe menni. Így lenne igazságos. A microcode frissítés lehetősége egy félmegoldás, ami még nagyobb babzsákot tol az Intel fősodratú mérnök urainak segge alá, és így fordulhatott elő az is, hogy képesek voltak a 13-14. generációs processzorokat instabil minőségben kiadni.

kevered a biztositas intezmenyet a vasarolt termek meghibasodasa esetere adott (csere)garanciaval. :)

Semmit nem kevertem össze. Ezek alapvetően különálló dolgok, de van olyan hardvermulti (lásd fentebb), aki adatmentést is ad a garancia mellé.

a backupot te intezed. ha akarod. ha nem akarod, akkor ugy jarsz, mint a repteresek...

A backup az adatok elvesztését előzi meg. A backupot vissza is kell állítani. Attól is leáll a reptér és azért a leállásért elsődlegesen a hardvermulti a hibás. Más kérdés, ha az üzemeltetők nem tudják annyi időn belül visszaállítani, mint azt vállalták, akkor már ők is ludasak, de a leállást a CrowdStrike hibája, szarul-húgyul implementált kernelmodulja és a velejéig kaotikus release folyamata okozta. Nincs mentség nekik, csak azért, mert milliárdosabbak egy reptérnél.

egy nagy lofaszt. az aldozat az, aki ottragad a repteren.

Ő is áldozat, igen. Csak ugye neki nem mondogatod, hogy vehetett volna tartalék vonatjegyet is vagy másik reptérről induló járatra egy "backup" jegyet. Érdekesmód a reptéri dolgozókat meg áldozathibáztatod, miközben a CrowdStrike-ot mosdatod.

a hibas pedig a tarsasag, akinek a szarul megtervezett, szetsporolt infrastrukturaja egy SW bugtol lehal napokra/hetekre.

Elsődlegesen a CrowdStrike a hibás, akinek a szarul-húgyul megtervezett, szétspúrkodott QA és kaotikus release folyamatban dolgozó, inkompetens, megélhetési babzsákfejlesztői egy kékhalált okozó kernelmodult képesek voltak kitolni frissítésben.

nem is az utasokat hibaztatom, ha nem tunt volna fel :)

Az tűnt fel, hogy valamiért kényszeredetten mosdatod CrowdStrike-ot. A többi "ki a hibás" kérdésben meg szerintem egyetértünk.

az kellene legyen a tanulsagod a sztoribol, hogy kritikus infrastruktura eseten kiemelten fontos a backup recovery plan es annak ideje.

Ezt magamtól is leszűrtem és a munkám során is ennek megfelelően jártam el az elmúlt években, amióta üzemeltető csapatot vezetek. A kérdés, hogy te tudod-e, hogy a CrowdStrike-nak mi a tanulság, mert látszólag ezzel vannak nehézségeid.

"For one, in-lab data recovery attempt provided" - magyarul beviszik a local Kürt Zrt-be és azok megpróbálják visszaállítani. Vagy sikerül, vagy nem. Semmilyen felelősséget nem vállalnak a sikeres visszaállításra, csak azt igérik hogy megpróbálják.

Ennyit a felelősségvállalásról.

Kritikus rendszernél pedig a folyamatos üzletmenet biztosítására a párhuzamosság a válasz.

Az, hogy garantálják, hogy egy professzionális adatmentést végző cég térítésmentesen ránéz, egy picivel több felelősségvállalás, mint az, hogy kicserélik garanciálisan a winchestert és végérvényesen buktál mindent, ami rajta volt. A KÜRT elég jó eredményekkel dolgozik és ha nem is az adatok 100%-át, de sok mindent vissza tudnak róla állítani, ami több, mint a semmi.

Kritikus rendszernél pedig a folyamatos üzletmenet biztosítására a párhuzamosság a válasz.

Ez is igaz, de továbbra sem mentesíti a CrowdStrike babzsákfejlesztőit.

látszólag ezzel vannak nehézségeid. > nekem veled es a faszsagaiddal vannak nehezsegeim. :) latszolag erted amit irtam es elvben el is fogadod, merthogy valami csapatfonok vagy, akkor a tobbi faszsagod megtarthatod magadnak.

aki adatmentést is ad a garancia mellé. > teljesen kulon termekrol beszelsz.

az üzemeltetők nem tudják annyi időn belül visszaállítani, mint azt vállalták > te tudod mit vallaltak? :) az a repter hibaja, hogy alltak X ideig es basztak rendbehozni az elszarodott infrat. tokmindegy kinek a hibajabol szarodott az el. pont.

Érdekesmód a reptéri dolgozókat meg áldozathibáztatod > az a repter hibaja, hogy alltak X ideig es basztak rendbehozni az elszarodott infrat. tokmindegy kinek a hibajabol szarodott az el. pont.

Elsődlegesen a CrowdStrike a hibás > az a repter hibaja, hogy alltak X ideig es basztak rendbehozni az elszarodott infrat. tokmindegy kinek a hibajabol szarodott az el. pont.

"Az tűnt fel, hogy valamiért kényszeredetten mosdatod CrowdStrike-ot. " > mi lenne ha azzal vitaznal amit irok, nem azzal ami a fejedben van. nem all jol! :)

"biztonsági szoftverre hagyatkozik." "garanciaidő alatt miért ment tönkre az a hardvereszköz" "> ha te nem keszulsz elbaszott szoftverfrissitesre, ransomware-re, hardverhibara, szarul csinalod. pont. teljesen kurvara mindegy ki volt a hibas. az ugyvezeto igazgato klikkel ra a ransomra vagy az utolso mancika, vagy a takaritono huzza ki a szerver racket, hogy bedugja a porszivot, lenyegtelen. a te dolgod az uzletfolytonossag es az adatbiztonsag fenntartasa.

hir sem lett volna az egeszbol, ha a mindenhol 1-2-3 oran belul meg lett volna a backupbol restore es folyik az elet tovabb... 2024-ben nem itt tartunk.

latszolag erted amit irtam es elvben el is fogadod, merthogy valami csapatfonok vagy, akkor a tobbi faszsagod megtarthatod magadnak.

Én leírtam a véleményemet a témában, te pedig szokás szerint idejöttél offolni, kötekedni és milliárdos multit mosdatni.

teljesen kulon termekrol beszelsz.

A HDD-k mellé adott garanciális opcióról beszélek, amit úgy kapsz meg, mint a szerviz- vagy cseregaranciát (ami szintén két külön dolog).

az a repter hibaja, hogy alltak X ideig es basztak rendbehozni az elszarodott infrat. tokmindegy kinek a hibajabol szarodott az el. pont.

Meg a CrowdStrike hibája.

mi lenne ha azzal vitaznal amit irok, nem azzal ami a fejedben van. nem all jol! :)

Belső Mérnök Úr már sokszor próbált így terelni. Nem jött be neki se. Mi lenne, ha megértenéd, amit írok, nem csak write-only minősítgetnél?

ha te nem keszulsz elbaszott szoftverfrissitesre, ransomware-re, hardverhibara, szarul csinalod

Ebben egyetértünk.

teljesen kurvara mindegy ki volt a hibas.

Kurvára nem mindegy, mert a CrowdStrike is szarul csinálta. Te mégis mosdatod.

hir sem lett volna az egeszbol, ha a mindenhol 1-2-3 oran belul meg lett volna a backupbol restore es folyik az elet tovabb...

Attól még, hogy nem okoz teljes összeomlást és egésznapos kiesést, okoz pluszköltséget és megfeszített munkaórákat szerte a világon minden cégnek, szervezetnek, akik megkapták a frissítést.

Mi lett volna, ha mosdatott milliárdos multikád tolja bele azt a 3 óra munkát, mielőtt kinyomja a szar frissítést? Esetleg nem kellett volna százezreknek beletenni azt a 3 óra munkát? Elég lenne, ha csak ezt megérted, hogy a CrowdStrike szar frissítésének nagyobb impactja van az egész világra nézve, mint egy reptéri leállásnak. Az egész világ többet fizet backupolva is a visszállításért, hogy ne álljon le kritikus infrastruktúra, mint amennyi kárt okoz egy nem backupolt, leállt kritikus infrastruktúra. Ezért úgy etikus, hogy a CrowdStrike is felelősségre van vonva.

milliárdos multit mosdatni. > mi lenne ha azzal vitaznal amit irok, nem azzal ami a fejedben van. nem all jol! :)
A HDD-k mellé adott garanciális opcióról beszélek > ami egy kulon termek. mint az on-site 4 oras hwsupport. pl. ja, nem is annyiba kerul :)
Meg a CrowdStrike hibája. > az a repter hibaja, hogy alltak X ideig es basztak rendbehozni az elszarodott infrat. tokmindegy kinek a hibajabol szarodott az el. pont.
Kurvára nem mindegy > de. az a repter hibaja, hogy alltak X ideig es basztak rendbehozni az elszarodott infrat. tokmindegy kinek a hibajabol szarodott az el. pont. mint irtam is, ha 1-2-3 oran belul mentek volna a gepek,  hir sincs az egesz bakirol. annyit egy repter/MAV default ugymenetben is osszehoz :)
Attól még, hogy nem okoz teljes összeomlást és egésznapos kiesést, okoz pluszköltséget és megfeszített munkaórákat szerte a világon minden cégnek, szervezetnek, akik megkapták a frissítést. > egy restore-ra ranyomni, majd varni 20-30 percet?
Mi lett volna > #milettvolnaha-val tele a padlas. mi lett volna ha a repter (es a tobbiek) rendes infrat uzemeltet? hir sem lett volna. pont.
a CrowdStrike is felelősségre van vonva. > ezt majd lejogaszkodjak a jogaszkodok, neked az a dolgod IT uzemeltetokent, hogy az uzletfolytonossag es az adatbiztonsag fenn legyen tartva. ennek a tortenetnek ez a tanulsaga. mutogathatsz a majkroszoftra meg a kradsztrajkra meg a kurva mongo'lokra, deminek.

mi lenne ha azzal vitaznal amit irok, nem azzal ami a fejedben van. nem all jol! :)

Belső Mérnök Úr már sokszor próbált így terelni. Nem jött be neki se. Mi lenne, ha megértenéd, amit írok, nem csak write-only minősítgetnél?

ami egy kulon termek. mint az on-site 4 oras hwsupport. pl. ja, nem is annyiba kerul :)

Egy garanciában adott "külön" termék.

az a repter hibaja, hogy alltak X ideig es basztak rendbehozni az elszarodott infrat.

Meg a CrowdStrike hibája.

tokmindegy kinek a hibajabol szarodott az el. pont.

Kurvára nem mindegy, mert a CrowdStrike is szarul csinálta. Te mégis mosdatod.

egy restore-ra ranyomni, majd varni 20-30 percet?

Hamar 20-30 perc lett az 1-2-3 órából. :) Az érvként felhasználni próbált álnaivitásodból látszik a legjobban, hogy a büdös kurva életben nem üzemeltettél kritikus infrastruktúrát.

mi lett volna ha a repter (es a tobbiek) rendes infrat uzemeltet? hir sem lett volna. pont.

A probléma nem a reptérnél kezdődött, hanem kedvenc multikádnál. Mivel, ha lett volna "rendes" infrája a repülőtérnek, akkor is pluszmunkát jelentett volna nekik a tucatnyi kékhalálozó gép visszaállítása és ez alatt az idő alatt nem lehetett volna dolgozni.

ezt majd lejogaszkodjak a jogaszkodok, neked az a dolgod IT uzemeltetokent, hogy az uzletfolytonossag es az adatbiztonsag fenn legyen tartva. ennek a tortenetnek ez a tanulsaga.

A CrowdStrike babzsákfejlesztőinek pedig az (lett volna) a dolga, hogy ne nyomjanak ki egy e2e tesztekkel triviálisan megfogható, szarul-húgyul összetákolt, kernelszintű crash-t okozó frissítést.

mutogathatsz a majkroszoftra meg a kradsztrajkra meg a kurva mongo'lokra, deminek.

Minek? Annak, hogy elsősorban ők a hibásak. Igen, a Microsoft is, mert lehetőséget adott az egész rendszerét összeomlasztani 3rd-party szutyok által.

Ebben a történetben elég sokan hibásak, te most mégis az üzemeltető macikra kennéd az egészet. Igen, ők is elceszték, de messze nem csak ők.

minősítgetnél > "szemellenződ" "álnaivitásodból látszik" "Tapsikoljunk" "szarul-húgyul" "mosdatod" "valamiért kényszeredetten" "Ezt magamtól is leszűrtem" "a büdös kurva életben nem üzemeltettél" "látszólag ezzel vannak nehézségeid" > #fogadjisten. meg mindig: azzal amit irok, pls! :)
"külön" termék. > eljen, eljutottunk ide is. \o/
Meg a CrowdStrike hibája. > meg a mongoloke!
Kurvára nem mindegy > csak a vegeredmeny szempontjabol. teljesen mindegy kinek a hibaja, nem volt idoben rendezve.
Hamar 20-30 perc lett az 1-2-3 órából > 1-2 ora ticket tologatas, telefonban liftzene hallgatas, 20-30 perc melo. nagy kornyezetben ez igy mukodik.
Mivel, ha lett volna "rendes" infrája a repülőtérnek, akkor > nem lett volna hir egy bagatell szoftverhibabol. es egy rm /drivec/windoz/kladsztrajk.sys-bol.
A CrowdStrike babzsákfejlesztőinek pedig az (lett volna) a dolga > #milettvolnaha strikes nr2.
Minek? Annak, hogy elsősorban ők a hibásak. Igen, a Microsoft is, mert lehetőséget adott az egész rendszerét összeomlasztani 3rd-party szutyok által. > Minek? Annak, hogy elsősorban ők a hibásak. Igen, a repter is, mert lehetőséget adott az egész rendszerét összeomlasztani 3rd-party szutyok által. majd cseszett visszaallitani a mukodest ertelmezheto ido alatt.
Ebben a történetben elég sokan hibásak > foleg a repter (uzemeltetese), hogy megbizott egy szoftvberben.
te most mégis az üzemeltető macikra kennéd az egészet > nem. probalj meg azzal vitazni amit irok, thx!
Igen, ők is elceszték, de messze nem csak ők. > viszont a mukodes visszaallitasa nem a kladsztrajk, nem a majkroszoft es nem a mongolok feladata. lett vo'na. majd most megtanuljak. vagy nem, mert meg igy is kisebb koltseg volt a kieses, mint egy rendes infra. oszt'akko' a kovi ilyennel ugyanugy megall majd minden. biztositas ugyis van. utasok meg pingvineznek ahogy akarnak vagy tudnak :)

mellekesen jegyzem meg, ha nem a legolcsobb szar jegyet veszed meg, mint kovacsakosek romaniaba menet, akkor az utazasi iroda intez neked szallast, buszt, kajat, stb-t ha lekesed a jaratod vagy tortenik vele valami. 50+ eve is volt mar lehetoseged ilyenre olyan helyeken, ahol az emberek szoktak is utazni. :) #vanazapenz. csak se az utas, se a tarsasag nem szeret kolteni. c'est la vie. nem kell a fapadot valasztani mindenaron (uzemeltetesben sem!). ehhez nem kell torvenyi szabalyozas, amivel inditottal. hint: UK Civil Aviation Authority (CAA). csak igeny ra.

nekem az jott le, hogy inkabb mutogassunk mindenki masra, mer' az meno! vegulis akkor szerintem brusszelsorosmoszkvamongolokkina a hibas! janem. csak probalja mind megmagyarazni a bizonyitvanyt. :) ha ez helyett mondjuk fokuszalna arra, hogy rendesen vegezze a sajat do'gat, lehet elorebb vo'nank? :)

Wendell eleg jol osszefoglalja mi is a baj :) tl;dr: serulekeny infra. annyi, hogy epp a CS szoftvere volt a fogpiszkalo, ami megreccsent a gepezetben es ettol borult minden is. lehetett volna ezer mas.

eljen, eljutottunk ide is. \o/

Örülök, hogy felfogtad végre, hogy mit mondok.

Meg a CrowdStrike hibája. > meg a mongoloke!

A South Park-ban lehet. A valóságban a CrowdStrike és az üzemeltető macik hibája, együttesen.

csak a vegeredmeny szempontjabol. teljesen mindegy kinek a hibaja, nem volt idoben rendezve.

Nem a végererdmény szempontjából, hanem a helyreállítás szempontjából mindegy. Ok-okozat és felelősség szempontjából nem mindegy. Én erről beszéltem.

1-2 ora ticket tologatas, telefonban liftzene hallgatas, 20-30 perc melo. nagy kornyezetben ez igy mukodik.

Az még mindig 3 óra kiesés mindenhol, ahol beüt a babzsákcrach.

nem lett volna hir egy bagatell szoftverhibabol. es egy rm /drivec/windoz/kladsztrajk.sys-bol.

Ettől még pluszköltséget kellett volna mindenkinek fizetnie, aki CrowdStrike-ot használ. Tehát, a CrowdStrike a saját, tesztrendszeren való spúrkodását szervezi ki több tízezer ügyfélnek, ami 29 ezer ügyfél esetén 87 000 munkaóra (maintenance window). Nekik vajon hány órába telt volna normálisan letesztelni a frissítést? Ennél többe, vagy kevesebbe? Szerintem kevesebbe. Arrogáns multiról beszélünk, amikor a saját költségén akar spúrkodni, cserébe másoknak súlyos pluszköltségeket okoz. Ezt esetleg hajlandó vagy egyszer és mindenkorra megérteni?

majd cseszett visszaallitani a mukodest ertelmezheto ido alatt.

Ezért mondtam, hogy az üzemeltető maci is hibás, meg a CrowdStrike is. Csak ez neked nem tetszik, mert az arrogáns multit mindenáron fel akarod menteni. Ha visszaállította volna belátható időn belül, akkor csak a CrowdStrike lenne hibás.

foleg a repter (uzemeltetese), hogy megbizott egy szoftvberben.

Elsősorban a CrowdStrike a hibás, hogy megbízott a babzsákfejlesztőiben. Másodsorban a reptér üzemeltetése.

te most mégis az üzemeltető macikra kennéd az egészet > nem. probalj meg azzal vitazni amit irok, thx!

Pedig azokra kented. A reptér üzemeltetőjére.

mellekesen jegyzem meg, ha nem a legolcsobb szar jegyet veszed meg, mint kovacsakosek romaniaba menet, akkor az utazasi iroda intez neked szallast, buszt, kajat, stb-t ha lekesed a jaratod vagy tortenik vele valami.

Mellesleg megjegyzem, hogy ennek a történetnek pont az a tanulsága, hogy a legolcsóbb szar kategóriás jegy árusítását tiltani kéne. Ahogy a CrowdStrike sajátfelelősség-kizárását is.

#vanazapenz. csak se az utas, se a tarsasag nem szeret kolteni.

Ki kell söpörni az olcsó silány szar kínálatot a piacról, a többit a verseny megoldja. Ami a légitársaságok között azért még megvan.

vegulis akkor szerintem brusszelsorosmoszkvamongolokkina a hibas!

Nem mondtam se Brüsszelt, se mongolokat. Ahogy Belső Mérnök Úr mondaná: a fantáziáddal vitatkozol.

elorebb vo'nank? :)

Lennénk, ha néhány alapvető ok-okozati összefüggést és üzleti etikai szempontot hajlandó volnál megérteni, multimosdatás helyett.

Az még mindig 3 óra kiesés mindenhol, ahol beüt a babzsákcrach. > ezt ok CR nelkul is tudjak hozni. akar napokat is. :)
Arrogáns multiról beszélünk, amikor a saját költségén akar spúrkodni > jah, a repterrol.
Csak ez neked nem tetszik > mondd meg nekem mi tetszik, mert tudod. emlitettem mar, hogy azzal vitazz amit irok? jaigen! :)
Elsősorban a CrowdStrike a hibás, hogy megbízott a babzsákfejlesztőiben. Másodsorban a reptér üzemeltetése. > elsosorban a repter a hibas, hogy abbol indult ki nem lesz hiba. osszerakta a kartyavarat, ledolt. utana meg nem volt ember aki ertelmes ido alatt visszaepitse. igy jart.
Pedig azokra kented. A reptér üzemeltetőjére. > nem. emlitettem mar, hogy azzal vitazz amit irok? jaigen! :)
Mellesleg megjegyzem, hogy ennek a történetnek pont az a tanulsága, hogy a legolcsóbb szar kategóriás jegy árusítását tiltani kéne. > mert miert is? ha nekem belefer 2-3 plusz nap nyaralas, ki nem szarja le, hogy nem ment a repulo? :) ha fontos, akkor meg vegyel rendes szolgaltatast es ne sporolj ezen.
Ki kell söpörni az olcsó silány szar kínálatot a piacról > kereslet van ra, igy kinalat is. welcome to the market!
Nem mondtam se Brüsszelt, se mongolokat. > en pedig nem mondtam, hogy mondtad, hanem irtam egy szarkazmust. a sajat nevemben. leeshetett volna, nem esett. hint: "akkor szerintem". emlitettem mar, hogy azzal vitazz amit irok? jaigen! :)
Lennénk, ha  > nem szemelyeskednel es azzal probalnal vitazni, amit irok es amit Wendell is mond. sajnos azzal nem tudsz, csak frocsogod a kepzelgeseid meg a multibuzulasod. :)

sajnalom, hogy szamodra mas a tanulsag, mint Wendell szerint, miszerint elbaszott kritikus infak tomkelege van a vilagban, amik egy bagatell hiba miatt napokig-hetekig kepesek megallni. csak egy klasszikus pelda... 10 napig tartott! 2024-ben!
ja nem hirerteku, mert "csak egy ransomware"... LOL!

nem. emlitettem mar, hogy azzal vitazz amit irok? jaigen! :)
ugye, az megvan, hogy van olyan legitarsasag, aki napokig keptelen volt visszaallni? :D

ez is a CS sara, janem...
ajanlom figyelmedbe a grafikont, 1k feletti a torolt jaratok szama/nap, csak az usaban. :)
... https://www.flightaware.com/miserymap/

nem. emlitettem mar, hogy azzal vitazz amit irok?

Azzal vitáztam, de feleslegesen, mert megint játszod a büszke értetlent, hogy kötekedhess.

ugye, az megvan, hogy van olyan legitarsasag, aki napokig keptelen volt visszaallni? :D

Igen, megvan. És? Ez az az eset, amikor a CrowdStrike mellett a légitársaság üzemeltető macijai is hibásak.

ajanlom figyelmedbe a grafikont, 1k feletti a torolt jaratok szama/nap, csak az usaban. :)

Ez sem mentesíti a CrowdStrike-ot. Ha ezt az egyet képes lennél felfogni, nem lenne vita, mert gyakorlatilag egyetértenénk.

Azzal vitáztam > nem.
de feleslegesen > igen.
játszod a büszke értetlent > nem
kötekedhess > nem kotekszem, helyreteszlek mikor a fejedben levo faszsagokat huzod ram. azzal vitazz, amit irok. thx.
Igen, megvan. > akkor tanulj belole. lepjunk tovabb.
a CrowdStrike mellett > a CS nem tehet arrol, hogy egy het mire rendbebassza a repter az infrajat. remelem ezt nem szeretned vitatni. :)
nem lenne vita > meg mindig olyannal vitazol, amit nem mondtam. helyreteszlek mikor a fejedben levo faszsagokat huzod ram. azzal vitazz, amit irok. thx.

melyikuk miatt allt napokig? :)

Mindkettő miatt.

ha a repteri [insert all CS victims here] infra normalis lett volna es par oran belul minden szipiszuper, lett volna-e evtizedes hir?

Ha a CrowdStrike nem babzsákfejlesztőkkel, hanem valódi szakemberekkel release-eli a frissítést, és a szar repteres infrára rámegy egy jó frissítés, lett-e volna évtizedes hír?

Mindkettő miatt. > ez konkretab hazugsag. a CS miatt MEGallt. az uzemeltetes miatt allt napokig. ereztem en, hogy nem vagod a kulonbseget! :) szivesen!
Ha a CrowdStrike nem babzsákfejlesztőkkel, hanem valódi szakemberekkel release-eli a frissítést, és a szar repteres infrára rámegy egy jó frissítés, lett-e volna évtizedes hír? > nem indulhatsz ki abbol, hogy nem lesz hiba! uzemeltetoi oldalrol ez a dolgod... a pelda is jol mutatja :) elbasztak, nabumm. meg kell javitani (rm 1db file, b+!!!) vagy backupbol visszaallni. ennyi.

ha a repteri [insert all CS victims here] infra normalis lett volna es par oran belul minden szipiszuper, lett volna-e evtizedes hir?
ugyanide beleveheted a ransomware attackokat is. es szepen valaszolhatsz a kerdesre. kerdes helyett valasszal! :)

ez konkretab hazugsag. a CS miatt MEGallt. az uzemeltetes miatt allt napokig. ereztem en, hogy nem vagod a kulonbseget! :) szivesen!

Ha a CS miatt nem állt volna meg, nem állt volna napokig. A kiesés elsődleges okozója a CS.

nem indulhatsz ki abbol, hogy nem lesz hiba!

Ebben most is egyetértünk és az elején is egyetértettünk. Ugyanakkor, az első szereplő a történetben, aki abból indult ki, hogy nem lesz hiba, az a CrowdStrike, mivel nem tesztelték meg normálisan a saját szutykukat.

uzemeltetoi oldalrol ez a dolgod...

Így van. Az üzemeltetők inkompetenciája azonban nem validálja a CS babzsákfejlesztőinek inkompetenciáját. Attól még ugyanúgy elszúrta a CS is.

elbasztak, nabumm. meg kell javitani (rm 1db file, b+!!!) vagy backupbol visszaallni. ennyi.

Az ennyi az pont ugyanúgy plusz munkaóra és pluszköltség, ami ugyanúgy a CS lelkén szárad. Akkor is, ha volt backup. Ráadásul a világ több tízezer cégénél, tehát több tízezerszer 3 munkaóra.

ha a repteri [insert all CS victims here] infra normalis lett volna es par oran belul minden szipiszuper, lett volna-e evtizedes hir?

https://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio

Hogy a tech-lakájmédia mit fúj fel és mit nem, teljesen irreleváns kérdés abból a szempontból, hogy az ok-okozati láncolatban ki indította a lavinát.

olvasod is amit irok, mr. write only kapitany? :)
aki abból indult ki, hogy nem lesz hiba, az a > repter uzemeltetese. ha nem igy lett volna nem alltak volna napokig. teccikerteni? :)
tehát több tízezerszer 3 munkaóra. > egy jo rendszeren ez egy klikk. egy rosszabbon liveUSB bedug es var amig megtortenik az rm/restore. a repter eseten meg napokig pingvinezes ment. ennyike.
ha a ransomware miatt alltak volna, akkor a ransomware gyartojatol kerned a kompenzaciot? :D ha hw-hiba miatt akkor a...? :) egyik sem tehet az uzemeltetes hianyossagairol.
https://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio > ez faszsag. egy igen/nem-et kellene beirnod a kerdesre, csak keptelen vagy ra :) probald ujra! :)

ha a repteri [insert all CS victims here] infra normalis lett volna es par oran belul minden szipiszuper, lett volna-e evtizedes hir?

Ha nem lett volna évtizedes hír, akkor is több tízezer plusz munkaóra lett volna az ügyfeleknek biztosítani, hogy ne legyen akkora leállás, mint amit az érintett reptérnél láttunk. Amiről csak és kizárólag a CrowdStrike tehet, ergo felelősségrevonhatóvá kell tenni - erről szól a topik.

Egy igazságos világban a reptéri leállásért mindkettő felelősségre lenne vonva. A CrowdStrike és a reptér üzemeltetőmacis beszállítója is.

( zaphodb v | 2024. 07. 29., h – 23:51 )

A fejlesztő / cég teljes felelősséggel tartozik

helyett, csak a szoftver/előfizetés árát adja vissza.

nincs aláírásom

Ha felbérelsz egy biztonsági céget, hogy biztosítsa az irodád, és a megbízott cég személyzete tönkreteszi a beléptetőrendszert, ami miatt senki nem tud bemenni és megáll az élet az irodádban, akkor is csak ugye a megbízási díjat kéred vissza és véletlenül sem gondolkodsz el kártérítési igényen, sőt a szerződéskötéskor is elhesegeted az összes erre irányuló gondolatod, igaz?

ami miatt senki nem tud bemenni és megáll az élet az irodádban > akkor eloszor is a tuzvedelmiseket hivnam, hogy birsagoljanak egy szepet, hogy hol van a mindig szabadon megkozelitheto/hasznalhato menekulesi utvonal :P

ahol valaki ki tud jonni, ott be is lehet jutni.

Rendben, megbírságolták a céget. Az iroda kire fogja tovább hárítani a bírságot, mondjuk akár peres úton? Véletlenül sem a biztonsági cégre, amelyik elbaszta a rendszert, igaz? Nem beszélve arról, hogy ha megáll a veszélyeztetés vétségének gyanúja, akkor automatikusan előveszik a biztonsági céget is. Ahogy ilyenkor elő kéne venni drága babzsákfejlesztős multikáinkat is.

Az iroda kire fogja tovább hárítani a bírságot > a biztonsagi ceg baszta el a tuzbiztonsagi tervet is? koze sincs hozza. ne legyel kreten, pls! :)
ha valahol nem lehet be/kijutni ha lehal egy belepteto rendszer, ott esszencialis problemak vannak. de rohadtul nem a belepteto rendszerrel. :)
nem tudom mikor voltal utoljara - elvben felelos vezetokent - tuzvedelmi oktatason, javaslom potold hamarost! :P

"Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."

a biztonsagi ceg baszta el a tuzbiztonsagi tervet is? koze sincs hozza. ne legyel kreten, pls! :)

Azt is elbaszta valaki, akire tovább lesz hárítva a bírság. Te vagy akkora kretén, hogy ezt nem fogod fel, hogy így tisztességes.

ha valahol nem lehet be/kijutni ha lehal egy belepteto rendszer, ott esszencialis problemak vannak.

Ha valahonnan kimegy egy kernel crasht okozó patch, ott esszenciális problémák vannak. Te vagy akkora kretén, hogy ezt nem fogod fel.

nem tudom mikor voltal utoljara - elvben felelos vezetokent - tuzvedelmi oktatason, javaslom potold hamarost! :P

Minden évben vagyok, mivel kötelező. Ennek viszont nincs köze ahhoz, hogy nekiálltál megint orbitálisat csúsztatgatni, szándékosan összemosni össze nem tartozó dolgokat, és épp azon kötekedsz, hogy mi van a tűzvédelmi tervvel, miközben arról beszéltem, hogy megáll a termelés a beléptetőrendszer miatt. A csökött agyaddal esetleg felfoghattad volna (de erre sem voltál képes), hogy ebből a lényeg nem az, hogy hogy jutnak ki az emberek az épületből (nyilván a vészkijáratokon), hanem az, hogy áll a termelés.

Azt is elbaszta valaki > te meg valaki masra kented volna. :) szokasod az ilyesmi. csak ebben a topicban a harmadik. :D
szándékosan összemosni össze nem tartozó dolgokat > epp ezt tetted a szalban :) ramutattam, most picsogsz.
azon kötekedsz, hogy mi van a tűzvédelmi tervvel, miközben arról beszéltem, hogy megáll a termelés a beléptetőrendszer miatt > nem all meg. ha megall, teljesen mas a gond (pl. szar a tuzvedelmi terv). olyan nincs, hogy valaki bent marad valahol, mert ledoglik egy belepteto.
hanem az, hogy áll a termelés. > nem all. olyan nincs, hogy valahonnan nem tudsz kijonni/bemenni, mert all egy belepteto.
hint: "hogy hogy jutnak ki az emberek az épületből" > ott be is jutnak.

fogadd el, szar peldat hoztal most pedig magyarazkodsz. :) ertem en, hogy kellemetlen mikor visszanyal a fagyi, de viseld! ha mar mastol ezt varod... :)
"Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."

te meg valaki masra kented volna. :) szokasod az ilyesmi. csak ebben a topicban a harmadik. :D

Én csak felsoroltam, hogy kik hibáztak és így kiknek kéne felelősségre vonni. Neked nem tetszik, hogy a multika is benne van a listában. Szokásod az ilyesmi.

szándékosan összemosni össze nem tartozó dolgokat > epp ezt tetted a szalban :) ramutattam, most picsogsz.

Megint a tükörbe nézel, miközben kommentelsz.

nem all meg. ha megall, teljesen mas a gond (pl. szar a tuzvedelmi terv). olyan nincs, hogy valaki bent marad valahol, mert ledoglik egy belepteto.

Nem az volt a lényeg, hogy bent marad-e vagy nem marad bent. Az volt a lényeg, hogy senki nem tud bemenni dolgozni, ezért megáll az élet a cégnél.

nem all. olyan nincs, hogy valahonnan nem tudsz kijonni/bemenni, mert all egy belepteto.

Mert életedben nem láttál még irodaházat sem.

fogadd el, szar peldat hoztal most pedig magyarazkodsz. :) ertem en, hogy kellemetlen mikor visszanyal a fagyi, de viseld! ha mar mastol ezt varod... :)

Nem hoztam szar példát, csak szándékosan kifacsartad, elferdítetted, hogy beleköthess és multit mosdathass. Ahelyett, hogy megértetted volna a lényeget. A példába azt is beleértettem (csak ez se ment át), hogy a biztonsági cég bénázása miatt nem lehet bemenni az épületbe. Ezt érthetted volna úgy is, hogy ők sem hajlandóak senkit beengedni beléptetőrendszer nélkül. Nem így értetted, csak azért, hogy megtámadhasd, beleköthess, és minősítgethess.

Egyébként jó példa vagy szar példa nélkül is elsődlegesen a CrowdStrike a hibás a leállásokért. Másodlagosan pedig az, akinek nem volt backupja, vagy B terve.

"Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."

Én csak felsoroltam, hogy kik hibáztak > lofaszt sem soroltal fel, rakented a biztonsagi cegre: "a megbízott cég személyzete tönkreteszi a beléptetőrendszert, ami miatt senki nem tud bemenni és megáll az élet az irodádban"
Neked nem tetszik, hogy a multika is benne van a listában. > milyen lista? :D semmilyen lista nem volt. lofaszt sem soroltal fel, rakented a biztonsagi cegre: "a megbízott cég személyzete tönkreteszi a beléptetőrendszert, ami miatt senki nem tud bemenni és megáll az élet az irodádban"
Az volt a lényeg, hogy senki nem tud bemenni dolgozni > ahol valaki ki tud jonni (tuzvedelmi eloiras), ott be is tud menni. szar a peldad. ennyi.
Mert életedben nem láttál még irodaházat sem. > ha dolgoztal volna valaha automata nem H2O hatoanyagu tuzvedelmi berendezessel ellatott, amde fokozott biztonsagi auditalt helyisegben, talan lenne fogalmad rola. en helyi ero voltam ilyen helyen es az olyanoknak, mint te magyaraztam el mi a procedura es mit tegyen ha nem szeretne megdogleni ha jonne a fire alarm. na, en ennyire nem lattam meg irodahazat. se! :) a szemelyeskedesed egyebkent is bullshit, jelen esetben az egyik legnagyobb melleloves. legyszives mellozd! :)
Nem hoztam szar példát > de. eletszerutlen.
kifacsartad > az elet tette.
elferdítetted > az elet tette.
beleköthess > bele is kotottem, azota magyarazkodsz, ahelyett, hogy azt mondtad volna: bocs, szar pelda volt, haladjunk tovabb. :)
ők sem hajlandóak senkit beengedni > navarj, ez mar teljesen mas jogi kategoria, ez szandekos karokozas! :) ergo szar pelda. kulonosen, mivel a topik sem errol szol.
megtámadhasd > vitaztam vele, mert eletszerutlen.
beleköthess > bele is kotottem, azota magyarazkodsz, ahelyett, hogy azt mondtad volna: bocs, szar pelda volt, haladjunk tovabb. :)
minősítgethess > fejlodni kellene, magyarazkodas helyett. mondhattad volna: bocs, szar pelda volt, haladjunk tovabb. :)
akinek nem volt backupja, vagy B terve. > az a disaster recovery (gy.k: hibaelharitas) hianyossaga. nem a hiba oka. :)

itt annyi tortent, hogy volt egy eletszerutlen peldad, en leirtam mitol az es en hol kezdenem a helyzet megoldasat. nem kotelezo atmenni szajzaras acsargasba. :) peace!

hint/jotanacs: ha nem allnal bele az orbitalis butasagaidba, nem kellene folyton eszervek hijan szemelyeskedesekkel tamadnod a masikat, terelned, masok szajaba adogatni olyanokat, amiket nem allitott es magyarazkodnod. :)

de "Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."

lofaszt sem soroltal fel, rakented a biztonsagi cegre

A CrowdStrike tekintetében soroltam fel. Neked nem tetszett, hogy multiék is szerepelnek a lista első helyén.

ilyen lista? :D semmilyen lista nem volt.

Ilyen lista: CrowdStrike, reptér, infra-üzemeltetők

lofaszt sem soroltal fel, rakented a biztonsagi cegre

Az egy fiktív példa volt, hogy jobban megértsd, miért hibás a CrowdStrike. Ez neked sajnos nem sikerült.

ahol valaki ki tud jonni (tuzvedelmi eloiras), ott be is tud menni. szar a peldad. ennyi.

Nem feltétlenül tud, de a példám is teljesen mindegy már, mert ismét nem akarod megérteni.

ha dolgoztal volna valaha automata nem H2O hatoanyagu tuzvedelmi berendezessel ellatott, amde fokozott biztonsagi auditalt helyisegben, talan lenne fogalmad rola.

Most is ilyen helyen dolgozom.

en helyi ero voltam ilyen helyen es az olyanoknak, mint te magyaraztam el mi a procedura es mit tegyen ha nem szeretne megdogleni ha jonne a fire alarm. na, en ennyire nem lattam meg irodahazat. se! :)

Kurva nagy jampi vagy, de továbbra is arról van szó, hogy a bejutás ellehetetlenülése miatt áll a termelés. Te belekötöttél egy totálisan irreleváns dologba ("se ki, se be", mint szerencsétlen megfogalmazás).

a szemelyeskedesed egyebkent is bullshit, jelen esetben az egyik legnagyobb melleloves. legyszives mellozd! :)

Megint a tükröt nézed, miközben kommentelsz.

Nem hoztam szar példát > de. eletszerutlen.

Nem az, csak a lényegre kellett volna figyelni, dorsyka.

elferdítetted > az elet tette.

Te tetted.

bele is kotottem, azota magyarazkodsz, ahelyett, hogy azt mondtad volna: bocs, szar pelda volt, haladjunk tovabb. :)

Nem volt szar példa, a "se ki, se be" megfogalmazás volt szerencsétlen, mert lehetőséget adott rá, hogy beleköss. Azt még mindig nem vagy képes felfogni a csökött agyaddal, hogy a lényege a példának az volt, hogy egy biztonsági cég balfaszkodása miatt nem tudnak bejutni az épületbe az ott dolgozók, mert nem működik a beléptetőrendszer és mellette a szekusok sem engednek be senkit, mert nincs felhatalmazásuk kifeszegetni az ajtókat, meg kulcsuk sincs hozzá, se nem tudják a belépőkártyákat leolvasni, hogy egyértelműen azonosítsák a belépőket.

hint/jotanacs: ha nem allnal bele az orbitalis butasagaidba, nem kellene folyton eszervek hijan szemelyeskedesekkel tamadnod a masikat, terelned, masok szajaba adogatni olyanokat, amiket nem allitott es magyarazkodnod. :)

Ha nem mosdatnád a multikat, nem kellene folyton észérvek híján, kötekedned velem, nem kellene szándékosan nem a lényegi részeit figyelembe venned a példáimnak és a szerencsétlen megfogalmazásokba belekapaszkodni kiforgatnod a vitapartnered mondandóját. Hiszen már rég megértetted volna, hogy a CrowdStrike is ugyanannyira hibás volt a reptéri leállásokban, mint azok az üzemeltetők, akiknek nem volt B tervük.

A CrowdStrike tekintetében soroltam fel. > ... koncentralj arra, amit irok :) csapongsz! :)
Ilyen lista: > utolag nem er! koncentralj a threadre! :)
Az egy fiktív példa volt > megmutattam hol santit, haladjunk tovabb :) "Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."
Nem feltétlenül tud > amit peldaztal az eredeti felvetesed atkoltve egy szandekos karokozassal. nemar :) "Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."
Most is ilyen helyen dolgozom. > akkor csak a hupon vagy ilyen hulye? :D
Te belekötöttél egy totálisan irreleváns dologba > bele, eletszerutlen volt a peldad, most is az :) "Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."
Megint a tükröt nézed, miközben kommentelsz. > #fosszarhugy
Nem az > de, az. meg mindig. haladj tovabb. "Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."
Te tetted. > ... szar pelda volt, eletszerutlen, most is az. haladj tovabb :) vagy "Felőlem amúgy azt csinálsz a véleményeddel, amit akarsz, de ha már arra vered itt a bozontost, hogy te minden szart felvállalsz, akkor vállald már fel azt is, milyen elbaszott fos hasonlatokat vagy képes hozni, ahelyett, hogy megpróbálod kimagyarázni."

és ennek ellenére a cég szekusai sem engednek be senkit, mert nincs felhatalmazásuk kifeszegetni az ajtókat, meg kulcsuk sincs hozzá. > hozzakoltesz az eredeti sztorihoz! :) es amit irsz masik jogi kategoria, ami miatt a szekusokat seggbe kellene... :)
Ha nem mosdatnád a multikat > nem teszem, azzal vitazz, amit irok, ne azzal ami a fejedben van!
nem kellene folyton észérvek híján, kötekedned velem > eszervek menten bizonyitottam, hogy szar peldat hoztal, most itt rugozol rajta oldalakon keresztul :) engedd el, mondd, hogy "oh, erre nem gondoltam :)" es ennyike.
nem kellene szándékosan nem a lényegi részeit figyelembe venned a példáimnak > mi a lenyeg? oldalakat irogatsz arrol, hogy buta peldat hoztal, ami a valsoagban nem fordulhat elo, hacsak nem olyan utolag hozzakoltott sci-fi-ben vagyunk, ahol a szekusok mar "enyem a var, tied a lekvar"-t jatszanak onhatalmulag :D :D :D
szerencsétlen megfogalmazásokba belekapaszkodni > nem volt szerencsetlen a megfogalmazas, a pelda is jo, csak valami masra. :)
kiforgatnod a vitapartnered mondandóját > ideztelek, nincs kiforgatva semmi, sot a sajat mondatodat folytattam, hogy ilyenkor en mit tennek. tudod, a valo eletben:

ami miatt senki nem tud bemenni és megáll az élet az irodádban > akkor eloszor is a tuzvedelmiseket hivnam, hogy birsagoljanak egy szepet, hogy hol van a mindig szabadon megkozelitheto/hasznalhato menekulesi utvonal :P

ahol valaki ki tud jonni, ott be is lehet jutni.

Hiszen már rég megértetted volna, hogy a CrowdStrike is ugyanannyira hibás volt a reptéri leállásokban, mint azok az üzemeltetők, akiknek nem volt B tervük. > teljesen masban hibasak. ezt kellene megertsd :)

a szekusok elkurjak a beleptetot: CS hiba
az iroda uzemeltetese megnyitja a veszkijaratokat: javitas. instant. ha balfaszok voltak (es egyebkent nem tartottak be a tuzvedelmi eloirasokat sem!) es egy hetet kell varniuk mire valaki megpatkolja a beleptetot. na, az az o sajat kulon bejaratu (pun intended :D) hibajuk

remelem igy mar vagod a sztorit! amirol az elejetol beszelek... peace!

Egy szög miatt a patkó elveszett.
A patkó miatt a ló elveszett.
A ló miatt a lovas elveszett.
A lovas miatt a csata elveszett.
A csata miatt az ország elveszett.
Máskor verd be jól a patkószeget!

A patkószeg a CrowdStrike.

Természetesen, elveszett "patkószeggel" is lehetett volna "csatát nyerni", ha több lovat visznek, kompetensebb a hadvezér és a végtelenségig lehetne agyalni a "mi lenne ha" című okfejtéseken. Az ok-okozati láncot azonban ez nem érdekli. A CrowdStrike nem tett meg mindent annak érdekében, hogy jó frissítést adjon ki, hanem kiadott egy szar frissítést. Ez bizonyos helyeken 3 órás pluszmunkákat okozott. Bizonyos helyen 3 naposakat. Lehet vitatkozni azon, hogy ahol 3 napos pluszmunkákat okozott, ott más is el volt baszva, és igazad is van ebben, de ettől még az ok-okozati lánc elején a CrowdStrike áll. Második egyébként a Microsoft, amelyik hagyja egy biztonsági szoftvernek, hogy elkékhalálozza a rendszerét, miközben amikor a felhasználót kell korlátozni valamiben, akkor már olyan biztonságos™ a rendszer, hogy alig lehet felrakni egy custom buildelt cuccot, ami nincs aláírva, anélkül, hogy percenként elkapkodná a Defender.

Nagyon sajnálom, hogy nem vagy képes ezt megérteni és helyette inkább ilyen kommentámokfutásokat rendezel.

teljesen masban hibasak.

Igen, másban. De ugyanúgy hibásak és a CrowdStrike-ot nem menti fel az, hogy más is hibázott.

nem tett meg mindent annak érdekében > ezt honnan tudod? :) valaki elszabta, ennyi. van ilyen. en is halt-oltam mar le gepet amit nem akartam (volt, hogy egyszerre sokat is) konfigoltam mar el rendszereket. es? fogtam es helyreraktam a hibamat! ha kellett visszaalltam backupbol...
kiadott egy szar frissítést > es? volt mar ilyen a vilagtortenelemben :) ezt egy rm paranccsal tudtad orvosolni, mikor a MS kidobalta a particiokat a gepekrol... na az egy kicsit durvabb sztori volt. vagy az ominozus rm -rf / az opensource projectben. :D csak ezektol nem allt meg egyszerre sok gep. nem is lett akkora hir...
Ez bizonyos helyeken 3 órás pluszmunkákat okozott. > valahol meg semmit, mert a rendszer a masodik kekhalal utan felbootolt az utolso mukodo snapshotra :)
ott más is el volt baszva, és igazad is van ebben > \o/
de ettől még az ok-okozati lánc elején a CrowdStrike áll > nem. annak nem a CS az oka, ha valaki nem uzemeltet rendes infrat! a hetes leallas pedig ennek az eredmenye, nem annak az egy koszos sw-hibanak. erted mar? :) ransomware utan is mutogathatsz, hogy dehat megtamadtak!!!! csak senkit sem erdekel aki a szolgaltatast hasznalna. :)
Második egyébként a Microsoft, amelyik hagyja egy biztonsági szoftvernek, hogy elkékhalálozza a rendszerét > kezdodik, harmadik lesz a mongo'lok? :D hint: minden kernelt agyon lehet vagni egy szar driverrel. ehhez nem kell MS :)
alig lehet felrakni egy custom buildelt cuccot > melyik vilagban elsz? olyan binarist inditok amilyet csak szeretnek. akar admin joggal.
ami nincs aláírva > ott egyszer rakerdez, hogy figyuma', ennek nincs alairasa, "biztos vagy benne"?
hogy percenként elkapkodná a Defender > nem kapkodja el, teljesen masra valo, a binaris alairtsaganak semmi koze a defender kapkodasahoz :)
Nagyon sajnálom, hogy nem vagy képes ezt megérteni > csak a fenti par mondatodban van jopar valotlansag/pontatlansag. ertem en, csak nem igy van :)

Igen, másban. De ugyanúgy hibásak és a CrowdStrike-ot nem menti fel az, hogy más is hibázott. > aruld mar el, kedves, hajbabacska de la Mancha, ki a tokom allitott ilyet? :D csak ugy erdeklodnek! :)
hagyd abba a fejedben levo dolgokkal a harcot vegre!
hanyszor kertelek ra ebben a threadben?
szamold inkabb ossze!
legyen ez a mai napod tanulsaga :)
peace!

Áhá értem, tehát a CrowdStrike-tól már nem várod el, hogy redundáns legyen, és ha valaki "haltol egy gépet" (értsd: babzsákfejlesztőék elszabnak valamit), akkor ne menjen ki egy szar frissítés. Ahogy azt se várod el, hogy legyenek megfelelő review és QC folyamatok, amik garantálják, hogy nem megy ki szar frissítés, pláne nem egy olyan, ami összeomlasztja a gépeket.

A reptértől azonban elvárod, hogy olyan infrát tartson fenn, ami nem borul meg, ha az összes gépe lehal kékhalállal.

Gratulálok! A kettős mérce két lábon járó mintapéldája vagy.

a CrowdStrike-tól már nem várod el, hogy redundáns legyen > LOL, elmagyaraznad, kerlek, hogy lesz egy szoftver redundans? ketszer van a memoriaban? :D vagy a diszken? :D (janem, az a raid es rendszerszintu, upszika! :D es jelen esetben ezzel sem mentel semmire.)
olyan van, hogy ket peldanyban fut egyszerre es a memoriatartalom is mindket helyen letezik (IBM enterspajz tud ilyet, banki/penzugyi rendszerek ilyenek), de ott sem a szoftver a redundans, hanem a rendszer (es a HW) :)

tudsz esetleg azzal vitazni amit irtam es nem a szamba adni dolgokat? koszi! :)
hajbabacska de la Mancha, ki a tokom allitott ilyet? :D csak ugy erdeklodnek! :)
hagyd abba a fejedben levo dolgokkal a harcot vegre!
hanyszor kertelek ra ebben a threadben?
szamold inkabb ossze!
legyen ez a mai napod tanulsaga :)
peace!

LOL, elmagyaraznad, kerlek, hogy lesz egy szoftver redundans? ketszer van a memoriaban? :D vagy a diszken? :D

Az értetlenkedő kérdéseddel most már azt is bebizonyítottad, hogy normális szoftverfejlesztési folyamatot sem láttál közelről. Semmi baj, nagyon szívesen elmagyarázom a gyengébbek és dorsyka kedvéért, hogy mi a lényeg: a folyamat. Hogy ne mehessen ki úgy frissítés, hogy az kernel crash-t okoz. Ha a QA nem teszteli meg, akkor legyen egy másik (redundáns) QA, aki megteszteli. Ha a review-ért felelős babzsákfejlesztő nem talál benne semmit, akkor legyen egy másik (redundáns) fejlesztő, aki még átnézi.

olyan van, hogy ket peldanyban fut egyszerre es a memoriatartalom is mindket helyen letezik

Olyan van, hogy ismét félrebeszélsz, csakhogy a lényegről ne kelljen beszélni.

hanyszor kertelek ra ebben a threadben?

Te majd akkor kérsz tőlem ilyet, amikor nem szavakba és megfogalmazásokba kötsz bele, forgatod ki, csakhogy ne kelljen arról beszélni, ami a téma: a CrowdStrike felelősségéről és arról, hogy a CrowdStrike mit szúrt el.

Te majd akkor kérsz tőlem ilyet > amikor akarok :) nem kell mas szajaba valotlansagokat adni, meg kepzelegni arrol mire gondol. probald meg, nem nehez! :)
redundans szoftverrol beszeltel. ami - ebben a kontextusban - netto faszsag. engedd el a hulyesegeid vegre :)

( Oregon | 2024. 07. 30., k – 09:40 )

Nagyon ősi minőségjavító módszer, ami a exkluzív  autóknál mai napig megvan: odaírják a készítő nevét

Persze egy szoftvernél ez önmagában kevés.

( dorsy v | 2024. 07. 31., sze – 13:03 )

https://www.reuters.com/business/media-telecom/att-wireless-outage-febr…

egy meghiusult 911 hivas vajon mennyit er dollarban? :D
#takoltinfra

The FCC is also investigating a massive hacking incident in April disclosed earlier this month that resulted in the illegal downloading of about 109 million AT&T customer accounts.

Ez meg a hagyjukis kategoria... cellainfokkal egyutt, csak, hogy lehessen visszamenoleg kovetni a usereket. :)

A legkisebb gond, hogy a fejlesztok sz*r kodot dobnak ki, ha a mogottes infra ennyire nem reziliens/osszedrotozott/duct tape-elt/insecure ganajdomb...

( GerzSonka | 2024. 08. 11., v – 21:32 )

Én QA-ban (is) dolgozom. Ha az általam felügyelt szoftver crashel a fielden, az nekem blama, és mindent megteszek, hogy ne történhessen meg.

Viszont emberek vagyunk, mind tudunk hibázni. Mindenesetre a crowdstrike hiba az nagyon a levegőben volt, munkatársam gépén egy teljes magot hetek óta 100%-on pörgetett a céges ubuntun, szóval van ott javítani való dolog. Év elején átvettünk egy projektet, olyan tragikusan (nem) volt tesztelve, hogy köpni-nyelni nem tudtunk. Fél év volt, mire ledolgoztuk a trouble reportok számát nullára. Szóval engem kifejezetten zavar a szoftverfejlesztőknél tapasztalható beleszarós mentalitás. Főleg a fizetős termékeknél.

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( g3rg0 | 2024. 08. 11., v – 23:46 )

Kellene ? A cégek felelőssége bizonyos méret felet megszűnik. 

Jó példa az utóbbi évtizedekben nem is olyan ritka pénzügyi válságok, ahol érdemben nem történtek felelősségre vonások, ellenben a hibás cégeket az adófizetők pénzéből kisegítették. ( egyúttal ezekből szabad szemmel is látható bónuszok jelentek meg a felelősök számláin)