- sziku69: Fűzzük össze a szavakat :)
- MasterDeeJay: SATA to SAS adapter
- gban: Ingyen kellene, de tegnapra
- Viber: ingyen telefonálás a mobilodon
- Elektromos rásegítésű kerékpárok
- Argos: Szeretem az ecetfát
- btz: Internet fejlesztés országosan!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- gerner1
- Luck Dragon: Asszociációs játék. :)
-
LOGOUT
Új hozzászólás Aktív témák
-
proci985
MODERÁTOR
olyan matematika levezetéseket is meg tud csinálni, amit sose látott.
Ja, zero shot learningre képes ami jó, mert mi emberek is így működünk. Probléma, hogy az a matematikai levezetés nem feltétlenül lesz jó.Még ScopusAItól is láttam eléggé meredek hibákat.
coco2
Most esetleg megkérdezném, honnét tudod, hogy mit kapott információ betápnak?
promptokból nagyon specifikus esetekben (szűk terület) vissza lehet fejteni.googlenél nekem tavaly pythonnal volt az a tapasztalatom, hogy az első 20 találat kb a petal dataset alapján írt guideból generált -> crawlolt -> generált -> crawlolt -> generált content volt.
de olyan szinten, hogy konkrétan azt már semelyik guide nem írta, hogy mi van, ha eltérő adattípus vagy eltérően formázott inputod lenne.
---
egyébként nagyon úgy néz ki, hogy vibe coding egy pontig pl BSc computer science programoknál működik. aztán utána gyanúsan eljön az a pont, hogy aki magától nem tud kódot olvasni és írni, az kb belefut egy betonfalba.
mondjuk globális publikációkat erről a területen még nem láttam, de pl a Microsoft pár héttel ezelőtti tanulmánya is ezzel egybevág. senioroknak nagyon jó (és ha senior vagy, akkor stimmel amit írsz, hogy genAI a te szinteden gyorsít), kezdőknél viszont akadályozza bizonyos kritikus kézségek kialakulását.
-
husztiimi
csendes tag
MPI-hoz a Komondor gépet használjuk: https://hpc.kifu.hu/hu/komondor
Ha a "probléma" nem indokolja az MPI használatot (ez néha-néha azért előfordul), és elegendő hozzá az openMP is, akkor arra pedig van két darab számítási nódusunk: az egyik AMD EPYC 9554 64-Core procikkal és 2.5TB memóriával, a másik pedig Intel(R) Xeon(R) CPU E7-8880 v2 procikkal és 3TB memóriával.
-
husztiimi
csendes tag
Sajnos pont ettől tartottam... A chatgpt egyik válasza a sok közül nekem is az volt, hogy felajánlotta, hogy ír egy olyat, ami a C-s modult használja... De amit írt nekem az nem fordítható le. Sajnos a neked írt kód sem fordul le. (Írtam eredeti posztomban, hogy: "Sajnos az AI (chatgpt) ebben nem tud segíteni.")
Félreértés ne essék, én is használom sokmindenre a chatgpt-t, pl. keresse meg a hibát egy adott kódrészletben, vagy írjon egy-egy kisebb részt. Néha ezeket jól megcsinálja. De sajna néha kurvára nem. Sajna a te "megoldásod" az utóbbiak táborát erősíti.
-
proci985
MODERÁTOR
-
axioma
veterán
Nem voltam, nem tudom szakmai szempontbol mennyire erdekes. Az en high level kepzettarsitasom inkabb, hogy az ujdonsagok reklamozasa, meg egy kicsit reszletesebb elmagyarazasa megy, de foleg b2b termekek szempontjabol. Aztan lehet hogy nem igy van... vagy hogy az is erdekes lehet [piackutatasnak, eszkozvalasztasnal].
-
inf3rno
nagyúr
Ritkán vannak, napi 1 deadlock volt mostanában. Ez is új fejlesztés eredménye. Most beleírtam a kódba, hogy legyen retry ilyenkor, aztán rendben van. Nem tudom még mit lehet kezdeni az ilyen deadlockokkal. Jó lenne, ha nem tábla szinten lenne a lock, de ránézésre a key-ek is rendben, úgyhogy nem tudom még mit lehetne tenni.
Még arra gondoltam, hogy újra lehetne tervezni az egészet és bekötni a sorba azt is, ami a deadlockot okozza. Végülis nem sürgős műveletről van szó, úgyhogy megvárhatja a többit.
-
inf3rno
nagyúr
Az van, hogy 100-asával szórjuk be tranzakcióba az egymástól nagyjából független SQL-eket, aztán így kötegelve küldjük be az adatbázisba, mert így nem ül le tőle az adatbázis szemben azzal, ha egyesével küldjük be őket. Aztán ha valamilyen SQL hibára fut, akkor elnyeljük a hibát, hogy ne veszélyeztesse a teljes tranzakciót. Ha mondjuk out of range okozza a hibát, akkor rendben bekerülnek a változtatások commitnál egyedül azt hagyja ki, aminél a hibát dobta. Azoknál a kivételeknél, mint pl. deadlock, ahol elszáll a teljes tranzakció, ott muszáj újrapróbálni az egészet, hogy ne legyen adatvesztés. Aztán ezért kellett különbséget tennem a két hibatípus között. De közben találtam egy drupal kódrészletet, ami alapján megírtam a saját ellenőrzőt hozzá, úgyhogy rendben van. Most várom az out of range hibákat, mert enélkül a fejlesztés nélkül esélytelen volt debuggolni őket. A deadlockra már nagyjából rájöttem, hogy mi okozhatja, de nem javítható, teljesen újra kellene tervezni az egész rendszert hozzá. Úgyhogy ma sem unatkozom.
-
proci985
MODERÁTOR
kb BSc masodev vegi szinten egy jo konyv, jo otletekkel.
amiket felhozol problemaknak azzal jellemzoen a konyv is explicit modon tisztaban van. avagy ha szorol szora betartod, valoszinuleg hasznalhatatlan lesz a kod. de ezt emlekeim szerint tenyleg, tobbszor emliti es emlekezteti az olvasot.
ettol fuggetlenul kezdeni valahol el kell kezdeni, hogy mondjuk ne hasznaljon magyar valtozoneveket, se hungarian notationt, se ekezeteket. meg olyan dolgok, mint az egyseges nevezektan, a (komponens szinten) egyseges scope azert modellezes szempontbol nem az ordogtol valo. ez nem a te szinted, es nem is egy senior szintje (sot jobb esetben, nem is egy juniore mert ezekkel erdemes lenne tisztaban lenni).
plusz az is stimmel, hogy foleg OO teruletre jo.
"there is no silver bullet"
-
cucka
addikt
A baj ezzel, hogy nem tudod tudományos igényességgel megfogalmazni, hogy mit jelent az, hogy "jó a kód". Ugyanúgy nem tudod megfogalmazni azt sem, hogy mi a "helyes absztrakció".
Van egy csomó metrika, sokszor egymásra ortogonálisak, és ezekből lehet okoskodni.
Az egyetlen amit meg tudsz objektíven fogalmazni, az a kód helyessége. -
Drizzt
nagyúr
Elolvasva ezt a kommentedet olyan érzésem van, hogy vagy te olvastál egy másik könyvet, vagy én. De persze nehéz megmondani, mert valójában amikor erről beszél az ember valakivel, akkor nem szimplán a könyvben elhangzó dolgok vannak benne, hanem az azzal összefüggésben máshol olvasottak is. Én az általad leírt dolgok egy részére határozottan nem ebben a formában emlékszem. Én biztosan elég régen olvastam, olyan 7 éve kb. Viszont vannak újabb könyvei is, lehet az azokban leírt pontosítások miatt emlékszem máshogy már a korábbi könyveire is.
Az viszont nagyon gykori, hogy a könyvben leírtakat félreérti, félremagyarázza valaki és ebben a formában erölteti. Az valóban káros tud lenni.
Én például a DRY-nál úgy emlékszem, hogy benne volt a könyvben, hogy olyan esetekben kell csak kiemelni a közös dolgokat, amikor azok nagyon nagy valószínűséggel együtt fognak változni a jövőben is. Valamiért dereng, hogy a dry kapcsán is előjön a yagni, de lehet ezt már megint csak a minden egyéb olvasmányaim miatt hozza elő most az agyam.
Szerintem a clean architecture könyv ami későbbi is nagyon jó, bár azt kell mondjam, hogy clean architecture/hexagonal architecture kapcsán amiket olvastam, a legtöbbször az a gond, hogy nem elég gyakorlatias a dolog. Pedig néhány praktikus megoldás végiggondolása nélkül az elmélet erőltetése elég szarul tud elsülni.
Van egyébként functional programming könyve is, de azt nem olvastam még.
Alapvetően a közepes programozók rossz megoldásai azért vannak, mert eleve nem képesek a kritikus gondolkodásra, meg a kontextusban értelmezésre. Tök mindegy, hogy mit olvasnak, a végeredmény az lesz, hogy közepes programozók maradnak. Biztos vagyok, hogy vannak olyan könyvek amiket elolvasva ettől sokkal nagyobb hülyeségeket is csinálnának.Engem elsősorban a refactoring for the sake of refactoring jellegű akciók zavarnak, de ez megint nem a könyvek hibája, hanem az azokat értelmezni képtelen embereké.
-
cucka
addikt
Szerintem itt félreértés van arról, hogy mire jó a Clean Code.
Ez egy tankönyv kezdőknek. Gondolatokat és szempontokat fogalmaz meg arra, hogy mi számít a szerző szerint jó kódnak, egy adott kontextusban.
Nem receptkönyv. Nem szabály-lista, amit ha vallásos dogmaként kezelsz, akkor automatikusan jó kódot fogsz írni.Tudományos bizonyítékot igazságtalan számonkérni. Arra sincs tudományos bizonyíték, hogy a DDD elveinek betartásával jól fogod modellezni a problémát. Ettől még használjuk, hiszünk benne, hogy működik.
És a DDD szerintem más szintje az absztrakciónak. Arról szól, hogy hogyan lehet az üzleti problémát kódként modellezni. A Clean Code meg arról szól, hogy hogyan írd meg az osztályodat úgy, hogy azt le lehessen tesztelni és más is megértse.
Azzal én sem értek egyet, hogy a Clean Code-ra dogmaként gondoljunk. De hidd el, a programozók többségének bizony jót tenne, ha képes lenne megérteni és alkalmazni azokat az elveket. Példának pont felhoztad, hogy mi van akkor, ha valaki nem érti a DRY elv lényegét. Nem a DRY elvvel van baj ott sem, hanem user error.
Egyébként ha már itt tartunk, szerintem a Clean Architecture egy sokkal jobb könyv.
Illetve Uncle Bob ír blogot is, mostanában funkcionális programozással foglalkozik, és minő meglepetés, a clean code elvek arra is alkalmazhatóak. Mert ezek elvek. Nem receptek, szabályok, előírások. -
cucka
addikt
Igen, teljesen felesleges a komment, ha azt mondja el, ami a kodbol is latszik.
Igen, és fordítva is igaz. Arra kell törekedni, hogy a kód önmagában elég beszédes legyen, ne legyen szükség kommentre. És jól írod, vannak dolgok, amik nem derülhetnek ki önmagában a kódból.Például a nagy klasszikusnál ha a függvény neve az lenne, hogy "fastInverseSquareRoot", akkor az az összes komment, amire szükséged van igazából.
-
cucka
addikt
-
-
martonx
veterán
Nézegetem, de nem igazán látom be, hogy ez mitől annyival másabb / innovatívabb, mint egy Azure / AWS cloud stack. Azokon ráadásul szinte bármilyen nyelven lehet programot futtatni ezen meg szinte csak javascriptben (plusz python és rust).
Ha megtennéd, hogy pár mondatban összefoglalod, hogy ez miért jobb? -
coco2
őstag
Barátkozom vele. Egy kérdésre viszont nehézkesen találok választ. Ahogy kinéz, cron triggerekkel elindítok valamit, aminek futnia kell X paraméterek között. Mondjuk, beleférek a korlátok közé, és legyűjtök adatokat. Háttértároló hogyan van? Hogyan tudok kommunikálni legyűjtött adatokkal?
-
coco2
őstag
Ha tranzakció alapon fut valami, és feltételezem a szigetelési szintek is a jelenkori átlagosak, akkor egy ügyes join query kb tucatnyi szervert egyszerre tud megfogni, mert zárolás alá kerül gyakorlatilag minden. Egy időben csak egy folyamat tud majd futni a db-ben. Vajon kitaláltak arra valamit, vagy azt csak elfogadják?
-
coco2
őstag
Memória kezelést köszönöm mindkettőtöknek.
BQ-nál amit írsz A.C.I.D. vagy B.A.S.E. alapon működik? (Egyértelműsítő link.)
-
coco2
őstag
Bevallom töredelmesen, nem tudom, miből van gyúrva a BigQuery a brossúra szöveg mögött. Átírták áradat feldolgozásra az sql scriptek funkcionalitását? Vagy ugyan úgy tranzakció alapú feldolgozás?
Swap. Egy sql szerver hogyan tudja kitalálni, hogy adott időpillanatban adott memória éppen fizikailag a ram-ban van-e, vagy kikerült swap-re? (Linux partition type 0x82, hogy konkrétak legyünk.)
-
coco2
őstag
Túlságosan kicsi lesz a kép az értékelhető tartalomhoz. Előbb ki kellene nagyítani, de akkor meg nem fér el a képernyőn. Húzni kell a képet széltől szélig, hogy screenelni tudd. És azt mind programozottan
Néztem amúgy, mit csinál. Ahogy kinagyítom, és húzom a tartalmat, letöltöget kép részleteket cdn-ről (pld ezt itt). Maga a kép téglalapokból van összerakva - összerajzolja canvas-on, ami épp látszik az oldalon. A tartalom nem domain védett, de gyanítom, hogy a tokenek időkorlátosak - ha csak félre nem programozták. Érdekes teszt lesz, hogy az a link fél nap múlva még mindig működni fog-e.
-
bandi0000
nagyúr
Királysàg
Igazàból mi pàr hónapja kezdtük el, de sztem kár volt...
Az érdekelne, hogy olyan esetben, amikor nagyon sok vàltoztatás érintene sok függvényt mit csinàltok?
Nàlunk az a mondás, hogy kb if-be berakjuk a feature-t, ami defaultom false, és így mehet be a trunkba, de pl tegnap amit csináltam 20 file-t érint meg isten tudja hány fv-t, szal nemtudom elképzelni, ilyen esetben mi történik
Ugye elvben a trunk based nek az az alapja, hogy unit testelve van minden, ami le is fut, ilyen esetbe kb nem kellene ez a flages jàték ami nàlunk van, de persze unit testek csapnivalók pàr kivétellel
-
coco2
őstag
>..latency vagy throughput...
A latency logikai szintig kap legalább +3 RTT pofont (logikai adatok szinkronizálása fürtön). Aztán az írási művelet latency-je kap lenyírást a memória miatt. A throughput a memória miatt rendesen több.
Adott gyakorlati helyzetben egy valódi teszt tudná megmutatni, mi hogyan alakul. Olyat az után tudok gyártani, hogy találtam egy értelmes célterületet. És azért tettem fel a kérdést
>BigQuery..
A BigQuery mintha tárhely kihívás lenne
Mit nem értettem meg a felvetésből?
@nemethg66
>..a mostanában felbukkant domain helyett..
A szakma nyelve az angol. A "domain" egy szakmailag korrekt fogalom. Gondolom az "entitás" a másik, amivel hamarosan problémád lesz. Sajnos a szakma területén egyiket sem fogod tudni megkerülni.
-
Hja, sok igazság van abban, amit írsz. Viszont azt is látni kell, hogy a programozási feladatok olyan méretűre nőttek, amelyeket már csak kooperációban lehet megoldani, ezért szétszakadt a szakma ezekre a részterületekre. Egy ideális világban nyilván mindenki piszok jó üzleti és technikai skillekkel rendelkezne, de azt te is tudod jól, hogy ez nem a jelenkor realitása. És így jutunk el oda, hogy én már örülök annak, ha egy BA-nak IT végzettsége van, ha egy architect ténylegesen dolgozott is az iparban, és ha egy fejlesztő képes komplex üzleti problémákat legalább alap szinten megérteni. Ez már egy elég jó alap az értékteremtéshez.
-
coco2
őstag
Egy 200ezer soros mákostészta kódját akár a konkurenciádnak a kezébe nyomhatod, mert annyira biztos, hogy azzal fejlesztői doksi nélkül kajak semmit se tudnak majd csinálni.
Szóval itt jön egy favicc. Ha az informatika üzletbiztonsága csak mondvacsinálva van, jelszót lopni nem az egyetlen fenyegetés. Profitális üzletté tud válni a programozók megölése is csak azért, hogy elvesszen az az információ, ami egyedül az ő fejükben van.
@Tapsi:
De bizony van értelme a mezei kicsi programozót eltenni láb alól.
-
martonx
veterán
Nem vagyunk egyformák. Nekem egy mappa felmásolás, és egy next-next-finish végig nyomása egyszerűbbnek tűnik, mint két rendszert docker compose-al megcsinálni, majd utána a docker run-okat, majd image másolásokat megcsinálni.
De ez abszolút szubjektív, ki ezt szereti, ki azt.
Azure-ban a free App service-el, semmilyen bottal nem tudod elérni, hogy pénzbe kerüljön, maximum a napi 60 percnyi futás limit után elérhetetlen lesz az oldalad a következő napig. Ha egy bot ráfekszik az ingyenes oldaladra szerintem ez bőven vállalható ezért a pénzért (ingyenes).
Per pillanat is fut így ingyen több webappom is (ok, amelyik alatt DB sincs, az tényleg ingyenes, ami alatt DB is van, az havi 5 EUR, kivéve ha Cosmos DB, mert abból van tényleges free tier is).@coco2: milyen első 12 hónapra? Nézd meg pl. ezt az appot: P92 Interest App egyedül a feladat leadása résznél nyúl DB-hez, az év 2 napján felskálázzuk a mögötte lévő App service-t, abban az egy hónapban elérjük az 1 EUR-os költséget, az év maradék 11 hónapjában pedig ingyen fut.
-
coco2
őstag
Idézet:
Up to 3 shared-cpu-1x 256mb VMs
Idézet vége.
Vax gépekkel meg vms-el egy ideje már nem találkoztam, de aki csak egyszer is lát olyan sebességet, amikor egy karakteres terminál prompt olyan sebességgel jelenik meg, mintha valaki kézileg írógéppel real-time éppen pötyögné be, az biztosan nem felejti el. Nagyjából olyan végrehajtási sebessége lehet egy vm-nek megosztott cpu-val és annyi valós rammal, amikor egy hdd-n lévő virtual memory-ból fut az egész oprendszer.
-
martonx
veterán
Ez már kicsit filozófia, de egy k8s-ben futó számtalan instance (app server, queue, db server stb) nem felhő? Csak éppen nem publikus, hanem privát, és kell hozzá egy komoly üzemeltetési tudás és egy komoly szerver plusz storage?
A kezdő kollégának a felhőt javasoltam, ahol a legegyszerűbb a nagyoknál kezdeni, ráadásul ingyenes / filléres.
Aztán később ha ez érdekli, persze lehet saját felhőt építeni.
Szerintem nem mondtunk egymásnak ellent, amit kerülni érdemes, pont amit a kolléga akarna, az a klasszikus szerverrel (vps, virtual machine) bohockodás.
Kivéve, ha valakinek pont az a kattanása, hogy ezredfordulós megoldásokkal játsszon.
Szerintem. -
coco2
őstag
Az nem is kérdés. A Facebook oldaluk szerint Ginop pénzt nyertek, amit Angular tanításra használtak fel. Félreérthetetlenül tipikus. De azon túl a Facbook oldalukon csak szülinapi tortázgatás van. Arról lenne jó belsős infó, hogy pályázatok megnyerésén túl csinálnak-e bármit, amiért szakmai guruk pontot adnának nekik? És azt illetőleg nem a NER-Lovagokra gondolok.
-
coco2
őstag
Köszönöm. Még egy apróság. Nem találtam drótozatlan példát konkrét adattárolási műveletre. Van rá valami kubernetes-spec api beépített orm-szerűséggel (nem találtam nyomát), vagy az egyébként használatos sdk-n keresztül (környezete válogatja mikor éppen mi) megy az adathozzáférés?
-
-
JoinR
őstag
Erre jutott a management, amikor azzal a követelménnyel találkoztak, hogy az eltárolt adatot 10 évig meg kell tudni mutatni, hogy "fizikailag" hol van tárolva (gyógyszeripari logok). Mivel az AWS DC-jébe nincs belépőkártyájuk, ez maradt.
Ja a CPU limitről eszembe jutott egy use-case, amikor muszáj volt beállítani. Pl. Gradle pipeline-nál, ahol összefüggött a CPU-memory usage, folyamat OOM volt, ha el volt engedve a CPU.
A másik dolog a multi-tenancy, egyszerűen nem tartanám komfortosnak a végtelen burstinget, főleg, hogyha a manifesteket más csapatok is létrehozhatják. -
JoinR
őstag
Igen, igazad van.
Ettől függetlenül a request-en felüli cpu felhasználás szerint lehet(ne) skálázni. A mostani helyen, ahol dolgozom, adatvédelmi okokból szépen átálltak EKS-ről egy random privát felhőbe, ahol a k8s node-okat a rendszergazda kézzel telepíti és adja hozzá vSphere-ben... -
coco2
őstag
Neked fétised lehet hogy üres frázisokat puffogtatsz. Tudod, van ahol a lelki szemetes láda fizetésköteles szolgáltatás. Te meg folyton ingyen akarod
Amit felmérni gondoltam, az a levesben a hús, a körítése nélkül a kubernetest illetően. És meg is kaptam a segítséget, a téma részemről lezárva.
-
axioma
veterán
Egy teny: az USA-ban is sokaig kellett a pozitiv diszkriminacio menjen, hogy a negativ eltunjon az afro-amerikaiakrol. Tehat van akinek be kell vallalni a pozitiv diszkriminaciot, de az meg sajnos problemakat fog okozni, engem is volt mar munkatars aki ugy belyegzett, hogy nekem konnyu nokent, o mint feher 30 eves ferfi aki a vegen a sok DEI elv miatt negativ diszkriminacioban talalja magat...
-
Az aránytalanság mértékében tartom kizártnak a biológiai okot. Miért választja az egyébként matekos-reálos területet sokkal-sokkal több nő, mint a szintén matekos-reálos másikat? Sok helyen még a felvételi tantárgyak is azonosak.
Nem a férfi/női különbségeket tagadom, erről szó nincs.
-
coco2
őstag
@Tapsi hitetlenkedett, hogyan tudnának lehetségesen kikerülni biometrikus adatok. Én arra írtam. Teljesen mindegy, hogy single- vagy multi-factor, mert nem az a lényege a sztorinak, hogy emberünk bejutott-e a lakóházi ajtón, vagy sem, hanem hogy a biometrikus adatokat annyira egyszerű begyűjteni. A szenzorok nem csak céges belépőkapuknál, meg banki átlépő kapuknál tudnak üzemelni, hanem személyi szférában is, és azok a szenzorok ugyan azokat az adatokat (kompatibilis adatokat) gyűjtik be. Aztán vagy figyelmesen vannak kezelve a hitelesítő adatok, vagy nem. Céges épületben, bankoknál, katonaságnál, egyebek, elhiszem, hogy figyelmesen kezelik a biometrikus adatokat. De személyes szférában szinte egészen biztosan szanaszét hagyva lesznek.
-
axioma
veterán
Nem feltetlen. A jelszavaim generalodnak a belepesre szolgalo helybol egy sajat elkepzeles szerint es mindig egy egyeni koddal kombinalva, amibol parevente van csak valtozas (2-3 generaciot vissza tudok probalni), en mindenhol ahol lehet egyeni bejelentkezest hasznalok es nem irok le/jelszokezelozok semmit... meg amugy is ha tul ritkan hasznalom, vagy jon figyelmeztetes, vagy lehet jelszoemlekeztetozni.
[most fogok bazi nagyot szivni azzal, hogy a webmail.hu fizetos lesz, es vannak oda bekotott jelszoemlekeztetoim, me'g azt se tudom hol csinaljak helyette mail cimet, ami nem annyira trivialisan kotheto hozzam mint a domain-unk, ez ugyanis a "neked nem kell tobbet tudnod rolam" helyekre hasznalt cim - es nem, a gmail -est se hasznalom levelekre]
Minel kevesebb info van osszekotve, annal jobb. -
coco2
őstag
Értem. Megfigyelésem a dilettáns népekről, hogy ha nincsenek észérveik, helyette tekintélyérvekkel próbálkoznak, és amikor az nem jön össze, utoljára még személyeskedéssel. Félre ne értsd, semmi bajom azzal, hogy szélhámosokkal van tele a szakma, mert ti ügyesek vagytok pénz lopásban, és az árak felverésében. Abból másodkörben még nekem is van hasznom. Hanem éppen azért jobban örülnék, ha legalább a saját szakmai vonaladhoz nem lennél teljesen tehetségtelen. Mondjuk annyira, hogy a fenti típushibát elköveted kommunikációban. Te meg még itt egy páran mások is. Ha az első dobás nem jön be, inkább add fel. Semmit sem nyersz azon, ha erősködsz.
-
coco2
őstag
Ahogy te azt elképzeled
Bárhol biometrikus védelmet felszerelnek, egy épület belépés, vagy valami, amit a kutya sem fog komolyan venni, mint fenyegetést, a biometrikus adataid ott tárolásra kerülnek, és a fene tudja, mennyire lesznek védve, vagy éppen direkt eladva. A biometrikus adatok statikusak, azt nem tudod lecserélni, mint egy jelszót. Bárki bárhol bármikor egyszer ellopta, hosszú időre ellopott téged. A biometrikus adatok akár évtizedes vonatkozásban sem változnak.
-
coco2
őstag
Valóban keychaint használok (3 külön keychaint), de azok titkosított állományok, amikhez külön jelszó tartozik, és egyedül az én kezemben van mindegyik. Fegyveres támadás kellene hozzá, hogy azt ellopják, és csak én miattam az nem éri meg. És az a valódi védelem. Hogy nem éri meg.
Bármi központosított hitelesítésnek az a rákfenéje, hogy egyszer oda betörnek, mindent visznek el. Lehet, hogy a 95%-a teljesen jelentéktelen érték lesz, de 1%-ban lesznek 1-2k usd-s értékek. Egy nagyobb data vault esetében az az 1% milliárd usd-ket tehet ki. Csak idő kérdése, mikor dönt úgy egy terror szervezet, hogy na, akkor oda most ők betörnek.
Gondolkodtam a SIM swap támadáson, és úgy látom, hogy az egész egy fake. Ami esetet leír, az a mobil szolgáltató direkt hanyagságára épít, és mostanra szerintem nem reális probléma. Egyszer volt Budán kutyavásár.
-
Ezt viszont jó lenne tisztázni, mert kulcskérdés. Ha a banki appoknál tényleg az van, hogy az authentikáció a készülék által történik, akkor gyakorlatilag megvalósult a 0. pontban általam felvázolt scenario. Innentől már tényleg csak egy lépés az, hogy ne a készülék legyen a szolgáltató, hanem bármi más.
-
sztanozs
veterán
Igen, ez valoban igy van, de uj identitast csak a szemlyazonossog ellenorzeset kovetoen lehet(-ne) az ugyfelszamlahoz kotni. Raadasul ha harmadik fel vegzi az azonositast, akkor a harmadik fel automatikusan bele kerul az adott orszag jogszabalyai alapjan a penzintezeteket felugyelo szervek hataskore ala, meg kell felenie a penzintezeti torveny rendelkezeseinek es a helyi hatosag rendszeresen auditalja majd ezek utan.
- vagy: azonositod maga egy korabbi azonosito hasznalataval (hiszen igy kialakul egy chain of trust)
Ez azert problemas, mert az azonosito kompromittalodasa eseten megtorik a chain of trust. Ezert is problemasak a sim swapping es hasonlo visszaelesek. Egy hosszabb lancolat eseten meg kevesebb kontrollja van a penzintezetnek. -
-
sztanozs
veterán
A KYC ortogonalis problema. Amirol szo van, az az autentikacio, nem a szemelyazonositas.
Egy banki alkalmazas eseteben az authentikacio maga a szemelyazonositas.Ha csak azt nezed, hogy mennyi security research anyag jon ki mondjuk egy Project Zero-bol, meg barmelyik banki securitys csapattol.
Egy banki security-s csapatnak nem feladata a vilag osszes alkalmazasanak vizsgalata, hanem csak annak a nehany tucat-szaz-ezer alkalmaznak, amit az adott penzintezetnel hasznalnak. Masreszt egy ilyen csapat nem fogja nylvanossagra hozni az altala hasznalt komponensek sebezhetosegeit, hanem direktben kommunikalja le a gyartokkal, jol megfontolt onerdekbol... -
sztanozs
veterán
Mind a kettore
- passwordless login legfeljebb biometrikus lesz, de remelem nem erem meg... egy banknak mindig bizonyitania kell tudni, hogy az ugyfel lepett be. Ez hogyan biztosithato, ha az authentikaciot valaki mas vegzi el? Vajon a FB vagy Google accounthoz kell szemelyazonositas (KYC)?
- a banki security-re meg szemelyes tapasztalatbol mondom (tobb bankot is megtapasztalva), hogy barmelyik nagy szolgaltatoval felveszik a versenyt felkeszultsegben. -
coco2
őstag
Hmm, oké, szóval a telefontársaságoknak nem ártana bevezetnie egy felhasználói tájékoztatót, miszerint a felhasználó hozzájárulását kérik egy támdható kényelmi szolgáltatás nyújtásához, amihez ha a felhasználó nem járul hozzá az aláírásával, akkor nem nyújtanak olyat, és emberünknek személyesen kell bemennie az ügyfélszolgálatra személyi igazolvánnyal meg olyasmi.
Vajon azt a telefontársaságok még mindig nem tették meg? Ez a sim swap még mindig aktuális? A tanulmány óta eltelt 3 év.
-
dabadab
titán
Nekem egyelőre azzal van gondom, hogy ez jelenleg össze van kötve egy közösségimédiás profillal, amit tulajdonképpen bármikor, érdemli indoklás nélkül (mondjuk ha lenne, az se sokat segítene) letilthatnak és akkor ugrott a kapcsolt bejelentkezés is.
Meg mondjuk a userek talán jobban vigyáznak a banki jelszavukra, mint a mindenhol használt facebookos ID-jükre, amivel kapcsolatban folyamatosan megy a "feltörték a facebookomat" jajgatás (fenéket törték fel, ott hagytad a telefonod kilockolatlanul).
-
fatal`
titán
Ok, kivancsi vagyok, hogy miert nem tartanal bizonsagosnak egy 'Login with Facebook' gombot.
Nem ezt nem tartom biztonságosnak, hanem magát a facebookot. Ha a bank fejleszti a saját authentikációját és kompromitálódik, akkor kártalanít. Ha ugyanez egy 3rd party céggel történik, akkor sok sikert.
Felőlem ott lehet mint lehetőség, de teljesen feleslegesnek tartom.
-
coco2
őstag
>Az SMS-alapu 2FA talan a leggyengebb az osszes kozul, ezerszer beszopattak mar vele az embereket.
Köhöm, valami részletet hallhatnék erről, mert pislogok rá. Szóval itt van nálam a telefonom, küld egy sms-t, benne egy eredetileg 4 jegyű, később 6 jegyű, mostanra 8 jegyű szám, amit van 5 perce kitalálnia a pacáknak. Ellopják a telefonomat + kitalálták a jelszavamat, vagy hogyan?
Ha ki tudnak találni jelszót + el tudnak lopni telefont, ellopnak azok authentikátort is, ugyan mi tudna erősebb lenni a mezei double-step authentikálásnál?
-
fatal`
titán
A Facebookhoz is teljesen szabvanyos TOTP van. Szerintem keversz valamit.
Nem keverek semmit, az eredeti kérdés így hangzott:
"Biztonságosnak tartanátok mondjuk egy FB bejelentkezést akár a netbankotokba?"Ennek nincs köze a TOTP-hez és részemről nem lépnék be facebook fiókkal a netbankba. Akkor se ha szabányos OpenID, semmi keresnivalója nincs ott.
A TOTP-t én kevertem hozzá, hogy a Tokent örülnék, ha kiváltanák szabványos TOTP-vel az SMS (ez szar, sok banknál már nincs is) meg a saját kódgenerálás helyett (ez meg felesleges, ha van szabványos - pl. CIB). Csak egy indokot írtam, hogy szerintem miért használnak a bankok saját szoftveres tokent. Meg az is benne lehet, hogy a hardveres tokenek meg ugyanazzal az algoritmussal (vagy ugyanazon az infrán/környezeten) működnek, azt is lehet kérni.
-
fatal`
titán
Tudom, hogy van, de a bankok nem használják.
A saját authja mellett gondolom az az érv, hogy azt el tudják magyarázni Manci néninek, hogy hogy kell beállítani, a Google Authenticatort meg nem.
A szabányos TOTP-t támogatom, nyugodtan elférne KeePassban vagy Google Authban ez is.
A 3rd party szarokat viszont nem támogatom, nehogy már facebook-kal kelljen belépni a bankba (persze mint opció ott lehet, felőlem mindenki azt csinál, amit akar).
-
K1nG HuNp
őstag
LinkedIn és a szerintem profilomba illő cégek CV-vel való bombázásán kívül van olyan dolog amit mindenképpen érdemes csinálni? Igazából most van időm belerázodni ebbe az egész külföldi cégnél munkakeresésbe.
Gondolom csak az első ilyen behúzása nehéz, de jelenleg tényleg szkeptikus vagyok kicsit, hogy nem tudok ahhoz eleget, hogy egy cég lenyúljon egészet idáig hozzám. -
baracsi
tag
Nem értelek, hogyan csinálsz akkor technikai felhasználót a teszt rendszerben?
Szerk: ja értem, a cég csinálja meg neki, az is jó, nyilván valamiféle cégként a saját belépésével vagy alkalmazottként van valami hozzáférés. Nyilván én is a saját cégünk adataival léptem be még anno a fejlesztés kezdetekor, hogy megnézzem az eredményt, meg hogy technikai felhasználót hol kell csinálni, mert a felhasználóknak fingjuk nem volt induláskor, hogy mit kell csinálni.
Szerk2: a technikai érvénytelenítés jóváhagyásához viszont sanszos, hogy meg fogják adni az adatokat, mert képtelenek bizonyos helyeken erre rákattintani, ez tapasztalat
-
FeniX-
senior tag
@Marky18: Köszönöm, ezt a lehetőséget megnézem!
@dabadab: Igen, és két különböző framework-ön.
@emvy: Sima mysql. Ipari cikkek vannak a webshopon és hozzá tartozó árak, tulajdonságok, ilyesmik, kapcsolótáblákkal.A csavar az a dologban, hogy:
1.) A tükör oldalon időközben bekerülhetnek függetlenül további termékek is, és így is konzisztensnek kell lennie az eredeti termékekkel a változások tekintetében.
(Magyarul több forrásból "szedi" az adatait, de minket most csak az érdekel, hogy a számunkra megadott forrással legyen 'pariban' és lehetőleg a többi inzertálás ne rontsa el a konzisztenciát.)2.) 1 api hívás csak 1 tábla változásait adja vissza json-ban vagy xml-ben.
(első hívás = teljes adathalmaz 1 táblára vonatkozóan, további hívások = csak a változás. ; Ezt gondolom, valahogy api kulcs alapján trackeli a forrás-api, illetve lehet force-olni, hogy teljes adathalmazt adjon vissza, de ez limitált.)
Kb. 21 tábla van a forrás webshopban, amiből 12-t kellene használni. (A többi rendelések, és ügyféladatok, amit most nem fogunk igénybe venni) -
coco2
őstag
Én nem arra értettem, hanem például arra, amikor valaki értetlenkedik, kétszer elmagyarázzuk, mi van, és ha nem érti, és tanulni sem akar, elhajtjuk a pi**ába, és ha szókimondóan, hát akkor szókimondóan. Én arra az egyre értettem. A másikat illetően nyitott kapukat döngetsz. Végső soron nekem is annyi a véleményem a kezdőkről, hogy tanuljon, vagy fizessen, vagy távozzon. És abból a háromból válasszon mindenki valamit magának. Negyedik opciót én sem kínálok. Írtam talán bárhol bármi mást?
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- LEGO klub
- exHWSW - Értünk mindenhez IS
- WLAN, WiFi, vezeték nélküli hálózat
- Milyen billentyűzetet vegyek?
- Milyen notebookot vegyek?
- Ford topik
- Gaming notebook topik
- Kertészet, mezőgazdaság topik
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- További aktív témák...
- AKCIÓ! ASUS B460M i7 10700 16GB DDR4 512GB SSD GTX 1080Ti 11GB KOLINK Observatory TG TT 600W
- Bomba ár! HP ZBook Studio G5 - XEON I 32GB I 512SSD I Nvidia I 15,6" 4K DreamColor I Cam I W11 I Gar
- Új! HP 230 Vezetéknélküli USB-s Billentyűzet
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- Csere-Beszámítás! Asus Számítógép PC Játékra! R5 1600X / GTX 1080 8GB / 32GB DDR4 / 256SSD + 2TB HDD
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest