Új hozzászólás Aktív témák
-
tehát overnight kamat van. értem.
vagyis ha banküzem zárás előtt elutalom a pénzem, azt a fogadó bank csak másnap kapja meg, így egy overnight kamatot bezsebel a bankom...egyébként a bankok pancsersége tökre egyértelmű. a boldog békeidőkben, a 90-es években még havi szinten ment a számlavezetés, meg is hekkelték őket ezerrel. ebből jutottunk el pár évvel ezelőtt oda, hogy nagyjából négy óra alatt átmegy egy átutalás. amikor pár évvel ezelőtt lecserélték a rendszereket olyanról, ami postagalambra alapozott volt olyanra, ami négy órát tudott, miért nem cserélték le olyanra, ami realtime megy?
tudomásom szerint eddig is clearinghouse-t használtak a bankok, a giro-t. miért nem lehet megoldani, hogy a giro bármelyik bankkal bármilyen protokollal tudjon beszélgetni? ha az otp tud azonnali átutalást, akkor elmegy az otp-ből a giro-ba azonnali átutalással a pénz, onnan meg a célbankba úgy, ahogy az fogadni tudja.
más. még mindig egy olyan formátumban kell leadni a csoportos beszedést a banknak, amiről látszik, hogy kb. az 50-es években tervezték, és cobol programok kezelik. bakker 2019. van. az otp giro interfésze még mindig nem hallott xml-ről meg json-ről.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
több hsz-re reagálva megkérdezném ismételten: nemrég mélyen belenyúltak a rendszerekbe, amikor megcsinálták a napközbeni többszöri átutalást. akkor miért nem csinálták meg rendesen?
szerk: megkérdezném azt is, hogy ha jól sejtem, a bankoknak egymással egyáltalán nincs közvetlen kapcsolatuk. akkor mit számít, hogy melyik bank van kész és melyik nincs az azonnali átutalással?
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"Nem nyúltak bele sehogyan sem.": eddig nem volt napközbeni utalás, majd lett. tehát belenyúltak.
[link]szerk: "az egész rendszer automata, container alapú, mert más nem képes ilyen gyors és rugalmas lenni a virtuallizáció nagy és lusta a fizikai gépek eleve nem alkalmasak erre marad a konténer.": kösz, most már értem, miért nem tudták megcsinálni.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"Hol vannak olyan követelményei a napközbeni átutalásnak mint az 5 sec-en belüli utalásnak gondolkozzál már....": nem hangzott el olyan állítás, hogy a napközbeni utalásnak meg az 5 sec-en belüli utalásnak ugyanolyanok a követelményei. az hangzott el, hogy akkor, amikor kétszer is belenyúltak a rendszerbe, miért nem csinálták meg elsőre úgy, hogy az 5 másodperces utaláshoz is jó legyen. ez így tripla munka.
"Miért Te mivel csinálnád meg?": az nyilvánvaló, hogy konténerekkel biztosan nem. teljesen felesleges a konténerhez szükséges szoftver-rétegekkel rombolni a megbízhatóságot. egy ilyen feladatra egy bank legyen képes dedikált infrastruktúrát biztosítani, és akkor nem kell a konténer.
Mondok neked valamit: tojást sem tojtam. mégis pontosan tudom, hogy melyik tojás záp. de lefordítom, nehogy kétségeid maradjanak: attól, hogy még nem telepítettem ilyen rendszert, meg tudom mondani, hogy hogyan ne fogj neki.
ha pedig te már telepítettél ilyet, az csak annyit mond, hogy érintettséged folytán az objektivitásod nulla.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
kleinguru
#95
üzenetére
A konténer tesz pár ígéretet, amiből, szerintem, egyet se tart meg.
például:
- gyorsan lehet deployolni. nem hiszem, hogy az oprendszer saját csomagkezelőjénél gyorsabban bármi tud deployolni.
- biztonságos1. a konténer szoftverekben is lehet hiba, az interneten olvasott hírek szerint van is.
- biztonságos2. a konténerekből pillanatok alatt ki lehet törni, tehát hoszt oprendszerbeli védelmet nem ad
- egyszerű. a konténer maga lehet egyszerű (egyébként nem az), de a használatához mindenféle kiegészítő szoftverek kellenek, amiket egyrészt sok energia megtanulni, üzemeltetni, másrészt ugyanúgy bugosak, mint a konténer.
- mindenféle szolgáltatásokat ígér: amiket az alap oprendszer ugyanúgy tud, mint amit a konténer állít magáról.a konténer szerintem egy olyan technológia, ami úgy jött létre, hogy pár programozónak már nagyon viszketett a segge az unalomtól, hogy programozni kellene valamit, hát csináltak egy konténert, ahelyett, hogy megvakarták volna, vagy uram bocsá', megmosták volna. ezzel a húzásukkal ahelyett, hogy a hibák alaprendszerből történő kitakarításába feccölték volna értékes munkaerejüket, újabb hibák rendszerbe pakolása sikeredett. ez egy ilyen "nem elég, hogy dácsiát vettél bmeg, még szét is borítod munka közben" típusú hozzáállás. ezzel párhuzamosan meg kidobják azok munkáját, akik valóban hasznosan áldozták idejüket arra, hogy egy dpkg meg egy apt rendesen működjön.
egyébként ki lehet ezt számolni: ha p1,p2,p3,...,pn a valószínűsége, hogy az i-dik szoftverréteg hibátlanul működik, akkor
P=p1*p2*...*pn
a valószínűsége, hogy az egész kóceráj egyben jó lesz, ahol minden pi<1. Következmény: minél több réteged van, ami 1-nél kisebb valószínűséggel hibátlan, az összegük annál labilisabb lesz.
a unix alapfilozófiája: KISS: Keep It Stupid and Simple. sem a konténer, sem a systemd nem ez.
az informatika alaptörvénye pedig ez: ha nem romlott el, ne akard megjavítani. értsd: ha nincs valós igény egy problémára, akkor az nem lesz megoldva. a konténer nem valós igény.Jönnek a süket dumával, hogy gyorsan kell deployolni. Ezt az igényt az hozta elő, hogy trógerül végzik el azokat a munkafolyamatokat, amik a szoftver meghatározásához kellenek, konkrétan a folyamatszervezést és a szoftver tervezését. Nem tudja a megrendelő se, hogy mit akar? nem baj, csinálunk valamit, hátha attól rájön, hogy mit akar, és akkor majd megcsináljuk azt is. Magyarul pazaroljuk a programozók munkáját, mert ha nem tudják, mit kell programozni, biztosan kidobásra ítélt kódot csinálnak, és megspóroltuk a szervezést, a megrendelő interjúztatását, kifaggatását. így a végén a legdrágább munkaerő sorozatos pazarlásával készül el valami. Ha így programozunk, akkor nyilván kell a gyors debloy, hogy a megrendelő két percenként változó igényeit követni lehessen. De ez marhaság, ez csak egy aktuális menedzsment bullshit. Ami ugyanez a kategória: kínosan viszketett már valamelyik yuppie menedzsernek, feszített a hátsója, hát mondott egy ordas baromságot ahelyett, hogy kiment volna a kishelyiségbe, és bedurrantott volna a perem alá. (zárójelben jegyzem meg: ennek a hülyeségnek az értelemszerű következménye egy csomó agilis szoftverfejlesztési módszertan is. hogyan dolgoztassuk a programozót akkor is, ha fingunk nincs arról, milyen feladatot kellene adni neki.)
Néha felemlegetik az emberek a linuxnál a töredezettséget, hogy miért van kettőnél több desktop, stb. Amikor a konténer szóba kerül, akkor lesz hozzá egy bazi hosszú lista, "orchestration", hogy ceph, kubernetes, meg a fene se tudja, még mi, amik mind megoldanak egy olyan részfeladatot, ami konténer nélkül nincs. rotfl, aki ezeket feltelepíti magának, az csak plusz munkát okoz.
Levetítve ezeket a banki átutalásos rendszerekre:
1. konténernek elvben lehet értelme akkor, ha több usert akarsz kiszolgálni egyszerre egy vason.
2. konténernek lehet elvben értelme akkor, ha több feladatot akarsz ellátni egy géppel, amelyek csak egy töredék gépet használnának ki. (egyébként ez más okból is hamis érv)Ez a két érv ne legyen már igaz egy banki utalásos rendszerre. Ez annyira kritikus rendszer egy bankban, hogy erre vegyenek megfelelő mennyiségű dedikált gépet, és azon ne menjen semmi más. Egy banknak legyen már pénze pár darab márkás szerverre, főleg ilyen otp-k, mikor 1 milliárd eurós adózás utáni nyereséget jelentenek be.
3. A konténertechnológia jelenleg jól láthatóan nem hibátlan szoftver.
4. Volt már a héten intel proci sebezhetőség?ezek alapján súlyos hiba lenne az átutalási rendszer mellé beengedni ugyanazon gépre bármilyen más szoftvert, pláne idegen felhasználót. következmény: nincs szeparálási igény, a szeparálást a gép fémdoboza adja. akkor meg minek konténer?
Egy ilyen rendszert úgy lehet jól megcsinálni, hogy fogod az architektúra tervet, amit egy átlagos java architekt tervezett, és kihajigálod az összes réteget, ami nem kell. majd elolvasod Himfy-t, és alkalmazod
ami marad, azt pure linuxon megvalósítod, és akkor jó lesz.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"A bank nem kezelési költséget fizet a betétedre, hanem kamatot": értelmezésben kihívásokkal küszködők kedvéért a "kezelési költség fejében nála tárolom" megfogalmazás azt jelenti, hogy aki beteszi a pénzt a bankba, a tárolásért cserébe kezelési költséget fizet a bank részére.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
hallador
#123
üzenetére
"Mert miért is kellene csak oprendszer csomagokat deployolni, a fejlesztők által készített saját fejlesztéseket hogyan szeretnéd teríteni a saját csomagkezelővel?": eszerint a vita szerint két választási lehetőséged van: a fejlesztő által készített szoftverből oprendszer csomagot készítesz vagy konténer image-t. minek csinálnál konténer image-t, ha összességében az oprendszer saját csomagját megcsinálni nagyjából ugyanannyi meló és kihagyhatsz egy felesleges köztesréteget?
"Hát ja mint magában az operációs rendszerben is, ennyi erővel nem szabad csak számológépet használni azt nem tudod semmihez csatlakoztatni, sarkított példa, de érthető szerintem": nem sarkított példa, hanem rossz. oprendszert mindig fogsz használni. nem mindegy, hogy annyi bugod van, amennyi az oprendszerben van, vagy annyi, amennyi az oprendszerben + a konténerben + a konténerkezelő szoftverben. ha meg tudsz oldani mindent az oprendszerrel (mert meg lehet), akkor a többi hibaforrást minek húzod a nyakadba?
"Ezt ne hozd fel mert, ha ez így lenne, akkor a google-től, az amazonon át a Microsoftig senki nem használná ezt a technológiát": ja mer a google-t, a facebookot meg az ms-t már qrvára érdekli, hogy mekkora lyukak vannak a cuccaikban... az ms-t például annyira érdekelte az outlook365 biztonsága, hogy három hónapig átjáróház volt a rendszerükben. másrészt a google, az amazon, az ms az eladói oldalon van ebben a kérdésben, én meg a vevőin. nekik érdekük, hogy minden sz.rt elsózzanak a vevőnek, mert abból van bevétel. őket nem érdekli, hogy a szolgáltatás hasznos-e vagy sem, őket az érdekli, hogy fizess. engem meg kizárólag az érdekel, hogy a feladatomat mivel tudom hatékonyan és olcsón megoldani.
"Mi az, hogy bug-os? Mond már meg, hogy melyik operációs rendszer az amiben nem volt épp aktuális bug, tudsz ilyet mondani?": oké, mondok autós példát: ha most nyitnál egy taxivállalatot, mit csinálnál? vennél 15 féle autóból 100 darabot/típus, és tartanál 5 féle gyújtógyertyát, ékszíjat meg fékbetétet raktáron, meg készleteznél többféle üzemanyagot, vagy kiválasztanál egy gyártmányt és abból vennél 1500-at? na a docker meg a kubernetes pont ez, hogy kellene egy autó, amivel fuvarozol, de te nem egy autót veszel, hanem többet, hogy legyen mivel szívni. senki nem mondta, hogy a linux hibátlan (de, én
). csak nem mindegy, hogy van pl. a debianban heti 3 hiba, azt kell kezelni, vagy van a debianban heti 3 hiba, a dockerben heti 8, a kubernetesben 12, a ceph-ben 6, és egyébként is a szkriptek fele telepítéskor rossz, és heteket kell dolgoznod, mire először elindul a rendszer."Bizony így van, csak ameddig a konténer képes ezt a 10-ed annyi erőforrással megoldani.": az alap oprendszernél nincs hatékonyabb. Tehát a konténer nem tud semmit 10-ed annyi erőforrással megoldani, mint amit az alap oprendszeren megoldasz. a konténer egy réteg az alap oprendszer és a szoftvered között, tehát nem gyorsít, hanem lassít.
"Addig az operációs rendszer mivel minden egyes feladathoz egy külön kernel kellene, addig a konténer számára nem kell.": de mi a fenének kellene minden feladathoz külön kernel? a linux kernelek felhasználói interfészei már nagyon régen nem változtak érdemben, ha mégis, azt hallottad, mert azt Linus elég nagy hangerővel szokta megkifogásolni. Don't break the userland. felrakod azt a kernelt, amit éppen a legbiztonságosabbnak gondolsz, azon a legtöbb régi dolog elfut változtatás nélkül. ha meg nem, javítsd ki. A konténernek se raksz be külön kernelt, tehát ebben a kérdésben a konténer nem előnyösebb az alap oprendszernél. A konténernek elvben lehetne előnye a virtualizált rendszerekkel szemben, de a valós teljesítménykülönbség annyira kicsi, hogy nem érdemes foglalkozni vele.
"Platformfüggetlen a dolog nincs odakötve a kernelhez, vashoz oprendszerhez platformhoz.": értem, tehát feldobok egy dockert windows10-re, belerakok egy linuxos postgrest és működik? mert ha nem csal a memóriám, maga a docker elvileg működik w10-en. Vagy mégiscsak tévedsz, és oda van kötve a kernelhez? Például ha felraksz egy docker image-t, akkor jól összefossa magát az uid/gid számozás, ha nem egyforma az oprendszer, amin futtatod, meg az oprendszer, amin az image-t generálták? (személyes tapasztalat). Meg ugye a docker elvileg layered fs, tehát csak az van benne a docker image-ben, ami nincs meg az alap oprendszerben, mert a többit onnan húzza fel. szóval ki nem függ mitől?
"Ha az egyik konténer megsemmisül a microservice-en belül, a másik úgy képes elindulni, ha kell, hogy 1 sec-sem esik ki a rendszer üzemeltetésből": mi meg tudunk olyan microservice-t programozni, ami nem semmisül meg. szóval itt is az látszik például, hogy konténerrel akarod megoldani a tróger programozási munkát.
"ezt old meg vm-el, vagy teljes virtuális géppel, mindezt úgy, hogy egy fizikai vason futhat akár 40 konténer is": nem akarom sem vm-mel, sem teljes virtuális géppel megoldani. (mi is a különbség a vm meg a virtuális gép között? én eddig úgy tudtam, hogy tükörfordítás, azon kívül semmi). ha ebben a vitában a véleményemet akarod támadni, akkor ne azt kérdezd, hogy hogy oldom meg virtuális géppel, hanem azt, hogy hogy oldom meg csupasz oprendszerrel. azta, futhat 40 konténer is, most leesett az állam... (nem). ha általában kérdezed, azt a 40 szolgáltatást felrakom egy oprendszerre, oszt jónapot. a csupasz oprendszer védelmi rendszere egy centivel sem gyengébb, mint egy konténeré.
"A rugalmasság az ereje, nem a szerinted miért nem jó, hát ja a 2000-es évek elejének vége van, ezt kellene felfogni.": úgy érted, hogy bekorlátoztad magad a konténerbe, és akkor ez a rugalmas, a csupasz oprendszer meg nem? esetleg nem ismered, hogy miket tud az alap oprendszer? azt kellene felfogni, hogy az igények nem változtak érdemben a 2000-es évek eleje óta, úgyhogy tök jól megfelel oda az idén 50 éves technológia is. csak az igényeket kell pontosan leírni. mert ha szerinted az az igény, hogy a konténer így-úgy működjön, meg a telepítés könnyű legyen, meg ilyenek, akkor ezek nem igények. Az emberek nem konténert vesznek, hanem facebookozni akarnak meg videót akarnak letölteni. kutyára nem érdekli őket, hogy mi van mögötte.
"Meg a unix röpke 50 éves, lehet a múltban élni csak minek.": hát ja. a tőzsdék zöme linuxon megy, az androidban linux van, a hálózati eszközök zömében linux van, a microsoft a saját felhő rendszerében a switchek meghajtására linuxot használ, a windows10 nevű desktop operációs rendszerbe fullosan integrálták a linuxot, mer' annyira régi és ócska, hogy csak a múltban élünk. azt már bele sem írom, hogy google, facebook, oracle, sap, meg még egy csomó garázsbt is linuxon fejleszt. Meg van az alma, aki nem linuxozik, viszont a termékei mélyén ott van az eredeti echte tanúsított unix. Munka Pista egyszer dobott egyet a NeXT-tel, utána gurított egy nagyot a MacOS-sel (bsdi kernel), majd szétrúgta a világ seggét a szifonnal (freebsd, mint tanúsított unix kernel). Menj ki az utcára, nézd meg, hány ember kezében van szifon, és mond a szemükbe, hogy 50 éves ócska cuccot hurcibálnak magukkal.
"Igen pont ez a lényege, hogy a konténert nem virtualizáción futtatunk, hanem natív hardveren.": én ilyet nem állítottam, tehát ha te erről akarsz vitázni, azt mással tedd.
"A systemD meg hogy jön ide?": a systemd nagyon jó példa, ott is azt állították, hogy valami hiperszuper meg az elődje régi volt, meg minden, pont ugyanazokat az állításokat tették meg, mint a konténernél. és pont ugyanúgy nem teljesítettek egyet se, mint a konténernél. a systemd nagyobb bughalmaz, mint a w10 update rendszere. Volt egy rendes, szabványos, svr4-es init. az minden linux disztrón egyforma volt (magánügy, ha nem svr4-es init volt egy disztróba, engem nem érdekelt), hibátlanul futott. Tény, hogy egy debian svr4-es inittel pár másodperccel lassabban bootolt, mint egy systemd-vel, de legalább bebootolt, mindig pontosan azt csinálta, amit mondtam neki, és ugyan már ki a bánatos francokat érdekelte, hogy 5 másodperccel lassabb a boot, mikor a raid vezérlő 300 másodpercig tesztelte magát minden bootkor? meg egyébként is, kétévente bootolva ráérek arra az 5 másodpercre.
"Nem mondom, hogy a systemd fenékig tejföl": pedig mondhatnád, mert páran röhögnénk végre egy nagyot.
"De még mindig jobb mint szerencsétlenkedni minden disztrón a saját dolgaival.": konkrét megtörtént eset: systemd-ben a mount unitok nem működnek rendesen. azt megoldani, hogy egy program csak azután induljon el, miután kinyitott egy titkosított partíciót és felmountolta, systemd-vel hónapokba került. svr4 inittel meg 5 perc. akkor melyik is a gyorsabb? ki fizeti ki nekem azt, hogy a systemd nevű rakás sz.rt kellett konfigurálnom három hónapig, és nem derült ki, miért nem jó?
különben is mi az alaptörvény? hogy ami nem romlott el, ne akard megjavítani. elromlott az init? nem. akkor nem cseréljük le. kiss. egyszerű volt az init? egy dolgot csinált, de azt jól? igen. egyszerű a systemd? egy dolgot csinál? nem egyszerű, egy rakás dolgot csinál, de legalább zömében rosszul.
"A mindent akarok, de semmit nem akarok érte tenni otthoni mentalitásból kiindulva igazad van,": én nem a magyar közszférában dolgozom, hanem a versenyszférában, és a bankok is. itt arról szól a történet, hogy csökkentsd a költséget, növeld a bevételt, mert a kettő különbsége a profit. ez a történet erről szól. és ebbe se a konténer nem passzol, se a systemd.
"Hát ja lefordítom azok nyelvére is akik nem egészen értik ezt, tehát szerinted ha búzát aratunk": oké, legyen mezőgazdasági példa, az öreg Moldova kiváló példát adott ehhez.
a hsz-ed több részében is az a probléma, hogy a konténert ebben a konkrét témában is támadtam, és ott nincs 300 ezer user, meg hasonló hülyeségek. Ha ez szóba kerül, az egy másik téma nyitását igényli.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
nézhetjük nem technológiai oldalról is...
a konténer arról is szól, hogy ha nagyon elterjed, az üzemeltetőnek nem lesz állása. de nem ez a fő kifogásom ellene, hanem az, hogy úgy látom, tájékozatlanul alkalmazzák. azt hiszik, az mindenre is jó, miközben például a biztonságába vetet hit megalapozatlan."Én olyan területen dolgozok (főként fejlesztő és részben üzemeltető sapkában), hogy az alkalmazás nem tartozik a jól ismertek közé, ezért nekem általában nagyobb tapasztalatom van telepítés / hangolás kérdésekben, mint nekik.": tehát neked több ismereted van az alkalmazás beállításával kapcsolatban, ezért te csinálod? ez nagyjából minden ide vonatkozó elvnek, szabványnak, szabálynak ellentmond. egy ilyentől egy iso auditor kiszalad a világból.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
ZeroCool
#128
üzenetére
olyat, hogy nem kell üzemeltetni, nem mondtam. olyat viszont mondhatnék, hogy mások azt hiszik, majd nem kell üzemeltető. ez a rengeteg software as a service, paas, stb. lószerszám a hátsódba as a service mind arról szól, hogy nagy cégek ki akarják venni az üzemeltetést a kezedből, hogy ők szedjék be érte a profitot.
miből gondolod, hogy nem tudnám megalkotni a konténerizációt? biztosan meg tudnám, csak az jobb lenne, mint a mostani vackok. megtanulni is meg tudnám. nem a tudás vagy a képesség (esetleges hiánya) a lényeg, hanem az, hogy ezt ki fizeti meg. de ez már elhangzott: normálisan a ráfordításokat csökkenteni kell, a bevételeket meg növelni, mert ettől nő a profit. ha meg tudok csinálni valamit 3 óra munkával alapoprendszeren vagy 15 óra munkával dockeren, és ugyanaz a végeredmény, akkor azt alapoprendszeren kell megcsinálni, mert senki nem fog megfizetni 12 óra felesleges munkát.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
ha egy cég biztosan akar működni, akkor nem engedi, hogy bizonyos fontos információk egy embernél legyenek. ha veled bármi történik (pl. felrúgod a villamost), akkor mi lesz?
ha a cég a működését szabványosítani akarja, akkor előbb-utóbb csinálnia kell üzletfolytonossági és katasztrófa elhárítási terveket. ezeknek része, hogy az alkalmazást hogyan kell telepíteni és üzemeltetni, egészen bolondbiztos szintig lemenő leírással. ez alapján az üzemeltetőnek is tudnia kell pontosan ugyanolyan jól telepíteni az alkalmazást, mintha te csinálnád.
az információbiztonsági megoldások zömében nem a hatékonyságról szólnak
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
hallador
#133
üzenetére
"a fejlődés az nem a kisipari hegesztésekkel lesz megoldva előbb utóbb": a konténerezés nem érte el még a kisipari hegesztések szintjét se.
"amíg egy adott technológia arról szól, hogy szabványosítson": mert a docker például arról szól, hogy szabványosítson? ne nevettess. hogy fog szabványosítani a docker úgy, hogy a szükséges feladatok zöméhez más programcsomagokat is üzemeltetni kell, miközben sem az alap oprendszer nem szabványos, sem a konténer technológia nem szabványos, sem a körítés?
"Amilyen példákat Te hozol arról szól hogyan ne oldjuk meg": így van. de ha nem szelektíven olvasol, akkor azt is leírtam, hogy hogyan kell megoldani másképp.
"Senkit nem érdekel, hogy konkrétan mibe futottál bele a systemd-vel, ha 100 rendszerből 99-nél képesek használni.": legyen a szokásos autós példa. ha egy autóval mindig lehet közlekedni, de néha nem tudom bekapcsolni a rádiót, akkor abba bele tudok törődni. de ha egy autó az esetek zömében nem indul be, és ha be is indul, akkor se tudom rátenni a szabványos kereket, akkor azt felgyújtom a p..ba. különösen ha egy olyan világban erőszakolják rám, ahol addig a szabad választás lehetősége volt a vezérelv.
a docker meg olyan, hogy van egy ócska, kátyús utad, és egy csomóan azzal foglalkoznak, hogy olyan jelzőtábla tartó oszlopokat fejlesszenek ki, amit könnyű telepíteni és nem fújja el a szél, hogy rátehessék a kátyús út! táblát.
"Olyan példákat hozol fel mintha csak a Docker, meg a systemd meg azok a technológiák lennének a rosszak amit Te rossznak tartas": én a dockert (pontosabban a komplett technológiát) rossznak tartom. igazából nem is a docker a rossz, hanem a tervezési irányelvei és céljai. a systemd-t meg nem csak én tartom rossznak, népes "rajongó" tábora van.
"jajj a többi sem jobb": pontosan mit is írtam, amit így sikerült értelmezni?
"El tudok szakadni én bármitől, csak azt nagyon rühellem, ha valaki akkor is okoskodik, ha nem kellene.": a valóság ezzel szemben az, hogy tetszőleges időpontban mondanék olyan véleményt, ami neked nem tetszik, akkor az rögtön okoskodás lesz szerinted. Tehát nem attól lesz okoskodás valami, hogy szerinted nem kellene vagy rosszkor jön, hanem attól, hogy ellenkezik veled.
"Nem ismeri a technológiát": ezt honnan tudod?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
hallador
#134
üzenetére
pedig a konténer arról is szól, hogy nem kell hozzá üzemeltető. ezt az állítást csak azok olvassák félre olyan jelentéstartalmmá, hogy "nem kell üzemeltetni", akik nem beszélnek rendesen magyarul.
az, hogy nem kell üzemeltető, azt jelenti, hogy a hagyományos felállást, miszerint van az egyik szobában fejlesztő, a másik szobában üzemeltető, felváltja az, hogy az üzemeltetőt elküldik, a fejlesztő nyakába sózzák az üzemeltetési feladatok egy részét, és átnevezik devopsnak, a feladatok másik részét meg lenyúlják a publikus cloud üzemeltetők a zsetonnal együtt.
Az általad emlegetett auditorok közül az egyikkel volt már dolgom (hagy ne emeljem ki), azóta is mindig nagyokat röhögünk, ha sztorizgatás közben előkerül.
"Hát csak ne felejtsd el, hogy ez megint akkor lesz igaz, ha annyi rendszert üzemeltetsz amit fejben meg tudsz jegyezni,": szerintem erről a hülyeségről leszakadhatnál már, mert az, hogy egy üzemeltetési módszertan jósága nem attól függ, hogy konkrét valaki hány rendszeren használja, hanem attól, hogy elvileg mekkora rendszerig hatékony. tehát ha én felépítem a google mását három szerveren, akkor az pont olyan jó, mint a google, és nem a kisgépes kategória.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
hallador
#140
üzenetére
írom ömlesztve:
ne aggódj, ismerem annyira a technológiát, hogy megalapozottan nyilatkozzak róla. a megtanulás pedig arra vonatkozott, hogy melyik oprendszeren aktuálisan milyen hasfájása van a kócerájnak. azt tényleg nem ismerem.képes különböző oprendszereken is pont ugyanúgy működni? ez implicite azt az állítást is tartalmazza, hogy képes ugyanazon az oprendszeren is pont ugyanúgy működni, különben semmi értelme. tehát a docker az szabványos minden tekintetben, az alatta levő fájlrendszertől kezdve a konténerig, tehát csak docker van, lxc meg lxd nincs, és a szükséges kiegészítőkből is pontosan egy van, amik szabványosak? nincs ceph meg puppet meg ansible meg a fene se tudja, hogy a héten még mi? vagy ha mégis az a valóság, hogy van ceph meg puppet meg ansible meg a többi, és a dockert felrakhatod többféle cluster fájlrendszerre, stb. stb., akkor a konténer technológia nem szabványosít semmit.
"a volt kollégámnak (Amazonnál mérnök)": nyugodtan mondd neki, hátha ő megérti a különbséget. neked meg elmagyarázom: az amazon az egyik cég, amelyik sok pénzt akar kaszálni a konténer technológiából. tehát náluk lesz. ők azok a mumusok, akik el fogják venni az üzemeltetők munkáját (na jó, nem ők azok a mumusok, hanem egyike a mumusoknak, de ez lényegtelen különbség). tehát az amazon azért tolja a konténert, mert ez az alap kompetenciája, szemben egy csomó más céggel, akiknél a konténer nem üzleti cél, hanem teljesen más üzleti célok megvalósításához egy eszköz (annak hiszik).
"Aki folyamatosan azt bizonygatja, hogy minek kellene megtanulni bármit ami új, ha ott a régi is": én ilyet mondtam ebben a threadben? én azt mondtam, hogy minek tanulnék meg valamit, ami nem jó, de legalább bugos és felesleges. nem az új technológiákat utasítottam el en-bloc, hanem a felesleges, valódi cél nélkül létrehozott technológiákat. csak neked már leszállt a köd, így nem vagy képes értelmezni a megfogalmazásban levő finom nüanszokat.
"Tehát akkor finoman lefikáztat a komplett magyar piacot, és vele együtt kinevetted a komplett magyar bankipart": abból, hogy egy auditort lefikáztam, hogy vezetted le, hogy a komplett piacot lefikáztam? hint: tévesen. az általad említett három auditorból egyet lefikáztam, az általad említett másik két auditort és a piacon szereplő többit pedig nem fikáztam le, ahogy nem fikáztam le ilyen téren a bankokat se. úgyhogy ne beszélj félre, ha velem akarsz vitatkozni, azzal vitatkozz, amit én mondtam, ne azzal, amit te kiolvastál belőle vagy más mondott.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
hallador
#142
üzenetére
ezzel a nézettel nagyon nem tudok azonosulni.
most azt mondtad, hogy fejlődni kell, és az egyetlen fejlődési irány a konténer, és aki nem akar erre menni, az mind elmaradott és ócska.marhaság. kismillió más lehetőség is van szerencsére. valójában te vagy beszűkülve, ha azt gondolod, hogy aki nem a te utadon jár, az téves, más üdvözítő út nincs.
nekem egyébként jó dolgom van, nagyjából két, objektíven mérhető paraméter eldönti, hogy jól dolgoztam-e vagy sem. ha nem csörög a hibabejelentő telefonja, akkor alapvetően jól dolgoztam, függetlenül attól, hogy a kibicek mit irkálnak. a másik meg: ha le tud tölteni annyi adatot, amennyi a szerződés szerint jár, akkor jól dolgoztam. a pletyka meg lepereg.
"Ez ilyen majd meglátjuk kinek lesz igaza ezt a jövő dönti el.": nem, nem fogjuk a jövőből megtudni, hogy miért volt igazam
egy csomó példát tudnék most hozni informatikai és nem infós területekről, amikor se az aktuális divat nem vált be, és a fősodratú vélemények bevallani se merték. az a szerencsés eset, amikor akkora pofáraesés van, hogy nem lehet alternatívan interpretálni, ritka.de azért megkérdezem: van egy konkrét problémám, amit eddig virtualizációval oldottam meg. az nem tanulás, hogy most megtanultam, hogy hogyan lehet jobb eredményt elérni, ha virtualizáció nélkül oldom meg?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
hallador
#146
üzenetére
"Én meg azzal, hogy csak azt akarja erőltetni amivel egyetért...": normális ember nem erőlteti azt, amivel nem ért egyet.
"Tehát Te ismered a komplett piacot mindenhol?": ööö, mivel is gyanúsítottál meg? hogy "Ezt megint Te halucináltad". szóval azt meg, hogy sok példát ismerek, ebből levezetted, hogy ismerem a komplett piacot mindenhol, az a te halucinációd, mert egyébként ez téves következtetés.
az otthonfóbiádba meg nem szeretnék beszállni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
hallador
#151
üzenetére
"Persze abban igazad van kedves Bambano, ha a vitatkozás, meg az EU-s pénzek eszetlen költése a cél, akkor a Te véleményed az erősebb....": nem tudom, milyen alapon hoztál összefüggésbe eu-s pénzekkel, de ezt a személyeskedő sértegetést fejezd be, mert semmi alapja sincs.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
ami marad, azt pure linuxon megvalósítod, és akkor jó lesz.
). csak nem mindegy, hogy van pl. a debianban heti 3 hiba, azt kell kezelni, vagy van a debianban heti 3 hiba, a dockerben heti 8, a kubernetesben 12, a ceph-ben 6, és egyébként is a szkriptek fele telepítéskor rossz, és heteket kell dolgoznod, mire először elindul a rendszer.
Új hozzászólás Aktív témák
it A rendszerüzemeltető bizakodó, és a törvényi kötelezettségre is hivatkoznak, de felmerült annak lehetősége, hogy a bankok kapnak még türelmi időt.
- -56% HP EliteBook 840 G8:i7 1165G7,16GB RAM,512GB NMVe SSD,Iris Xe,IR kam.+ujj.olv.,vil.MAGYAR bill.
- Monitortató plexi konzol több elérhető készletről MONITORCENTER
- -50% HP EliteBook 840 G8: i7 1165G7,32GB RAM,1TB NMVe SSD,Iris Xe,IR kam.+ujj.olv.,vil.MAGYAR bill.
- 1.250.000 FT helyett 940.000 FT !! MacBook Pro 16" M3 Pro 12CPU / 18GPU / 18GB / 512 SSD
- RTX 2080TI ROG STRIX GAMER PC