-
Mobilarena
Új hozzászólás Aktív témák
-
válasz
husztiimi
#20810
üzenetére
> Ha meg át lesznek téve, akkor majd megmérjük, hogy mi legideálisabb inputtól függő választás? openMP + GPU? MPI + GPU? MPI + openMP + GPU
Ezeket szerintem ki lehet számolni, következik a feladat struktúrájából. Például belefér-e a mátrix a GPU memóriájába? Ha igen, mennyi idő megcsinálni vs mennyi idő 1) feltölteni 2) odavinni a node-ra? Ha jól láttam, 200 gbps interkonnekt van, azért az nem nagyon gyors (késleltetést nem tudom). Szóval én először biztos csinálnék papíron egy esztimaciot.
-
válasz
husztiimi
#20797
üzenetére
o3-high-t probaltad?
program cusolver_demo use iso_c_binding implicit none interface function cusolverDnCreate(handle) bind(C, name="cusolverDnCreate") import :: c_ptr, c_int type(c_ptr), intent(out) :: handle integer(c_int) :: cusolverDnCreate end function cusolverDnCreate function cusolverDnDestroy(handle) bind(C, name="cusolverDnDestroy") import :: c_ptr, c_int type(c_ptr), value :: handle integer(c_int) :: cusolverDnDestroy end function cusolverDnDestroy function cusolverDnDsyevd(handle, jobz, uplo, n, d_A, lda, d_W, d_work, lwork, d_devInfo) & bind(C, name="cusolverDnDsyevd") import :: c_ptr, c_int, c_double, c_char type(c_ptr), value :: handle character(c_char), value :: jobz character(c_char), value :: uplo integer(c_int), value :: n type(c_ptr) :: d_A integer(c_int), value :: lda type(c_ptr) :: d_W type(c_ptr) :: d_work integer(c_int), intent(inout) :: lwork type(c_ptr) :: d_devInfo integer(c_int) :: cusolverDnDsyevd end function cusolverDnDsyevd function cusolverDnDsyevd_bufferSize(handle, jobz, uplo, n, d_A, lda, d_W, lwork) & bind(C, name="cusolverDnDsyevd_bufferSize") import :: c_ptr, c_int, c_char type(c_ptr), value :: handle character(c_char), value :: jobz character(c_char), value :: uplo integer(c_int), value :: n type(c_ptr) :: d_A integer(c_int), value :: lda type(c_ptr) :: d_W integer(c_int), intent(out) :: lwork integer(c_int) :: cusolverDnDsyevd_bufferSize end function cusolverDnDsyevd_bufferSize end interface integer(c_int) :: n, lda, lwork, status type(c_ptr) :: handle type(c_ptr) :: d_A, d_W, d_work, d_devInfo real(c_double), allocatable :: h_A(:,:), h_W(:) character(c_char) :: jobz, uplo integer :: i, j n = 100 lda = n allocate(h_A(n,n)) allocate(h_W(n)) do i = 1, n do j = 1, n h_A(i,j) = i + j end do end do jobz = 'V' uplo = 'U' status = cusolverDnCreate(handle) if (status /= 0) then write(*,*) "Hiba: cusolverDnCreate" stop end if ! GPU-memória allokálás, pl.: ! call cudaMalloc(d_A, n*n*sizeof(real(c_double))) ! call cudaMalloc(d_W, n*sizeof(real(c_double))) ! Másolás: h_A -> d_A (cudaMemcpy) ! Lekérdezzük a szükséges workspace méretet: status = cusolverDnDsyevd_bufferSize(handle, jobz, uplo, n, d_A, lda, d_W, lwork) if (status /= 0) then write(*,*) "Hiba: Buffer méret lekérdezés" stop end if ! GPU workspace allokálása a lwork méret alapján: ! call cudaMalloc(d_work, lwork*sizeof(real(c_double))) ! call cudaMalloc(d_devInfo, sizeof(integer(c_int))) ! Eigen-dekompozíció meghívása: status = cusolverDnDsyevd(handle, jobz, uplo, n, d_A, lda, d_W, d_work, lwork, d_devInfo) if (status /= 0) then write(*,*) "Hiba: cusolverDnDsyevd" stop end if ! Eredmények visszamásolása: pl. ! call cudaMemcpy(h_W, d_W, n*sizeof(real(c_double)), cudaMemcpyDeviceToHost) ! Ha az eigenvektorokra is szükség van: call cudaMemcpy(h_A, d_A, n*n*sizeof(real(c_double)), cudaMemcpyDeviceToHost) ! GPU erőforrások felszabadítása: ! call cudaFree(d_A); call cudaFree(d_W); call cudaFree(d_work); call cudaFree(d_devInfo) status = cusolverDnDestroy(handle) if (status /= 0) then write(*,*) "Hiba: cusolverDnDestroy" end if write(*,*) "Eigenértékek:" write(*,*) h_W end program cusolver_demo
-
#20780
emvy
félisten
whatsthecred
#20779
válasz
whatsthecred
#20779
üzenetére
Javaslom a ChatGPT-t vagy Claude-ot.
-
válasz
inf3rno
#20737
üzenetére
Milyen adatbaziskezelo ez?
Eleg meredeknek hangzik, amit irsz, es szerintem nagy terheles eseten ennek lassabnak kene lennie, mintha minden egyes muvelet kulon tranzakcioban van. Valamilyen MVCC implementacio biztosan van az RDBMS-ben, szoval ha sokaig vannak nyitva a nagy tranzakcioid, az jo esellyel megszivatja a vacuum folyamatokat.
Szoval szinte biztos, h amit csinaltok, az rossz otlet, de mivel nem irtal le eleg reszletet, ezert nem tudom, hogy mi a rendes megoldas.
-
válasz
inf3rno
#20735
üzenetére
Egyaltalan nem vilagos szamomra, hogy mit akartok elerni, mit ertesz 'tehermentesites' alatt, mi az, hogy 'nagyjabol fuggetlen', stb.. Leirnad a kontextust? Az se vilagos, hogy lehet tranzakciot committalni, ha hiba tortenik a tranzakcio kozben. Milen adatbazisrol van szo egyaltalan?
-
-
válasz
Drizzt
#20692
üzenetére
Oke, adom, hogy valojaban nincs baj a tartalommal ugy altalaban -- a bajom leginkabb a dogmakkal van, ami nagyon jellemzo a szakmara. Az egesz programozoi vilag tele van anekdotalis fassagokkal, igazabol nincsenek reprodukalhatoan jol mukodo mintaink.
OOP, clean code, agile ... szerintem mindenki latja, hogy mennyi szarsagot csinaltak mar a vilagban ezen elvek 'neveben'. Amikor a Telekomnal megvan 2.5 evre elore a pontos szkop es a pontos hatarido, de minden heten eljatsszak az agile ceremoniakat. Amikor bejon a 'tapasztalt programozo' csavo a ceghez, ranez egy tenyleg szar kodra, 2 honapot refaktoral, a vegen lesz clean code, acyclic visitor, decoupling meg minden, de ugyanugy nincsenek jol megcsinalva a tranzakciohatarok, mint korabban; es ezzel csak annyit ert el, hogy meg nehezebb lesz megcsinalni jora.
Nahat, nekem ezekkel van bajom, megutaltam a dogmakat.
-
> fastInverseSquareRoot
Konkretan az a neve, szoval ezzel szerintem nincs gond. (Ha C programozo vagy, akkor kiveri a szemed, ha valaki InverseSquareRoot-ot ir rsqrt helyett, ertheto modon.) Szoval az olvashatosag gyakorlott szemnek szerintem teljesen oke.
A komment, ami szerintem hianyzik, az valami utalas arra, hogy ez miert is mukodik.
Szoval a jol olvashato kodnal szerintem feltetelezhetjuk, hogy az olvaso ismeri a programnyelvet. Mutatok egy teljesen jol olvashato kodreszletet:
s:.*|":"\:*i:"\n\n"\:1:`:i/5.txt / seedsr:{R{,/+(y;x)}\:0N 2#-1_0,/*R:a@\:<*a:|+(++\2#'0 2_)'.:'1_"\n"\:x}'1_i / rangessplit:{r@&</'r:(*|y)-(*y)-(*|x)&(*x)|*y:y,\:,(://*y;*|x)} / split a range according to a map{&/*:'(+\'x)(,/split\:)/r}'(s,'1; 0N 2#s)Ez barmelyik programozonak, aki gyakorlott k-ban, teljesen olvashato. (Kb. hat honap utan en is ugy olvastam, mint az angolt.) (Ez egy Advent of Code feladat megoldasa.)
-
> Ehelyett az állítás, hogy a jól megírt kód önmagában olvasható, nem szükségesek hozzá kommentek.
Igen, teljesen felesleges a komment, ha azt mondja el, ami a kodbol is latszik. A komment arra jo, hogy olyasmit mondjon el, ami a kodbol nem latszik (mert nem latszodhat). Peldaul ha olyasmit csinal, aminek valami specialis uzleti hattere van.
Vagy ugye a nagy klasszikus:float Q_rsqrt( float number ) {long i;float x2, y;const float threehalfs = 1.5F;x2 = number * 0.5F;y = number;i = * ( long * ) &y; // evil floating point bit level hackingi = 0x5f3759df - ( i >> 1 ); // what the fuck?y = * ( float * ) &i;y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removedreturn y;}Ide jo lett volna ket plusz sor komment, pedig 100%-ig olvashato a kod.
Es aki azt mondja, hogy John Carmack gyenge programozo, azt hadd rohogjem ki
-
Par problema, csak igy hasbol:
- tulzottan preszkriptiv, es foleg a kozepes programozokban azt az erzetet kelti, hogy a kod attol lesz strukturalt es atlathato, hogy pl. sok rovid metodus van (valosag: a kod attol lesz jo, hogy korrektul modellezi a problemat)
- tudomanytalan: semmilyen bizonyitek nincs arra, hogy 10 darab 10 soros fuggveny atlathatobb/karbantarthatobb, mint 1 db 100 soros. Neha igen, neha nem - kezdoket jo otlet erre biztatni, de komplett cegek komplett kozepes programozohadseregei gondoljak azt, hogy ez a 'megoldas'
- DRY DRY DRY: ebbol van az, hogy kozepes programozonk meglat ket metodust, ami 98%-ban ugyanazokat a sorokat tartalmazza, es refaktoralja egy metodussa. Azt nem fogja fel, hogy ha a ket metodus valojaban masra volt jo (szemantikailag/modellezes-ugyileg) innentol ugy nez ki a kod, mintha tenyleg ugyanaz lett volna a ket metodus feladata, es megteveszti az olvasot
- OOP-t eleve sokkal kevesbe tartjuk manapsag 'mindenre alkalmas' modszernek, mint regen
- a konyv tele van olyan kovetendo (!) peldakkal, ahol a metodusoknak abszolut varatlan side effectjei vannak
- a konyv az elozo ket pont miatt total rossz tananyag multicore/multithread vilagbanFelreertes ne essek: van benne egy csomo jo meglatas. A baj az, hogy ossze van keverve egy csomo haszontalan tanaccsal, es ez felrevezeto.
Egyebkent olyan cegeknel szoktak nagyot menni ezek a konyvek, mint pl. az EPAM. Aki olyan helyen szeretne dolgozni, annak hajra.
----
Szoval szemely szerint azt gondolom, hogy a programozok legfobb feladata a vilag (domain, uzleti problema, technikai problema) megertese. Otmilliofelekeppen le lehet kodolni dolgokat, de legfokepp attol szarodnak el a projektek, hogy a programozo nem erti, hogy mit is kene megcsinalnia. Ha vilagosan erti, es a program azt fejezi ki, amit kell, akkor lehet OOP, funkcionalis, Haskell, J2EE, Javascript -- valoszinuleg jo lesz.
Talan az egyetlen orokervenyu szabaly az egyszeruseg. Konyvbol meg pl. a Domain Driven Design.
-
-
#20636
emvy
félisten
Fire/SOUL/CD
#20635
válasz
Fire/SOUL/CD
#20635
üzenetére
wat?
-
#20633
emvy
félisten
MotoHacker
#20632
válasz
MotoHacker
#20632
üzenetére
Ha tudjatok jol specifikalni, h mire van szukseg, arra lehet adni egy projektarat. Ha nem teljesen vilagos, akkor meg vagy merfoldkoveket araztok, vagy T&M alapon (ez utobbi lenyegeben oradij/napidij).
Az elso esetben ugy erdemes, h pl. valaki mond egy arat arra, h felmeri a feladatot, aztan utana magara a feladatra.
-
Ha atallitod 38-ra a maximumot, akkor 36-ig tudja majd allitani a user.
Az altalad leirt viselkedes pontosan dokumentalt. [link]
". The maximum value that can be reached through user interaction is equal to 1 plus the Maximum property value minus the LargeChange property value."
The maximum value that can be reached through user interaction = 1 + 36 - 3
-
válasz
martonx
#20573
üzenetére
Nem mindenben egyertelmuen jobb, hanem inkabb 'mas', de nekem tetszik az, ahogy a CF tervezi ezeket.
Peldaul: Cloudflare R2 -- olyan object store, aminel az egress koltseg 0. Ez egesz mas, mint a Google/MS/Amazon fele modell, ahol nagy szopasokba belefuthatsz, ha valaki elkezdi tul sokat olvasgatni a bucketeidben levo adatot, plusz nincs migracios koltseg, ha el akarod vinni.
Vagy a CF Durable Objects -- ilyen feature set igazabol nincs is nagyon mashol.
Szoval nem azt mondom, h papiron mindenben megveri a tobbieket, hanem azt, hogy amikor CF cuccokat hasznalsz, akkor tenyleg azt erzed, hogy wow, hat ez 'just works'.
En anno azert valasztottam GCP-t pl. Azure helyett, mert az Azure anno papiron _mindent_ tudott, de kb. semmi sem mukodott stabilan. Tehat pl. egy atlag CTO siman ramutatna az Azure-ra, hogy az pont jo lesz, de azt nem mondjak az Azure doksik, hogy pl. az AKS 1000-bol hanyszor szarja ossze magat (mert par evvel ezelott tulzas nelkul kb. 100x annyi problema volt vele, mint a GKE-el).
Nagyon latvanyos peldaul, hogy egy CF WAF-et mennyi ido beallitani, es ugyanez mennyi ideig tart pl. egy Azure WAF vagy GCS Cloud Armor eseteben. Elobbiknel kivalasztod, hogy havi $0, $200 vagy Enterprise plan, utobbiaknal eleve kurva nehez kitalalni, hogy mennyit fogsz erte fizetni, de siman lehet, hogy evi 50000 dollarral fogsz indulni (ugyanaz a CF-nel havi 2400).
Szoval osszefoglalva: egyszeru, olcso, just works, abszolut developer friendly szinte minden, amit csinalnak.
-
válasz
Drizzt
#20538
üzenetére
Google, Twitter es Amazon backendjeinek nagy resze. Bazel. Az osszes JetBrains IDE. Minecraft. Lenyegeben a teljes Android okoszisztema (bar most Kotlin lett a meno, de az azert szinte Java). Az osszes Atlassian termek. Oracle. SAP nagy resze. Netflix backendjeinek nagy resze. LinkedIn backend. Salesforce nagyresze.
Az a helyzet, hogy a Java megnyerte az OOP backend kategoriat. Az OOP mostmar kezd kevesbe nepszeru lenni, igy csokken a Java nepszerusege is.
-
psql-nel kulon allitod a working_mem-et, es a diszket hasznalja spillover eseten (es azt is megmondhatod neki, h a diszk mennyivel lassabb/gyorsabb, mint a memoria)
bq-nal, mint a tobbi big data db-nel is, ugy mukodik a dolog, h replikalva van az adat gyors tarolokon, szoval mondjuk egy aggregacio eseten gyorsabban tudsz vegigmenni az adatokon, mint egy eros szerver memoriasavszelessege
-
> Ha feliratkozok egy queue-ra, azt valami háttér szolgáltatás időnként kérdezgeti, és automatán áttölti helyi adattárolóra, vagy a rákérdezés pillanatában fog szinkronban elmenni távolra, megnézni, van-e új üzenet, és akkor kezdi letölteni?
az utobbit adatbazisnak hivjak, az elobbit meg pub/sub (queue) rendszernek
-
válasz
F-ECT$
#20218
üzenetére
Eleg trukkos, mert a kepek zoomolhatoak, es kisebb elemekbol rakja ossze (zoom szinttol fuggoen).
Nekem most elsore az jutott eszembe, h headless bongeszovel ossze lehet hekkelni.
pip3 install shot-scraperplaywright installaztan:
#!/bin/bash
BASE_URL="https://maps.hungaricana.hu/en/MOLTerkeptar/29646/view/?pg="
OUTPUT_DIR="screenshots"
mkdir -p $OUTPUT_DIRfor i in {1..577}
do
URL="${BASE_URL}${i}"
OUTPUT_FILE="${OUTPUT_DIR}/screenshot_${i}.png"shot-scraper $URL \
--wait 5000 \
--width 1920 \
--height 1080 \
--output $OUTPUT_FILEdone
... ezt kene finomhangolni
-
válasz
Vision
#20046
üzenetére
Igen. Szerintem keveredik a fejedben a 'webes' es a 'krossz-platform' fejlesztes. Az elso generacios krossz-platform fejlesztoeszkozokkel sokszor egy webappot fejlesztettel, ami utana egy beagyazott webbongeszoben futott. Egyreszt ez lassabb (volt), mint a nativ kod, masreszt nem nezett ki ugy, mint a nativ widgeteket hasznalo app.
Viszont a Flutterrel vagy Unityvel fejlesztett krossz-platform appok nem webes technologiat hasznalnak, es kulon fordul egy iOS meg egy Android kod. Kicsit mintha C++-ban irt programot forditanal le Linuxra meg Windowsra is.
-
válasz
Vision
#19895
üzenetére
Abszolut igazad van, hogy nem erthet mindenki mindenhez, en igazabol azt nem szeretem, amikor emberek eltologatjak maguktol a megtanulando dolgokat, mondvan h 'nem az en dolgom'. Tehat szerintem egy jo BA-t alapvetoen erdekli a technologia es valamennyire konyit is hozza, csak nem az a fo felelossegi kore, vagy mittudomen, egy jo banki programozo baromi jol ert a penzugyekhez, csak nem napi szinten folyik bele. Szoval amit irtam, az ugy igazabol nem fair (tehat vszeg nem igaz az, amit sugalltam), csak ezt az eros szegregaciot nem kedvelem.
Volt hasonlo temakorben egy jobb iras, https://www.fishmanafnewsletter.com/p/balancing-engineering-cultures-debate-vs-do
szoval az se jo, ha mindenkinek mindenhez ertenie kell, meg az se jo, ha mindenki csak azzal hajlando foglalkozni, ami a nagyon szuken vett hivatalos feladatkore.De te is biztos lattal mar csomo 22 evest, aki bejelenti az elete elso allasinterjujan, hogy 'en nem koder akarok lenni, hanem architekt'. Az _osszes_ ilyen esetrol az derult ki nekem, hogy igazabol oket nem erdekli a technologia, es bar programozonak jelentkeznek, a leheto leggyorsabban el akarnak huzni valami olyan munkakorbe, ami jol fizet, de nem kell kodot irni. Egyebkent ugye a menedzsmentre is igaz, hogy a legrosszabb menedzserek azokbol kerulnek ki, akik az elso pillanattol menedzserek akartak lenni (szerintem a jo menedzsment a 'szolgalo' menedzsment, azaz amikor a vezeto megcsinalja a szar munkat, hogy a csapata csinalhassa az erdekes munkat).
-
válasz
#79484416
#19891
üzenetére
> Előbbiek hidalják át a szakadékot szakterület (pénzügy/műszaki témák/stb.) és az IT közt, a tervezők leginkább az algoritmizálással, a nagyobb képpel dolgoznak és az ő outputjukból dolgoznak a programozók, akik mindezt kódsorra fordítják.
ezek a programozas kulonbozo reszei -- kicsit ahhoz tudnam hasonlitani, mint amikor valaki azt mondja, hogy o egy front-end programozo, ugye az valojaban azt jelenti, hogy nem ert a back-endhez
ennek mintajara, az ondefiniciok szerint:
- a 'business analyst' az, aki jol akar keresni IT-ben, de nem ert a programozashoz
- az 'architekt' az, aki regebben meg tudott programozni, de mara megunta vagy sose volt jo benne
- a 'koder' az, aki lusta ahhoz, h a programnyelveken kivuli dolgokat is megtanulja> Ebben a felállásban az üzleti problémák értelmezése a szervezők dolga (volt?).
ja, ebbol szulettek a 'gyonyoru' rendszerek
-
válasz
#79484416
#19885
üzenetére
Ugyanaz, mint ami idaig. Az automatizalt feladatokra toredekannyi ember is eleg lesz. Ezert nincsenek ma mar 'HTML fejlesztok', meg webshop-programozok (vagyis csak nagyon keves). A programozokat mindig is azert fizettek, hogy formalizalni tudjanak problemakat es a problemak megoldasat, ez a problemakor nem fog eltunni. Tehat ahogy mindig is, azok fognak gyoztesen kijonni a szitubol, akik nem abban jok, hogy megtanultak valamelyik nyelv szintaxisat, hanem abban, hogy melyen megertik a domain problemakat.
-
Nyilvan a lenyeg a kockazatelemzes. Ha gyakoriva valik a programozok tomeges lemeszarlasa, akkor biztos komolyabban fogjak venni a cegek. Viszont jobb modszer inkabb azt megoldani, hogy a dokumentacio tartalmazza a tudas jelentos reszet, a maradek resz pedig tobb ember fejeben is benne legyen, erre vannak modszerek, amiket szoktunk is alkalmazni.
> 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.
Azert ez termeszetesen nem igy van, ha tenyleg muszaj (== van ra penz), akkor akar obfuszkalt kodbol is vissza lehet fejteni dolgokat. Ha nehany szazezer dollarrol van szo, akkor nyilvan nem fogja megerni.
-
válasz
dabadab
#19736
üzenetére
A masik szerintem az, h a VPS-ek eseteben tipikusan van valami nagy/redundans/etc. szerver (vagy szerverek), ami adja a az eroforrasokat (cpu, ram, storage), es az van felmappelve a VM-ek ala. Ennelfogva egy 5 dollaros VM jellemzoen kevesbe szall el a fenebe, de egy 20 dollaros Hetzneres dedikalt vasnal siman elofordulhat, hogy elpukkan a tap, es elvesznek az adataid a geprol. Persze backup, etc., de egyszeruen az a tapasztalat, hogy a(z olcso) dedikalt szerverekre jobban kell figyelni, mint a VM-ekre.
Cserebe a dedikalt szerver sokkal olcsobb.
-
-
válasz
martonx
#19720
üzenetére
Az inga elkezdett visszafele lengeni egyebkent. Ennek tobb oka van:
- a felhasznalok (cegek, stb.) 99.99%-anak nincs szuksege on-demand skalazasra
- a k8s eleg jo absztrakcionak bizonyul, tehat az egyik alapproblemat, miszerint 'mi tortenik, ha ledoglik egy gep' konnyu megoldani
- a felho nagyon draga tud lenni, pluszban nagyon sok aremelkedes volt az utobbi idobenA felho nyilvan nagyon jo, ha
- meg kell felelni mindenfele standardnak (compliance)
- extra fontos a biztonsag
- nagyon magas a hozzaadott ertek a ceg reszerol, azaz az infrastruktura-koltsegek nem lenyegesekViszont az alkalmazasok egy nagyon-nagyon nagy resze boven megoldhato egy menedzselt k8s-el, queue-nak feldobsz egy NATS-et vagy akar PSQL listen/notify-t (ami megintcsak eleg majdnem mindenkinek), adatbazisnak PSQL, berakod az egeszet egy Cloudflare Zero Trust vagy Tailscale moge es kapasbol megvan az SSO az infrahoz.
Szoval egyre tobben fedezik ezt fel ujra, mert elert oda az eszkozkeszlet, hogy nem kell feltetlenul publikus felho.
-
#19399
emvy
félisten
VikMorroHun
#19394
válasz
VikMorroHun
#19394
üzenetére
ez napidij
-
-
> 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.
Ebben az esetben (is) szerintem a megoldas a CPU request; tehat mindenki annyit requestel, amennyi elegendo a szolgaltatashoz, a maradekot meg ugy hasznaljak a processzek, ahogy eppen 'kiadja'.
Aminek talan lenne ertelme, az valamifele scheduling priority (kb. mint a niceness), de ezeket azert nem egyszeru tenyleg hasznalhatoan megcsinalni. (Ahogy a k8s eseten is a nagyon alacsony (<500m) CPU limitek sokszor oda vezetnek, hogy a processz nem kap semmit.)
-
Ha a Kubernetes fejlesztese neked a 'konnyu resz', akkor holnap tudsz talalni magadnak 2000 euros napidijjal melot.
Valojaban pont stateless alkalmazast azert nem akkora dolog csinalni, mert az allapotot szepen ki lehet szervezni erre mar felkeszitett tarhelyekre.
De nyilvan tudni lehetett a posztnal, hogy csak trollkodni jossz megint
-
-
> Amit találtam róla, az eléggé marketing-elmaszatolt információ.
Hat, pedig a Kubernetes az egyik legjobban dokumentalt technologia jelenleg.
> Vertikális skálázás.
A Kubernetes alapvetoen container orchestrator, vertikalis skalazasra nem igazan valo.
> Azt mondja az elmélet, hogy röptében még node-okat kér az alkalmazás a szolgáltatótól. Tuti, azt megkaphatja. Nem mintha röptében telepíteni egy OS-t, be-config-olni, üzembe állítani két pillanat lenne, de pár perc alatt meg tudhat éppen történni.
Kb. 1 perc GKE-n.> Sőt, mondjuk az esetek 99%-a nem olyan. Vagy megfeledkeztem volna valamiről?
Webes kornyezetben a szoftverek eseteben a nagyresze ilyen.
> Ha esetleg létezik olyan leírás, ami a technikai részleteket tényleg leírja, és nem csak a levegőbe beszél közhelyeket, örülnék olvasnivalónak.
Kezdd itt.
https://kubernetes.io/docs/concepts/architecture/
-
-
#19125
emvy
félisten
VikMorroHun
#19124
válasz
VikMorroHun
#19124
üzenetére
A Qt nem nyelv. A Java miért áll C++ alapokon? A C# miért?
szoval rajtad áll a bízonyitas kényszere
-
-
válasz
stellaz
#19044
üzenetére
Nem ismerjuk a gyerekedet, ezert nehez megmondani. Szerintem 9 evesen meg boven abban a korban van a gyerek, ahol minel tobb dolgot erdemes kiprobalnia, es ha epp most nincs kedve programozni, akkor nem kell eroltetni, ettol nem lesz okosabb. Ha helyette focizik vagy olvas vagy tarsasjatekozik vagy fara maszik, akkor semmivel nincs hatrebb (sot).
-
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Bomba ár! Lenovo ThinkPad E550 - i5-5GEN I 8GB I 256SSD I DVDRW I 15,6" HD I CAM I W10 I Garancia
- Csere-Beszámítás! Intel Core I9 14900KS 24Mag-32Szál processzor!
- LG 27GR95UM - 27" MiniLED - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 1000
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Intel Core i9 9900KF 8 mag 16 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest