- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Melyik tápegységet vegyem?
- Kiszáll az optikai meghajtók piacáról a Pioneer
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- NVIDIA GeForce RTX 5060 Ti (GB206)
- Házimozi belépő szinten
- NVIDIA® driverek topikja
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Vezeték nélküli fülhallgatók
- Házimozi haladó szinten
-
PROHARDVER!
Új hozzászólás Aktív témák
-
dabadab
titán
válasz
K1nG HuNp
#17849
üzenetére
Én ezt úgy csináltam, hogy egyszerűen beadtam a CV-met egy rakat osztrák céghez, aztán kimentem állásinterjúkra. Mostanában nyilván már az utóbbit le lehet zavarni online is.
Nyilván ez innen a határ mellől elég könnyen megy meg nem kellett a lakás miatt problémáznom, mert simán ingáztam, de ha távolabbra mennék, akkor is így csinálnám.
Ha van relocation, az jó, de anélkül is meg lehet oldani. -
K1nG HuNp
őstag
BME MSc elvégzése után nekem egészen benne van a pakliban, hogy külföldön vállalok munkát. Aki csinált már ilyet hol kezdte? Nézzek egy magyar céget amelynek van külföldön is irodája és cégen belül próbáljak meg kijutni? Vagy relocationnel hírdetett pozikra adjam be és hátha összejön? Budapestről, remote végzett meló is igazából szóba jöhet a zsírosabb fizuért de őszintén csak ki akarok takarodni pár évre végre saját bőrömön átélni mindazt amit a hanyatló nyugat nyujthat és majd meglátni, hogy vissza akarok-e még jönni.
Tudom, hogy ez annyira nem prog téma de ti vagytok a legközelebb a kérdése témájához. Köszi előre is. -
#17847
pmonitor
aktív tag
Fire/SOUL/CD
#17843
pmonitor
aktív tag
válasz
Fire/SOUL/CD
#17843
üzenetére
Én nem vagyok programozó, így ezt nem valószínű, hogy meg tudnám oldani.
Nem véletlenül írtam ittenke:
>Azt hiszem, hogy régebben már írtam, hogy ha most kezdenék programozni desktop-ra, akkor az ASM, C, C++ nyelvekre állnék rá nagyon.De ha nem értetted meg, akkor szívesen lefordítom.
Nekem ilyen tapasztalataim vannak, ha nem a webprogramozást nézzük: Kevés ASM, C++, Pascal, közepes Vb6/Vba, C, viszonylag sok Vb.net, C#.
Ez helyett, ha most kezdenék, akkor sztem. ez lenne az ideális: Nagyon sok ASM és C, erősen közepes C++.Ez tehát azt jelenti, hogy sajnos nem tudok annyira ASm-ul, C-ül.C++-ul főleg nem. De ha neked nagyon megy, akkor példakódnak elfogadnám. Sőt, azt hiszem, hogy más nevében is írhatom, hogy elfogadnánk. Tudomásom szerint ASM topic meg nincs is(vagy ha van is, akkor sem aktív).
Egyébként C-t azért közepesen használtam, mert Vb.net/C# -ban van amit vagy nem lehet megoldani, vagy meg lehet ugyan, de nagyon lassú. Ezért muszáj volt néhány esetben C-ben natív .dll-t írnom. De ezért is bántam meg, hogy nem sok C-vel kezdtem. Ugyanis így megtanultam a C#-ot, viszont a C-re is szükségem volt. De akkor minek tanultam ilyen szinten C#-ot, ha nem tudom/tudtam a C-t kikerülni. Miért nem foglalkoztam majdnemhogy kizárólag C-vel.
De egyetértek azzal, amit ittenke írtál:
>Segítség:: Ezt csak ASM-ban, vagy C/C++ lehet megvalósítaniPontosan ezért bántam meg, hogy nem ezekre álltam rá...
-
#17846
axioma
veterán
Fire/SOUL/CD
#17844
axioma
veterán
válasz
Fire/SOUL/CD
#17844
üzenetére
Egyreszt nekem nincs phd-m.
Masreszt nem ertem a fogalmakat amit hasznalsz, pedig lehet hogy jo a problema.
Primek: en me'g elso egyetemista eveim egyikeben irtam egy primek (lancolt(!)) listajaval, es tovabb nem cipelt maradekokkal dolgozo megoldast pascalban egy egyesuleti otletelgetesre (mondhatnam verseny de abbol nagyon kilogtam, ott valoban asm-mel tolta'k profik). ramdisk-en futtattak, es nekem az mar eleg volt hogy volt nalam lassabb program Talan 1M-ig kellettek a primek, es az asm szita nyert, de a futasi ido nagy resze a kiiras miatti konverziora ment el.
Itt most a max. 64 bites uint-ek erdekelnek gondolom, mert a zarojelben meg a 2^64-1 darab prim ertheto ki.
Nagy szamoknal sztem wikipedia, Miller-Rabin, es az alabbi (masok altal mar kiszamolt) feltetel: if n < 18,446,744,073,709,551,616 = 2^64, it is enough to test a = 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, and 37.
Mondjuk lehet elvi szinten jobb nagyordos algo, de nem csak a szita nem fer el hanem barmi "csak" korabbi primeket ta'rolo megoldas, igy ez lenne az elso otletem (pontosabban a masodik, az elso hogy megkeresek egy letezo algot vagy programot ... ). Mondjuk persze ez is csak elmeleti, mert 8 byte per prim, azok lesznek vagy 10^15 darab korul igy exhas meg wolframalpha, 8ezer terrabyte jol saccolok? Ha adod a disk-et amire mentsem, irom a programot -
#17845
Fire/SOUL/CD
félisten
axioma
#17841
válasz
axioma
#17841
üzenetére
Nem itt, de szoktál ilyen feladványokat linkelni/adni....
Mondok "egyet"...
0 to 2^64-1 - ig írjuk ki az összes PRÍMET egy fájlba, 64 bites formátumba
Mindegy milyen nyelven (programozási nyelven), a lényeg hogy legyen a leggyorsabb...
Mivel sok lesz, legyen fájlba mentve (MÉGEGYSZER MONDOM 2^64-1 PRÍM)![;]](//cdn.rios.hu/dl/s/v1.gif)
Sok lesz bammeg(1 nap min.)...
(Na majd most megmutasszuk az ASM erejét (max 2 óra)... 
-
#17844
Fire/SOUL/CD
félisten
axioma
#17841
válasz
axioma
#17841
üzenetére
Neked meg (me' tisztelek és szvsz matekot imádod és vágod, akko'), hogy lehet a 5. prímet meghatározni az ELSŐDLEGES (és egyetlen) halmazban (véletlen számosságú halmazban)
Ha ezt megoldod, akkor nem lenne PHD-M 15 ÉVE...UI (PS)
Robogunk hazafelé, Somogyba... Hákunámátátá...
-
#17843
Fire/SOUL/CD
félisten
pmonitor
#17834
-
pmonitor
aktív tag
válasz
sztanozs
#17832
üzenetére
> biztos tudsz nyitni egy "C/CPP optimalizálás sebességre" topikot
Nem ilyen topic-ot hoztam létre, hanem A WIN API haszálata címűt. Örömmel várok oda kritikákat/kiegészítéseket. És persze az sem lenne baj, ha vki. szaki is írna példakódo(ka)t, mert azért én mégiscsak hobbiból kódolok/programozom.
-
pmonitor
aktív tag
válasz
axioma
#17838
üzenetére
Utolsó hsz-ek egyes témakörökben:
C# programozás: 2022-10-01
C++ programozás: 2022-09-25
C programozás: 2022-09-03Komoly forgalom megy más topic-okban...
-
pmonitor
aktív tag
válasz
K1nG HuNp
#17836
üzenetére
>azota nem olvasom ezt a topicot miota letezel
Azóta lehetsz boldog ember, amióta nem olvasod. Amíg olvastad, addig elég boldogtalan lehettél...
>mindig rajtad megy a frocsoges
Hát igen. Jobb lenne, ha a programozók nem velem foglalkoznának, hanem mondjuk minta/példa kódot adnának/tennének közzé. Mert ugye a programozás kimenete kétféle lehet: az elkészült bináris file(.dll, .exe), vagy forráskód(script nyelvek esetén nyilván csak ez utóbbi). De ehelyett csak rizsa megy. Ahhoz meg nem kell programozónak lenni. Rizsázni még én is tudok. De amikor pl. azt a kódot kellene optimalizálni, mint amit betettem ide, akkor meg csak nézegetnek. Mondjuk azért így is lehet tanulni némelyikből. Pl. dqdb hozzászólásából is. Még akkor is, ha csak kötekedés volt a célja(nekem teljesen mind1, hogy milyen okból ír valaki, csak hasznosat írjon). Amiket martonx írt, azok is hasznosak voltak(bár ha odafigyeltem volna, akkor ezek nekem kapásból mentek volna, de hagyjuk meg neki az örömöt). Aztán Fire/SOUL/CD hozzászólásából is lehet tanulni(mivel problémamegoldó gondolkodást tükröző hozzászólás volt). Szóval sztem. ehhez hasonlóknak kellene lennie a hsz-eknek/diskurzusoknak. Mert amikor arról megy a vita, hogy mindenképp ragaszkodni kell-e a "prof" által mondottakhoz, vagy a "nagykönyvben" leírtakhoz, vagy pedig a gyorsaság érdekében áthághatunk-e 1(esetleg több) ilyen szabályt, az sztem. jó vita. De amikor olyant ír vki., hogy 1 programozónak nem muszáj produktumot adni - na akkor tudnám lekaparni a falat(persze idézőjelesen - mert természetesen ettől még tudok aludni). Vsz. 1 magát fórumozó programozónak természetesnek kellene, hogy legyen, hogy minta/példa kódot adjon(hogy helyes utat mutasson az általad ugyebár csak "fórumos vérpistikék" -nek nevezett emberkéknek - is). De ki tudja miért nem foglalkoznak vele? Talán csak egyszerűen félnek attól, hogy vki. kritikát mond/tanácsot ad nekik az esetleges kódjukhoz? Pedig az én példámon is látszik, hogy ez a programozás velejárója.
-
pmonitor
aktív tag
válasz
pmonitor
#17834
üzenetére
Buffer overflow esetén, ha a program nem száll el, akkor lehet a kód lassulása nélkül is detektálni az overflow-t, mégpedig a hívó(buffer-nek memóriát foglaló függvényben). Iteráció esetén, ha mindegyik bufferben max. a bufferek végéig találok L'\0' -t, akkor tuti, hogy nincs overflow, egyébként tuti, hogy van. Ezzel ki tudnám szűrni a #17829 - dabadab által említett viccben emlegetett hibát. Valamint még olyant is lehet csinálni, hogy lehetőséget adok a bufferek méretének manuális megadására. Pl. parancssori paraméterekkel... Ha a program elszáll, akkor esetleg ezek beállításával lehet módosítani...
Több használható 5letem nincs. -
#17834
pmonitor
aktív tag
Fire/SOUL/CD
#17833
pmonitor
aktív tag
válasz
Fire/SOUL/CD
#17833
üzenetére
buffer overflow-ról volt szó, nem stack overflow(
) -ról. Ezt azért simán meg lehetne oldani. Csak az említett okok miatt nem érdemes. Sztem. legalábbis. Én hagyom, hogy false adatot írjon ki, vagy elszálljon a program...@sztanozs:
>szóval fogalmam sincs, honnan vagy (vagy nem vagy) kitiltvaEzt 2lem. De ha teljesen őszintén írtad, akkor én meg teljesen őszintén elnézést kérek tőled...
De akár tudtad, akár nem, ez is azt mutatja, hogy semmiképpen nem jó, ha egyes topikokbó véglegesen kitiltanak valakit. Mert semmi nem jelzi ezt. Esetleg abban a speciális esetben, ha lejjebb lapoztál volna, akkor láthattad volna, hogy a nick-em szürke... -
#17833
Fire/SOUL/CD
félisten
pmonitor
#17831
válasz
pmonitor
#17831
üzenetére
OK. Let's do it
Ha ilyen "kemény" srác vagy, akkor lám, had lássam ASM-ba (vagy akármibe), hogy:
1. Detektáld az adattároló egységeket (IDE/SAS/RAID/SATA/NVME stb stb stb) ami a gépre/gépbe van csatlakoztatva
2. az általuk használt vezértőkódokat értelmezd
3. 32 avagy 64 bites (neked kell meghatároznod, hogy melyik) címzéssel ellátott memória belapozást állítsd elő(32 bites OS esetén ún base + index (base egy lap + ezen belül offset)) címzéssel lehet elérni (ha nem védett) a 0xFFFFFFFF12345678 címéről kinyerni adatot, mint 64 bit esetén(FLAT módan, mert van még vagy 8 MEM mód)
4. az adott eszköz (1-3 pont) drivere által belapozott memóriacíméről log-old az adatokat és értelmezdSegítség:: Ezt csak ASM-ban, vagy C/C++ lehet megvalósítani, megfelelő compiler és linker direktívák alkalmazása mellett.
Segítség2: 64 bit esetén nincs kód (CS), data (DS) és stack (verem) SP szegmens sem....Tesó, ha ezt megoldod, akkor ennek van értelme (Én megoldottam, kb. 15 éve, szóval hajrá)
-
sztanozs
veterán
válasz
pmonitor
#17827
üzenetére
Ne haragudj, de én nem vagyok sehol sem moderátor, szóval fogalmam sincs, honnan vagy (vagy nem vagy) kitiltva. De vsz nem vagy letiltva a topicnyitásról, szóval biztos tudsz nyitni egy "C/CPP optimalizálás sebességre" topikot, és ha valakit érdekel a dolog, akkor ott elbeszélgethettek róla.Hiperfizikus is nyitott egyet az agymenésére (nem mellesleg magától), és szerintem ő is jól elvan a saját projektjével ott (és legfeljebb a nagyobb fejleményekről számol be a javascript topokban) - pedig az ő projektje sem különbözik sokban a tiédtől...
Itt ez - szerintem - nem elég általános programozási téma. -
pmonitor
aktív tag
válasz
pmonitor
#17830
üzenetére
Annyit lehet csinálni, hogy ha detektálná az overflow-t, akkor kiírja, hogy "sorry, nem jutottam semmire...". De ez egyrészt hajszálvékony jég, másrészt végeredmény attól még nem lesz. Az egyetlen helyes út, ha megfelelő buffer méretet állít be a hívó függvény. 64 bites app esetén azért ez sztem. megoldható...
-
-
-
-
dabadab
titán
válasz
pmonitor
#17823
üzenetére
A moderátornak az a dolga, hogy a topik működését zavaró dolgokat eltávolítsa.
Márpedig ha valaki csak és kizárólag zavarja azt és folyamatosan, a sokadik figyelemztetés ellenére is ezt teszi, azt ki kell rakni.
Ennyi.Ha ezt nem értetted meg (és hát nyilvánvalóan nem), akkor az is csak azt mutatja, hogy mennyire indokolt volt az - és igazából az a csoda, hogy innen nem raktak még ki.
-
pmonitor
aktív tag
válasz
sztanozs
#17822
üzenetére
A kitiltásnak igen. A végleges kitiltásnak sztem. nem. Már csak azért sem, mert(ahogy már 1-szer írtam) a végleges kitiltást véglegesen megszüntetném. Tiltsanak ki vkit. 1 hétre, 1 hónapra, de véglegesen(főleg csak 1 topic-ból) nem. Úgyhogy ezt már csak ezért sem tartom jogosnak. A moderátornak sztem. az a dolga, hogy a trágár dolgokat kigyomlálja. És nem az, hogy egyes topicokból véglegesen kitiltson vkit. De biztos csak kissebségi komplexus-om van. Na meg az a gondom, hogy "nem vették fel valahova programozónak,". Holott az igazság az, hogy sosem jelentkeztem programozónak sehova... Csak az a helyzet, hogy a szövegelés hatalom nélkül semmit nem ér... Hatalma pedig a noname moderátoroknak van...
-
pmonitor
aktív tag
válasz
sztanozs
#17818
üzenetére
Sztem. ez a szakasz eléggé megmutatja, hogy én hogy képzelem el ezt a fórumot. Nem muszáj pmonitor-nak nyernie(nem ez a lényeg). Látod, hogy amit javasoltak, azt módosítottam. De sztem. ezekből a hozzászólásokból/javaslatokból az esetleges olvasók is tanulhatnak.
Viszont ami ez után a szakasz után jött - na az már tényleg nem "szakmai". -
sztanozs
veterán
válasz
pmonitor
#17816
üzenetére
Tudod, hogy én nem vagyok az optimalizáció pártján.
A helyedben az osszes wcscpy és wcscat hívást a BO-biztos _s végure cserélném.
Ráadásul az se látszik, hogy a tempFolders és a pFke hogy vandefiniálvapéldányosítva - szóval nem igazán tudok nyilatkozni. Azt sem tudom, hogy sebességre vagy RAM-ra szeretnél optimalizálni.Amúgy nem vagyok egy C/C++ guru, de mivel ezt nem a nyelv saját fórumában beszéled meg, így nem érzem a késztetést, hogy ne mondjak véleményt.
-
-
pmonitor
aktív tag
válasz
pmonitor
#17809
üzenetére
Módosítottam a dolgokat.
Hogy ne kelljen mindig ezt a viszonylag hosszú kódot bemásolgatnom, ezért ide tettem fel a file részletet.Az overflow aknákkal szándékosan nem akar(tam/ok) foglalkozni. Tegyük fel, hogy elég a lefoglalt memória...
-
dqdb
nagyúr
válasz
pmonitor
#17807
üzenetére
void search(wchar_t* sPath, wchar_t* sFileMask, FAJLKERESESEREDMENYE* pFke, char almappae, char mappae, char fajle)Ha már állandóan az optimalizáláson pörögsz, akkor hol vannak a
constmódosítók azon paraméterek elől, amelyek értékét nem módosítja a kód, és emiatt a compiler optimalizáláskor figyelembe tudja venni?wchar_t* sPath_1 = (wchar_t*)GlobalAlloc(LMEM_FIXED, (wcslen(sPath) + wcslen(sFileMask) + 1) * sizeof(wchar_t));Először is:
Másodszor az első paraméterben szereplő
LMEM_FIXEDaLocalAllochíváshoz tartozó konstans, itt aGMEM_FIXEDkonstanst kellene használni.if (sPath_1 == INVALID_HANDLE_VALUE) MessageBox(0, L"memória", L"Üzenet", 0);A dokumentáció alapján sikertelen foglalás esetében a
GlobalAllocvisszatérési értékeNULL, míg azINVALID_HANDLE_VALUEértéke -1, szóval rossz a hibakezelésnél mind a feltétel, mind a kezelése, hiszen NULL pointerrel továbbengeded a futást.És itt abbahagytam, mert feleslegesnek éreztem folytatni. Az egy pillantásra látszik, hogy tele van a kód buffer overflow aknával.
-
pmonitor
aktív tag
válasz
nevemfel
#17791
üzenetére
>de ez elvileg nem terápiás-, hanem szakmai topik.
Na akkor 1 kis "szakmai" probléma. Ezt kellene optimalizálni. Bármilyen kis optimalizálásnak örülnék, de az sem ártana, ha jelentős optimalizálás lenne...
...
typedef struct FAJLKERESESEREDMENYE
{
int Fajldarab;
int Mappadarab;
long long Fajlhossz;
wchar_t* Fajlok;
wchar_t* Mappak;
} FAJLKERESESEREDMENYE;
...
void search(wchar_t* sPath, wchar_t* sFileMask, FAJLKERESESEREDMENYE* pFke, char almappae, char mappae, char fajle)
{
if (!out)
{
int i = 0, n = 0;
wchar_t* aktFolders = tempFolders;
WIN32_FIND_DATA WFD;
HANDLE iSearchHandle = NULL;
int bContinue = 1;
wchar_t* sPath_1 = (wchar_t*)GlobalAlloc(LMEM_FIXED, (wcslen(sPath) + wcslen(sFileMask) + 1) * sizeof(wchar_t));
if (sPath_1 == INVALID_HANDLE_VALUE) MessageBox(0, L"memória", L"Üzenet", 0);
if (almappae)
{
wcscpy(sPath_1, sPath);
wcscat(sPath_1, L"*");
iSearchHandle = FindFirstFile(sPath_1, &WFD);
if (INVALID_HANDLE_VALUE == iSearchHandle)
{
}
else
{
while (bContinue)
{
if (wcscmp(WFD.cFileName, L".") && wcscmp(WFD.cFileName, L".."))
{
int s;
if ((WFD.dwFileAttributes & 16) == 16)
{
wcscpy(tempFolders, sPath);
wcscat(tempFolders, WFD.cFileName);
wcscat(tempFolders, L"\\\0");
s = wcslen(tempFolders);
tempFolders += s;
++tempFolders;
++n;
}
}
bContinue = FindNextFile(iSearchHandle, &WFD);
}
bContinue = FindClose(iSearchHandle);
}
}
bContinue = 1;
wcscpy(sPath_1, sPath);
wcscat(sPath_1, sFileMask);
iSearchHandle = FindFirstFile(sPath_1, &WFD);
if (INVALID_HANDLE_VALUE == iSearchHandle)
{
}
else
{
while (bContinue)
{
if (wcscmp(WFD.cFileName, L".") && wcscmp(WFD.cFileName, L".."))
{
int s;
if ((WFD.dwFileAttributes & 16) == 16)
{
if (mappae)
{
wcscat(WFD.cFileName, L"\r\n");
wcscpy(pFke->Mappak, sPath);
wcscat(pFke->Mappak, WFD.cFileName);
s = wcslen(pFke->Mappak);
pFke->Mappak += s;
++(pFke->Mappadarab);
}
}
else
{
if (fajle)
{
wcscpy(pFke->Fajlok, sPath);
wcscat(pFke->Fajlok, WFD.cFileName);
wcscat(pFke->Fajlok, L"\r\n");
s = wcslen(pFke->Fajlok);
pFke->Fajlok += s;
++(pFke->Fajldarab);
}
}
}
bContinue = FindNextFile(iSearchHandle, &WFD);
}
bContinue = FindClose(iSearchHandle);
}
GlobalFree(sPath_1);
if (almappae)
{
for (; i < n; i++, aktFolders += (1 + wcslen(aktFolders)))
{
search(aktFolders, sFileMask, pFke, almappae, mappae, fajle);
}
}
}
} -
martonx
veterán
válasz
pmonitor
#17803
üzenetére
Jaaa, hogy a Google-t pozitív példának írtad? Azért a Google keresés sebességét hasonlítani egy garázs szerveren futó SQL-éhez, szerintem nem korrekt. Ennyi erővel egy vadász repülőt is hasonlíthatsz egy normál autóhoz...
Emellett annyiban igazad van, hogy a garázs SQL-re olyan programozó dolgozik, aki egy év alatt nem keres annyit, mint a Google-nél dolgozó egy év alatt. Google-nél ilyenből van több ezer, a garázs SQL-en meg Pista bácsi egymaga bohóckodik.
Szóval igen, nem vagyunk egyformák, nem egyformák a képességeink.
Rengeteget állás interjúztatok, és nagyon gyakran ledöbbenek, hogy milyen gyenge programozók is vannak (többnyire állami szférából érkezettek a különösen fájdalmasak). -
pmonitor
aktív tag
válasz
martonx
#17780
üzenetére
>A Google keresés pedig nem a te géped, vagy a Google optimalizálatlansága miatt lassú,
Miért? Szted. lassú a google keresés? Sztem. a kiírás alapján nem lassú. Éppen azért írtam az adatbázis példát, mert az ezek készítői dicsekednek azzal, hogy mennyire gyorsak. Ha nem lenne fontos a sebesség, akkor miért is dicsekednének azzal, hogy milyen gyorsan van találati lista a nagy méretű adatból is.
Itt írtam, hogy a FindFileC.exe 64 bites lett. Csak sajnos tele volt bug-al, ami abból adódott, hogy a karakterkódolást unicode-ra állítottam, viszont elég sok helyen maradt char típus a wchar_t helyett. Bár úgy látom, hogy "csak" 1 letöltés történt azóta, de nekem 1 ember is fontos. Elnézést kérek a hibáért.
Egyébként ez hasít a TC-hez képest. De találtam 1 FreeCommander programot, ami ugyebár hivatalosan is free a TC-vel ellentétben. És ránézésre nem tud kevesebbet. Csak azt nem értem, hogy az ilyen programokat miért kell telepíteni? De mind1.
-
pmonitor
aktív tag
Az itt levő .rar-ban a FindFileC.exe 64 bites lett.
Jó programoz(gat)ást kívánok!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(Na majd most megmutasszuk az ASM erejét (max 2 óra)... 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Szeged és környéke adok-veszek-beszélgetek
- Hálózati / IP kamera
- Futás, futópályák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Autós topik
- Politika
- Melyik tápegységet vegyem?
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- Red Dead Redemption 2 (PC)
- Eredeti játékok OFF topik
- További aktív témák...
- Bosch GMS 120
- https://www.mac-audio.de/en/car-audio/subwoofer//mac-mobil-street-sub-108a
- BOMBA ÁRON ELADÓ! Üzleti HP Elitebook 640 G9 Laptop! / i5-1235U 16GB 256GB 14"col garancia/
- Akciós áron eladó HP Elitebook 850 G7 / I7 10610U/16 GB/512 SSD/15"/FHD/IPS/MX 250
- Szuper áron eladó új ACER SWIFT EDGE 16 /R7-7735U/16GB/512SSD/ 4K OLED
- Honor Magic7 Lite 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- 3DKRAFT.HU - 3D NYOMTATÁS - AZONNALI ÁRAJÁNLAT - GYORS KIVITELEZÉS - 480+ POZITÍV ÉRTÉKELÉS
- iKing.Hu- Apple Macbook 13 M1 Pro Touchbar - 2020 - Használt, karcmentes, 22 töltés
- iKing.Hu - Apple iPhone 15 Pro Max - White Titanium - Használt, karcmentes
- Sennheiser Momentum True Wireless 3 (2222132) (ELKELT)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest