- Amazon Kindle
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen alaplapot vegyek?
- Bambu Lab 3D nyomtatók
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- HiFi műszaki szemmel - sztereó hangrendszerek
- Házimozi belépő szinten
- SSD kibeszélő
- TCL LCD és LED TV-k
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
-
PROHARDVER!
Új hozzászólás Aktív témák
-
dqdb
nagyúr
A WSL kényelmesebb, és bőven elegendő, ha nincsen szükséged hardveres dolgokra. VSCode + remote development, vagy ha multiplatform dologról van szó és CMake alapú a build folyamat, akkor annak VS-ben eléggé jó a támogatása.
A WSLg jóvoltából már nem vagy konzolra sem korlátozva.
-
A WSL2 az egy full Linux VM. Semennyire nincs a Windows alatt - ha be van kapcsolva, onnantól a Windows és a Linux párhuzamosan fut (a Windows is virtualizált). Meg van oldva, hogy Windows alól lehessen menedzselni, de nem azalatt fut.
Tehát nincs teljesítményveszteség, stb.
-
-
cucka
addikt
De, pont ezért van, leleplezted a nagy IT-ipar összeesküvést!
Viccet félretéve - a devops és az üzemeltetés az ugyanaz.
Csak régen az üzemeltető az volt, aki a hóna alatt becipelte a szervert a szerverterembe. Most meg ugyanez az ember ír egy python scriptet amivel a cloud-ban szervert hoz létre, voilá, devops. -
dabadab
titán
Érdemes nem random helyekről összeszedett random adatokat egymással összehasonlítani, mert annak ez a vége.
A videó ezeket az adatokat használja és ott az Oracle továbbra is első. -
kozeposztaly
csendes tag
Jól tudom, hogy 2023ban 27.8M Ft éves bevételig választható? Magyarul havi 2.3M adózás előtti bevételig, amiből ha jól néztem 1.7M nettó marad kb. (ha nem ennyi, javítsatok ki)
Ergo egyéni vállalkozó + átalányadózás havi nettó bevételem max 1.7M lehet.
Efölött milyen lehetőségek vannak? Akkor már kikerülök az átalányadózásból? -
Marky18
aktív tag
Lehet binarisan tarolni, de a nyers adatra mindenkeppen szukseg van, a termek indulasatol kezdve egeszen a mostani idopontig. Onnantol kezdve a mernokok feladata, hogy mit kezdenek ezzel a nyers adattomeggel, milyen formaban transzformaljak es taroljak. Altalaban a raw reteg utan mar valamilyen DB vagy data lake kovetkezik....
Nalunk peldaul 4 lepcso van a raw es a konkret user reteg kozott , az adat bonyolultsagatol es a kovetelmenyektol fuggoen mindet ki is hasznaljuk. -
-
dabadab
titán
És azóta sincsen lila halvány gőzöm sem, hogy leszámítva valami munkahelyi szabályzatot (amire egyszer láttam példát), vagy elpancserolt design-t (amire jó sok példát láttam), ugyan mi értelme write-heavy load-ot adatbázisba küldeni mezei bináris állomány helyett?
Hogy lehessen majd rajta lekérdezéseket csinálni. Ugyanis - többek között - erre jó az adatbáziskezelő.
Szívesen. -
Amikre ráláttam nagy rendszerek (telco, finance, retail), ott szó sem lehetett arról, hogy ne tároljanak le nyers adatokat. Egyrészt azért, mert az adat a legnagyobb kincs (ez már sok-sok éve ki lett mondva mindenhol), másrészt az aggregáció logikája nem stabil soha, ezért sosem szabad a legalsó szintre rakni. A big data módszerek terjedésével ez hatványozottan igaz.
Nincs 100%-os rendelkezésre állás, soha senki sem állította ezt magáról. A tizedesvessző utáni 9-esek számán szokott megmutatkozni a minőség, és persze az ár is.
-
> Google, Facebook, Messenger, Amazon, AliExpress, DealeXtreme és társaik látszólag nem 99-95-öt, meg nem 99.99-et használnak, hanem 100.0-t.
Ez konkrétan nem igaz. Legutoljára 2022 augusztus 8-án volt offline a kereső globálisan percekre. A Google fő szolgáltatásai olyan 99.999% körül mozognak. A felhős régiók (tehát pl. Nyugat-Európa) 99.98% körül.
> . Ahol szenzor adatokat tárolnak, normális design gyárt belőle sorfolytonos adat stream-et valami helyi flash-en, amit távoli állomás időszakosan átolvas, feldolgoz, mindenféle statisztikát gyárt belőle, és már csak a kész statisztikát tolja fel adatbázisba
Sok területen ez konkrétan tilos, minden egyes mérési eredménynek meg kell lennie. (Pénzügyi tranzakciók, egészségügyi adatok, stb.).
-
Drizzt
nagyúr
"Vagy inkább csak a pancser fejlesztőik. Ahol szenzor adatokat tárolnak, normális design gyárt belőle sorfolytonos adat stream-et valami helyi flash-en, amit távoli állomás időszakosan átolvas, feldolgoz, mindenféle statisztikát gyárt belőle, és már csak a kész statisztikát tolja fel adatbázisba. Az a statisztika egyszer kap felírást, és életciklusa során vagy milliószor olvasást."
Ertem. Egy dolgot mondj akkor meg legyszives! Mit csinalsz abban az esetben, ha kiderul, hogy a statisztika gyarto fuggvenyben van egy bug, ami miatt a fel evvel ezelotti osszes adatot ujra kellene szamolni? A helyi flash meg mar azota 15-szor ujra lett irva uj adatokkal. Honnan lesz meg az adat, amibol kiszamoltad a rossz statisztikat, hogy ujraszamold helyesen?
De mondjunk egy meg egyszerubb forgatokonyvet: kellene uj statisztika az eszkozok altal begyujtheto adatbol, 5 evre visszamenoleg. Mostantol, eddig nem kellett. Viszont ugyanazokbol az adatokbol, amiket eddig is gyujtott az eszkoz.
Mit csinalsz? Tegyuk fel, hogy az adatok nagy frekvenciaval keletkeznek, a flash merete meg korlatos, mondjuk 1-2 napi adat fer el rajta maximum.[Nagyobb google kiesesek]
[Facebook: ez nem volt olyan regen, gyarkolatilag napokig hasznalhatatlan volt a felhasznalok tobbsegenek(bar hivatalosan 6 ora utan helyre lett allitva)] -
> A "nem szükséges" állítása egy kicsit savanyú a szőlő esetére hajazik.
Nem egeszen, csak en tudom, h miert nem 0% a downtime budget, vagy miert nem csinaluk 99.99999%-ot, akkor se, ha tudnank, ha 99.999% elegendo.
> Ha konkrét technikai kifogásod van, légyszíves fogalmazz konkrétan, milyen esetben látod elkerülhetetlennek a down time-ot?
- terroristatamadas az osszes adatkozpontban egyszerre
- haboru
- globalis BGP konfiguracios problema
.. stb.Ezek mind csokkentik a varhato rendelkezesre allast.
Azert nem szukseges pl. a 99.999999999% egy banki rendszer eseten, mert a koltsegeit nem hajlandok megfizetni az ugyfelek. Tehat ha a bankolas 10 forintba kerul tranzakcionkent, cserebe evente van 1 ora downtime, az az ugyfelek nagy reszenek jobban megeri, mint evi 1 perc downtime es 1000 forintos tranzakcios koltseg.
> hogy ők azt is meg tudják csinálni, mindjárt megváltozik a szükséges-e vagy sem minősítése
Csak epp senki nem marketingel 100%-al, akik komolyan veszi magat. A legnagyobb cloud szolgaltatok jellemzoen 99.95%-ot vallalnak datacenterenkent, 99.99% korul tobbregios elosztott rendszerekre.
De tudom, most jon az, hogy a Google-nel amatorok dolgoznak
-
cucka
addikt
De most mi a kérdésed?
Hogy lehet-e más dolgokra használni a blockchaint, amire kitalálták?
Lehet, igen. Mosogatószivaccsal is ki lehet festeni a szobát.Vagy az a kérdésed, hogy miért nem tértek át erre a bankok?
Ugyanazért, amiért a szobafestők sem cserélik le a festékhengert mosogatószivacsra. -
> A technológia röviden összefoglalva egy csak olvasható dokumentum halmaz minden node-on minden adat megvan jelleggel.
> Sok node-on az adat felírás annyival lassabb, mert minden node-ra fel kell írni minden adatot, de cserébe az adat visszaolvasás több ügyfélre elosztva tud lenni ugyan annyival gyorsabb, mert el lehet osztani az ügyfeleket a node-ok között (H/P).Nem, total nem errol van szo. Amit leirsz, az mukodne egy normal multi-master adatbazissal is.
A blokklanc lenyege az, hogy akarhanyan beallhatnak szavazni arrol, hogy elfogadjak-e az update-eket, es ha a fele resztvevo elfogadja, akkor az valid (ez valamennyire egyszerusites). Ennyi. Egy klasszikus multi-master adatbazis eseten nem dobhatod be a te sajat geped, hogy lecci hadd legyen ez is resze a clusternek, es ha a cluster eddig 5 gepbol allt, te pedig bedobsz 6-ot, akkor onnantol te mondod meg, hogy mi a megfelelo update.
-
A hitelesség biztosításához - a technológiából adódóan - nagyságrendekkel több erőforrást éget el, mint egy centralizált rendszer. Valódi előnye pedig nincsen. Nem véletlen, hogy a nagy blockchain láz idején is a csillogó szemű hívőknek semmilyen konkrét érvük nem volt mellette, csak az olyan abszurditások, minthogy: vége az eddig létező pénzrendszernek, kormányok fognak megdőlni, és társai.
-
cucka
addikt
Valóban nem ugyanarról beszélünk. Amiről te írsz, az egy elosztott rendszer.
A blockchain első számú fícsöre és problémaforrása, hogy decentralizált.Banki ledger-ek legalább 800 éve léteznek. A lényege, hogy minden érintett fél megbízik a bankban, hogy a tranzakciókat helyesen kezeli, megérkezik az utalás, nem tűnik el a pénz a számláról. A banknak pedig elemi érdeke, hogy ezt a bizalmat fenntartsa.
A blockchain arra a problémára ad megoldást, hogy hogyan tudnánk pénzügyi tranzakciókat elvégezni és validálni abban az esetben, ha nem léteznének megbízhatóan működő banki ledger-ek. Csak hát ugye léteznek, úgy legalább 800 éve.
-
dabadab
titán
A blockchain jelenleg fejletlen. Még nem olcsón és stabilan férhető hozzá általánosan a szakmai világ egészében
Ezeket a hülyeségeket egyébként honnan szeded?
Amikor pár éve berobbant a BTC árfolyama, akkor minden nagy cégnél vért izzadt egy csomó ember, hogy bármi épkézláb felhasználást találjon a blockchainnek.
Nem sikerült, mert bármi jutott eszükbe a blockchain felhasználására, pillanatok alatt rájöttek, hogy arra már van sokkal jobb megoldás. És nem azért, mert a blockchain "nem olcsón és stabilan férhető hozzá", hanem azért, mert vannak inherens problémái, amik tényleg problémák, cserébe meg olyan dolgokat old meg, amik nem problémák. -
dabadab
titán
Alapvetően a blockchain megoldás, ami problémát keres
Nagyjából egyedül a kriptópénzekre jó, bármi másra vannak sokkal jobb megoldások (és persze a "blockchain" kifejezés kellőképpen rugalmas, az Oracle által használt cucc az tényleg csak annyi, hogy hasheli az előző blokkot, semmi distributed ledger meg hasonlók, amivel a blockchaint általában társítani szokták).
-
mindthecrap
aktív tag
Persze semmiképpen sem konkrét példákkal gondoltam, én is olyan területen dolgozom, hogy egy meggondolatlan csatolmány vagy forward is az állásomba kerülhet. Csak jó lenne kicsit képbe kerülni mert egyelőre kizárólag végletekkel találkoztam (VIM-ben programozó sigma arcok akik ebédszünetben kifinganak egy komplex rakétavezérlő szoftvert vs. "annyi a heti munkám hogy átszínezek egy CTA gombot" arcok).
-
-
Ispy
nagyúr
Ne viccelj már, a cégek rengeteg mindent bevállalnak, folyamatosan, aminek a jó része kuka is lesz pár év alatt (startup? Opensource kódtenger?). Kicsiben, közepesben, meg nagyban. És de, bütykölős fajta vagyok, ezért tudom, hogy az embernek menyire limitált a kapcítása szabad idejében. Szóval nem, továbbra sem a hobbisták viszik előre ezt a szakmát, hanem a cégek, akik pénzt áldoznak a fejlesztésre, és a cégek, akik ezért fizetnek. A hobbistákat max felszippantja a rendszer.
-
dqdb
nagyúr
A .NET Framework SDK sem része a rendszernek, a .NET Framework runtime igen, mert rendszerkomponensek épülnek rá.
A .NET a Windowstól függetlenül fejlődik, teljesen más kiadási gyakorisággal, értelmetlen lenne beletenni a telepítőbe a runtime-ot. A Microsoftnál inkább az ellenkezője figyelhető meg mostanában, nem betesznek, hanem kivesznek olyan komponenseket, amelyeknek alapvetően eltér a kiadási ciklusa a Windowsétól (gyorsabb), és külön telepíthetővé teszik ezeket, a WSL most kerül majd ki és lesz Microsoft Store-ból telepíthető.
-
Ispy
nagyúr
A hobbiprogramozók nem építenek semmit cégekben, mert akkor az már nem hobbiprogramozás. Ha Jóskabácsi szeret otthon bütykölni, az nem fogja fellendíteni az asztalos szakmát...hobbiból meg nem lehet komoly dolgokat készíteni, mert ahhoz kevés heti 4-5 óra, hogy el is készüljön.
-
martonx
veterán
Kevered az sdk-t a runtime-al. A megcélzott OS-nek megfelelő runtime-ot könnyen hozzá tudod csomagolni az apphoz (de nem kötelező, te döntesz). Szegény win így is tele van minden szarral, miközben mindenki mást és mást hiányol belőle (én pl. Total Commander szerű file kezelőt). Szóval szerintem nem baj az, hogy nincs winen alapból minden szar, majd felteszi mindenki a saját szarjait. MS kivételesen pont jól csinálta, hogy az új dotnet alapból nem a rendszer része. Pláne, hogy a cross platformság miatt egyébként is arra kell készülni, hogy az OS-en nincs elő telepítve dotnet. Ennyike.
-
martonx
veterán
-
Ispy
nagyúr
Kis cégeknél sem kell promptra úszni, nálunk 6, de inkább 12 hónap, amire olyan feladatot kapsz, ahol nagyobb a falat. Addig meg felügyelet mellett csinálod a projektek, kisebb, majd egyre nagyobb falatjait.
De a cél az, hogy rád lehessen bízni nagyobb munkát is, nem az, hogy örökre junior pista maradjál, az senkinek sem éri meg.
-
A PACELC nem kritika, hanem kiegészítés, valójában még jobban leszűkíti a CAP-et.
> Ami vélemények eddig érkeztek, mindegyik tool, amelyik a problémát egyáltalán kezelheti bármilyen szinten, Raft / Paxos alapú. Azt kijelenteni vajon korrekt?
Mi a kérdés? Hogy van-e más a Paxos/Raft pároson túl elosztott konszenzusra? Persze, nyilván van. Vagy nem értem, hogy mit kérdezel.
-
Marky18
aktív tag
Frontendre elobb talal juniort egy ceg, mert egyetemen, bootcampeken, youtuben es udemyn is erre tudjak a legkonnyebben felkesziteni a kezdoket.
Beagyazott, backend/middleware fejleszto, cloud engineer vagy data engineer pozicioba magasabb a belepesi kuszob es nem is lehet akarhol beletanulni, mert van eszkoz/adat/infra kovetelmeny a tanulashoz. -
KubanitoS
veterán
Semmi sem egyszerű, ebben igazad van, de ahogy látom az a legnehezebb, hogy felkerüljön az ember arra a bizonyos hajóra. Ha ez megtörténik utána már csak a lehetőséget kell megragadni és élni vele.
Drizzt köszönöm neked is! Pont az a probléma, hogy nem tudom mire mehet az ember azzal, hogyha csak az ingyenes cuccokat nyomja. Nincs kontroll, nem tudod valójában milyen szinten vagy… -
K1nG HuNp
őstag
te továbbra is azt hiszed, hogy csak mert te megáltál egy értelmi szinten akkor az egész világnak meg kell ott állnia. segitek, nem
és tényleg nem értem, hogy jössz ahhoz, hogy mások kutatását, munkáját becsméreld. tegyél le valami negyed ennyire jót az asztalra és utána esetleg pofázhatsz.
meg akkor ezek után reméled a fenti hozzállásod alapján fogsz cselekedni és a mentőssel ordibálva fogod közölni, hogy téged márpedig nem vihet be a semmelweis klinikára hanem keresse meg a leglepukkantabb szoci SZTK-t ahol még véletlenül sincs semmilyen machine learninges orvosi döntéstámogató rendszer, hiszen az mennyire szar.
ja.. vagy amikor már az életed menti meg 1-1 okosabb csapat eü mérnök munkája akkor már királyak? -
K1nG HuNp
őstag
ezt most ugy irtad mintha te elertel volna valamit
nemtudom miert gondoljak emberek hogy a vallalkozashoz nem kell iskolazottsag, oke hogy ha nagy ceo manager genyo leszel akkor relative keveset fogsz turkalni low level codeban, de az igazan jok kepesek lennenek ra, csak epp massal toltik az idejuk nagy reszet (kenyszerbol).
meg manapsag aztan mivel telitett a piac a tudasoddal tudod igazan jol diverzifikalni magad az osszes tobbi fos kodot tolo garazs webfejleszto brigadtol
-
-
cucka
addikt
Az, hogy az elosztott rendszerek fejlesztése nehéz, az az én saját személyes tapasztalatom.
Amúgy bármikor tehetsz te is egy próbát, és nekiállhatsz lefejleszteni egy hibatűrő elosztott rendszert, és ezután neked is lesz tapasztalatod arról, hogy mennyire könnyű vagy nehéz ez a témakör.
-
Ispy
nagyúr
De olyan motiváció vagy van, vagy nincs
Motiváció nélkül ezt szerintem nem lehet, ahhoz meg kell valami téma, az hogy most elmegy egy random iskolába vagy random tanfolyamra elsőre nekem kidobott pénz az ablakon. Ha már tudja mit akar és úgy megy el, az már más. De motiváció legyen már, aki nem motivált, az mégis hogyan fogja ezt minden nap csinálni?
-
cucka
addikt
Ilyen feladatokra az iparágban key value store-t szoktunk használni. Cloud-ban a natív megoldásokat érdemes használni, saját üzemeltetésben a legtöbbször redis-t láttam. De léteznek distributed actor megoldások is, amivel megvalósítható.
És nem, nincs egymillió megoldás erre, mert ilyen elosztott rendszerek lefejlesztése kurva nehéz feladat.
-
cucka
addikt
Az a fő probléma, hogy az elosztott rendszerek egy nagyon nehéz témakör, a te ismereteid pedig nem elegendőek ahhoz, hogy ezt felismerd.
Ha pozitív akarok lenni - ez egy remek alkalom a fejlődésre, itt egy témakör, amihez egyáltalán nem értesz, viszont érdekes, izgalmas, és megéri elmélyedni benne.
Ha negatív akarok lenni - a magabiztosan előadott gondolataid olvasása közben óhatatlanul a Benny Hill zenéje szól a fejemben.
-
Szerintem 2 honapot siman meger, mert CAP-bol mindharmat egyszerre semmi* nem tud jelenleg, szoval pillanatok alatt dollartizmilliardos lennel, de akar egy Turing-dij is befigyelhet.
*Google Cloud Spanner 'majdnem CAP', merthat egy rakas szinkronizalt atomoraval lehet vicces dolgokat csinalni
-
K1nG HuNp
őstag
kicsit mintha mindent is akarnál egyszerre, CAP theorem olvasása szerintem jó dolog lehet, illetve ez pont egy olyan problémakör amelyet nálunk sokkal okosabb emberek évek alatt már a lehető legjobban megoldottak és csak le kell venned egy kulcsrakész megoldást a polcról.
-
Lortech
addikt
Korábban nem igazán írtad le, hogy mit szeretnél, kb: szemafor, elosztott, hibatűrő legyen.
Ehhez képest ebben a témakörben nüansznyi részleteken lehetne oldalakon át vitatkozni.
Mit szeretnél, elosztott szemafort vagy elosztott adatbázist (ami lehetőleg legyen CAP és gyors is) ?
Bevált megoldások annyira, hogy használják őket olyan problémák megoldására, amikre ki lettek találva. Ha a te problémád nincs ezek között, az nem az eszköz hibája.
A már felsoroltak között kellene legyen megfelelő eszköz számodra is, pl. Hazelcast CP alrendszere (RAFT alapú), vagy pedig nem létezik, amit szeretnél.
De mindegy is, mert nincs kedvem itt ködöt szurkálni. -
Lortech
addikt
A redis belül single theaded, kivéve IO, de a probléma szempontjából teljesen mindegy, hogy belül milyen a kiszolgálási modellje valaminek, nyilván nem thread-per-request redis esetében. Ne tévesszen meg, hogy van embedded változata is, legtöbben nem így hasnálják, én se. Emvy a problémára teljesen adekvát, bevált megoldásokat írt elosztott rendszerekre, sokprocesszes környezetre. Én hazelcastet, redist és zookeepert használtam hasonlóra, de rdbms alapon is implementáltam már szemafort lockokkal, de az költséges.
-
Na jó, akkor szólok az elosztott Redis clusterünknek, hogy a Prohardveren mondták, hogy ilyen nem is létezik :) (konkrétan használunk ilyen célra Redist, mármint elosztott szinkronizációs primitívekre).
Mindegy, valami fura dolog van nálad :)
("A redis csak egy szálon fut." - egyszerűen nem értem, honnan veszel ilyesmiket.)
-
Olvasgass erről még egy kicsit, szerintem félreérted elég rendesen. A Raft és a Paxos elosztott konszenzust oldanak meg. Az elosztott adatstruktúrák használatához kell valamiféle konszenzus-implementáció.
És nincs adatvesztés master elvesztése esetében, természetesen.A Redis faék egyszerűségű a kliens szemszögéből, nem tudom, h mi tűnik benne bonyolultnak.
-
Drizzt
nagyúr
SSE: Server sent events. Gyakorlatilag a böngésző indít egy kapcsolatot a szerverrel, amin keresztül aztán a szerver tud kezdeményezni küldést. Tehát alapvetően éppen bejelentkezett embernek üzenet küldésére szolgál.
Pl. elkezdesz megnyitni egy számlát. Kapsz egy azonnali visszajelzést, hogy oké, elkedztük a számlád megnyitását. De a számla megnyitása bonyolult folyamat, ami mondjuk két perc átlagban. Ilyenkor SSE-vel tudsz üzenetet küldeni az embernek, ha még éppen online van, hogy hahó, el is készült a számlád.
A másikról nem jól érted. Az a lényeg, hogy szeretnék 100e csatornát. Az egyes csatornákban elég kevés üzenet lenne, gyakran semmi. Ha valaki akar küldeni üzenetet, akkor az tudja a csatorna nevét, oda elküldi az üzenetet. Ha meg valaki olvasni akar üzenetet, akkor a csatorna nevét ismerve feliratkozik. Amikor valaki küld a csatornára üzenetet, akkor a feliratkozó kap értesítést. Feliratkozni a szerver iratkozna fel, amikor egy böngészőn keresztül a user SSE kapcsolatot épít ki nála. Ha kap értesítést a csatornáról, akkor az üzenetet tovább küldené SSE-n. -
-
Ispy
nagyúr
-
dabadab
titán
-
pmonitor
aktív tag
Ha a hegy nem megy...
Az is megoldás lehet, hogy ha az angol netes dokumentációkat sikeresen és zökkenésmentesen le lehetne fordítani más nyelvekre. De a weboldalak nyelvekre való lefordítása is még gyerekcipőben jár. Pedig csak ezzel az egy dologgal nagyon nagy része megoldódna a problémának. De ehhez egy jó webes fordítót kellene alkotni(pl. ami a példakódokat nem fordítja le, csak a magyarázó tartalmat). Viszont úgy látszik, hogy egyelőre ez túl nagy feladat a programozóknak. Nemrég írtam, hogy a google translate 1 nagy nulla. Ilyennel még a magyarázó tartalmat sem lehet értelmesen lefordítani. Vmi. normális kellene...
-
Ispy
nagyúr
-
pmonitor
aktív tag
>Minden dokumentáció, ami mérvadó, csak angolul érhető el.
És ez kinek a hibája? Sztem. a magyar szakiké, mert nem képesek mérvadó dokumentációt alkotni, de még fordítani sem...Nem azt állítom, hogy nem szükséges az angol tudás, de ez a magyar szakik hibája, nem az angoloké/amerikaiaké. Az a helyzet, hogy a magyar szakik lusták/dokumentum írásra képtelenek. Végül is mind1, hogy melyik. A lényeg, hogy nem az angolokon múlik, hogy nincs mérvadó magyar dokumentáció.
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Debrecen és környéke adok-veszek-beszélgetek
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Napelem
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Amazon Kindle
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- EA Sports WRC '23
- Samsung Galaxy S23 Ultra - non plus ultra
- További aktív témák...
- HP Spectre x360 Érintős Hajtogatós Laptop Tab 16" -60% i7-1360P 32/2TB Intel Arc A370M 4GB UHD OLED
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -60% i5-1135G7 4Mag 16GB /512GB FHD IPS
- Samsung Q80T 55" QLED - 4K 120Hz VRR / FreeSync / HDMI 2.1
- ÚJ HP ENVY 17 Nagyképernyős "Kis Gamer" Laptop -45% 17,3" Brutál i7-13700H 16/1TB Iris Xe FHD IPS
- Legion Go 8APU1
- Gigabyte BRIX GB-BXi3H-4010 mini PC eladó
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- Realme C30 32GB, Kártyafüggetlen 1Év Garanciával
- Bomba ár! Dell Latitude E7250 - i5-5GEN I 8GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- Telefon felvásárlás!! Samsung Galaxy A13/Samsung Galaxy A33/Samsung Galaxy A53
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest