Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Brogyi: CTEK akkumulátor töltő és másolatai
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: Te hány éves vagy?
- Klaus Duran: Minden drágul. Vajon a fizetések 2026-ban követi minimálisan?
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- Toomy: FOXPOST: régen jó volt, de már jobban jársz, ha elfelejted
- sziku69: Szólánc.
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
zoltanz
#16864
üzenetére
Gondolom mert a Debian nem teljesen kezdőknek lett szánva, és a felhasználóra bízzák, hogy milyen TRIM-elős megoldást használ. Eleve ott elkezdve, hogy NVMe SSD nem kell egyáltalán ilyet eljátszogatni. PATA/SATA/AHCI SSD-n kell csak.
A cron-ok között nem is fog szerepelni, mert a Debian systemd-s, és systemd service-szel oldják meg:
systemctl statusHa itt nem szerepelne az fstrim.timer service, akkor:
sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timerDe ehelyett azt a megoldást is választhatod, hogy te magad szerkeszted bele a /etc/fstab-ba az SSD partíciókhoz a discard (és esetleg a noatime) opciót. De ezzel is vigyázni kell, mert egyes speciális fájlrendszereken, pl. f2fs, máshogy kell engedélyezni, ott másik paraméter van rá, nem discard, persze ugyanazt csinálja, csak a neve más. Illetve vannak fájlrendszerek, amiken a discard egyáltalán nem támogatott, csak az fstrim, vagy fordítva. A két megoldás vagylagos, vagy egyiket, vagy másikat használd, mindkettőt használni felesleges.
Attól is függhet, hogy használsz-e ezekből valamit: RAID, LVM, LUKS, USB-UASP-SCSI.
Én egyébként rendszeresen, de kézzel futtatom a sudo fstrim -a -v parancsot, kb. 1-2 hetente, mikor kedvem szottyan rá. Vagyis egy saját scriptet hívok meg gyorsbillentyűre, ez lekérdezi smartctl-lel az összes SSD adatait, statisztikáit (hány napja szereltem be, ezt én számoltatom vele ki a beszerelési dátum és a mai dátum különbözetéből, mennyi írás van rajta, mennyi a kondíció, mennyi van hátra az íráslimitből, ilyen átlagos írási ütemmel mikor érem el az íráslimitet), és utolsó lépcsőben meg is fstrim-ezik minden felcsatolt partíciót.
Az, hogy mennyi időnként kell fstrim-ezni, ez függ az SSD tárterületétől, rajta lévő szabad helytől, és hogy mennyit írsz rá naponta. Ha egy nagy SSD-d van, pl. min 240-500 gigás, és még bőven van rajta min. 20-30% szabad hely, és naponta ilyen 10 GB alatt írsz rá, akkor elég ritkán TRIM-ezni, pár hetente.
Ha viszont ilyen kis szüttyőnyi sz4r, 32-128 gigás, szabad is alig van rajta, és csapatod fel az írást rá napi 20 GB fölött, akkor viszont érdemes lehet majdnem naponta TRIM-ezni. Illetve a két említett véglet között ott vannak az átmenetek.
A discard azonnal TRIM-ezik, fájl/mappatörlés utána közvetlenül egyenként, ott nem értelmezhető, hogy milyen gyakran fut le, nem ütemezés függvénye.
-
Frawly
veterán
válasz
sh4d0w
#15403
üzenetére
A raytracingről pont az írtam, hogy van, inkább azt tettem kérdésessé, hogy natívan használja-e egyáltalán valami, és a nem natív változat meg megy-e egyáltalán Linuxon. Ha van valami, ami tényleg natívan használja, akkor viszont mennie kéne, mert a DX12, Vulkan API-kba benne van, az RX2xxx szériához meg van driver, így technikai akadálya elvileg nincs. Valójában csak spekulációkat írtam, de te sem tudtál konkrétabbat írni, így nincs jogod lehülyézni.
Nem a chmod-ról írtam, hogy öröklődik, hanem egy már chmod-olt mappának a jogosultságairól. A chmod nem öröklődik, azt csak azt állítja be, amit kérsz, és ha nem adod meg neki a -R rekurzív kapcsolót, akkor csak adott fájlra, mappára fog vonatkozni. A chown által beállított tulajdonos az nem öröklődik, mert az tényleg attól függ, hogy a fájlt, mappát milyen felhasználóval hozod létre, de az rwx-jogoknak alapesetben öröklődnie kéne, ha nem bírálja valami felül. Lehet tévedek, de akkor javíts ki.
JFS, XFS esetén sem azt írtam, hogy egyáltalán nem fejlesztik, mert rendszeresen cikkezik róla a Phoronix, meg a kernelnewbies új kerneles logjaiban is rendszeresen említésre kerül, hogy egyik-másik kapott valami apróbb javítást. De ettől ezek már legacy fájlrendszerek, ahogy már írtam nem „nagyon” fejlesztik. Egyébként egyszer kíváncsiságból biztosan kipróbálom őket, de eddig a lustaság, meg a legacy status nem nagyon vitt rá, hogy ilyen irányba is kísérletezzek.
Meg az f2fs-es kaland is elvette erről a kedvem, anno az f2fs szakik is megszakértették, hogy SSD-re az kell, mert épp úgy jobban értettek hozzá, mint most te ezekhez a témákhoz. A Phoronix még ilyen 100 oldas bencharkgrafikonokban is lehozza, hogy sok minden gyorsabb. Nálam ténylegesen kipróbálva sok mindenben érezhetően lassabb, méricskélni sem kell hozzá, ráadásul bugos is volt.
-
Frawly
veterán
válasz
sh4d0w
#15391
üzenetére
Nem azt mondtam, hogy nem fejlesztik, hanem hogy nem nagyon. Csak kisebb foltokat kap. Egyébként meg nem ócsároltam, csak azt írtam, hogy ez alapján soha nem kaptam még kedvet a kipróbálásához. Az ext4 van olyan villám gyors, HDD-n és SSD-n is, hogy nem hinném, hogy az XFS vagy a JFS gyorsítani tudna ezen bármit is.
Ráadásul csak példának írtam, mert ilyen nagyon okos benchmarkok kihozzák, hogy az f2fs gyorsabb. Nem gyorsabb. Az f2fs olyan Flash eszközre való, aminek nincs saját aktív vezérlője, azokon valóban jobb lehet, mint egy ext4 pl. De SSD-n nincs előnye.
Persze SSD-khez kéne új fájlrendszert tervezni. Ami inkább egyszerűsítést takarna, kisebb overheaddel. A legtöbb fs ugyanis HDD-re készül, és a töredezés elkerülésére van benne egy csomó minden. Igazából egy max performance ssd fileysystembe ilyen journaling és metadata is felesleges, ha sebességet akar az ember. A legtöbb fájlrendszert telegyömöszölnek extra feature-rel, tömörítés, titkosítás, deduplikáció, copy-on-write, journaling, stb.. Ezek hasznosak is, de a fájlrendszer gyorsasága ellen hatnak.
-
F34R
nagyúr
válasz
Frawly
#15385
üzenetére
Meg azt mondod nem fejlesztik ez LOL....
Egyetlen oka annak hogy ext4-re valtottam vissza, meg evekkel ezelott, hogy a compile lassabb es nincs valos journaling csak metadata... volt adatvesztesem is aramkimaradaskor PL.
A JFS-t azt tenyleg elfelejette mindenki NAGYOOOONN regen nem fejlesztik, azonban meg mindig ott van a kernel-ben szoval erdemes ha mar flash alapu kartyarol vagy masrol f2fs helyett azt rakni.. Meg evekkel ezelott savaztak azt aki azt mondta hogy a samsung filerendszere az egyeduli.
(#15386) ubyegon2
Sok hasznat nem vetted volna... meg linux ismerkedesem elejen volt egy JFS Arch Installom ext4-hez kepest tenyleg csak a kicsivel gyorsabb eleres es sebesseg felhozhato, mas miatt viszont Ext4 sokkal erdemlegesebb, foleg hogy behozta lemaradasat..
(#15388) Frawly
Dehogynem.... Mindkettonek van Kornyezeti bootolhato rendszere, amivel felrakod magadnak szepen oket...
Nem a hagyomanyos installer, de vegulis az.. Isten mentsen attol, hogy mindent magadnak kelljen forditani![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Frawly
veterán
Még most, a legutóbbi tesztben is jobbnak hozta ki a Phoronix. Lehet szintetikus bencharkok alatt jobb az f2fs, de a való életben pattogósabb az ext4. Gyorsabban fstrim-elődik, gyorsabb az fsck lefutása, gyorsabb a fájlok keresése, gyorsabbnak érzem bootot és az alkalmazások betöltését is róla. Azt meg nem érdekel, hogy 1-2%-kal lassabb esetleg nagy fájlok másolásánál, olyat ritkán csinálok.
Júbájgönnek a böngészőteszthez még: ezek mind webes benchmarkok. Általában x darab teszt JS-et futtatnak le, megnézik, hogy adott idő alatt hányszor futnak le ezek a JS-ek. Az eredményeket súlyozva átlagolják, aszerint, hogy az adott fajta script milyen gyakori böngészés során. Így kijön egy átlagolt szám. Önmagában semmit nem lehet ezzel kezdeni. De ha annyira megnyugtat, íme a mértékegység: scriptlefutásiteráció/sec×súlyszám/összsúly
Igazából elég egyoldalú mérés is, mert ezek a webes benchmarkok csakis a böngészőmotor renderelési sebességét mérik. De nem mérik a böngésző felhasználói felületének reszponszivitását, a böngésző indulási idejét, CPU/mem-fogyasztását, hardveres gyorsítás hatását a tényleges képernyőre renderelésre, stb.. Tehát erre is általában ilyen Bencs Márk Pistik gyúrnak, igazából értelmes embert nem érdekel. De azért néhányan kíváncsiak, hogy 10-20 főverziónként hogy teljesít az adott böngésző pl. korábbi önmagához képest, vagy a konkurenciához képest, ebből lehet sejteni, hogy a megnövekedett kódbázis mennyivel lett bloatabb, és ehhez képest újabb optimalizációkkal mennyire sikerült ellensúlyozni.
-
Frawly
veterán
válasz
ubyegon2
#15380
üzenetére
Mert mikor a 3D Mark a GPU-n mér 10578 pontot, az szerinted mi? Forint×MB/kg/W/sec² vagy kismalac/farkas? Ez nem a Phoronix hibája, hogy a böngészős benchmarkok ilyen hülyeségeket mérnek. Ő is csak azzal tud mérni, amilyen benchmarkok vannak. Úgyse a szám meg a mértékegység a fontos, hanem hogy X megoldás hány %-kal gyorsabb, mint Y. Nyilván ezek amúgy is hülyeségek, mert szintetikus benchmarkok. Ezt én is megszoptam a Phoronixon, hogy pl. SSD-n az f2fs-t is mindig gyorsabbnak hozzák ki a számok, közben a valóságban meg ext4-gyel sokkal pattogósabb minden. Sose szabad ilyen benchmarkokat túl komolyan venni, csak tájékozódás szinten jó, hogy egy adott hardvert vagy szoftveres megoldást be tudj lőni szintben.
-
Frawly
veterán
válasz
Rimuru
#14670
üzenetére
Nekem csak az a bajom az f2fs-sel, hogy bootoláskor meg sok kis fájlokkal történő műveletekkor lomhának érzem. Meg a TRIM-ezése is lassú, és problémás, sem a discard, sem az fstrim nem támogatja, hanem saját garbage collection nevű megoldása van erre, ami minden x. boot és minden kernelfrissítés után lefut bootoláskor, és megcsinálja a TRIM-et.
Én is azért tettem fel f2fs-t, mert sok „szakértő” az írta a cikkekben, hogy SSD-re való, meg gyorsabb, mint az ext és társai. A Phoronix még ilyen alapos, több oldalas részletes méréseket is betett, hogy tényleg gyorsabb, ami igaz is, ha pl. nagy fájlokat másolsz vagy szintetikus teszteket futtatsz rajta, de valós felhasználás esetén sokkal fürgébbnek és problémamentesebbnek érzem az ext4-et. Nem véletlen, meg nem konzervativizmus, hogy az a default fs a legtöbb disztróban. Azt szoktam javasolni, ha nincsenek speciális igények (deduplikáció, snapshot, röptömörítés, stb..), akkor érdemes a deafult ext4-nél maradni, HDD, és Flash-alapú tárolón is.
-
Rimuru
veterán
válasz
Frawly
#14669
üzenetére
Maces vilagban meg sokaig volt pofajuk penzt is kerni a frissitesert. Szerencsere most mar nem kell, es 5+ ev gyari tamogatast kapsz (ha foverziot frissitesz).
f2fs: nem tudom hogy tudja bob hasznalni, kesobb teszteltem mint o, megis tobb problema elojott vele (nem tudok konkretumot irni)...
-
Frawly
veterán
válasz
zoltanz
#14662
üzenetére
Szerintem ezt nem lehet így kijelenteni. Mindenkinek más a jövő. Átlag desktop usernek elég az ext4, egyszerű, gyors, minden támogatja, szinte mindenhol default, az alap ext4-toolok is minden disztrón fent vannak szinte. Sok felhasználónak felesleges a btrfs extra featurehalmaza, pl. snapshot, cow, deduplication, röptömörítés. A legtöbben már SSD-t használnak, azon az online defragnak sem lehet már hasznát venni. De egyébként ez is fontos, hogy az SSD-nek már szinte mindegy melyik fs van fent rajta, egyformán villámgyors mindegyikkel, még a legszutyokabb NTFS, FAT32-vel is. HDD-knél még sokat számított milyen fs-sel használod őket.
De ha valakinek kell is a btrfs többlettudása, akkor ebben a szegmensben meg a ZFS on Linuxszal is versenyeznie kell.
Az f2fs meg inkább pendrive-okra, SD kártyákra való. Most hosszú hétvégém lesz, teszem is vissza az f2fs helyett az ext4-et és újratelepítem az Archot. Nincs még baj a rendszeremmel, de az f2fs-t nem érzem kellően fürgének (bootkor kicsit lomhának tűnik), meg sok felesleges gnome-es csomag és egyéb bloat van fent, így inkább tiszta lappal kezdek, csak a SwayWM-et, konzolos alkalmazásokat, stb. teszem vissza.
-
Frawly
veterán
válasz
zoltanz
#14616
üzenetére
Ezzel egyetértek. Teljesen felesleges volt ZFS-ből két vonalat is fejleszteni, csak arra volt jó, hogy megossza a fejlesztőket, erőforrásokat. Fejlesszenek egy közös vonalat, de azt rendesen. Disztróknál is ezért baj a túlzott sokszínűség.
Meg azzal sem értettem egyet, hogy a BSD-ket, Illumnost sokan istenítik, hogy jajj, közvetlen Unix-leszármazottak, meg történetileg a gyökerek messzebbre visznek, míg a Linux az valami nemrégiben lángra kapott finn hülyegyerek hobbija, és akkor az biztos nem olyan jó és tuti komolytalan. Közben meg a mai unixlike rendszereknek már semmi közük nincs az eredeti Unixokhoz, még azok a BSD-k is, amelyek jobban építettek az eredeti forráskódra, ma már annyira megváltoztak kernel-, körítésügyileg, hogy már semmi közük hozzá.
ZFS, Btrfs átlag desktop gépre felesleges. Inkább szerverre valók az extra szolgáltatásaik, ahol fontosabb az adatintegritás, meg a snapshotozás és ilyenek. Mondom ezt úgy, hogy jó ideig használtam btrfs-t, amivel semmi bajom nem volt (azon kívül, hogy akkoriban még swap fájlt nem támogatott, most már ezt is javították), én arra használtam, hogy HDD-n töredezettségmentesítsem a rendszert úgy, hogy ne kelljen lecsatolgatni a partíciót, arra akkor jó volt, de minden más szolgáltatását kikapcsoltam, hogy ne egye az erőforrásokat, úgy meg nem sokkal volt másabb egy ext4-nél. Szóval valamikor hasznosak lehetnek ezek valami speciális igény felmerülése esetén, de nagy átlagban random desktop gépre minek. Attól most senki nem lesz Richard Stallman, mert a default fs helyett ZFS-t használ.
A fs benchmarkok is megtévesztőek, mert pl. az f2fs-t is azért tettem fel, mert sok forrást esküdött, hogy jobb az SSD-nek, meg sok benchmark kihozta, hogy gyorsabb, mint a többi, aztán közben egyik érv sem áll meg. Az SSD vezérlője úgyis fájlrendszertől, partíciótó, és egyéb szoftveres logikai feldolgozástól függetlenül kezeli az adatokat, az f2fs meg lehet nyers erőben jobb ilyen szintetikus méréseken, de a gyakorlatban átlag felhasználásnál a rendszer, a TRIM sokkal lomhább rajta, mint ext4-en. Ezért nem szabad hinni a „szakértők” színes grafikonjainak, a Phoronix meg a többi is tud jó nagy hülyeségeket leírni, és még ügyelnek is rá, hogy nagyon hozzáértőnek tűnjenek.
-
Frawly
veterán
válasz
Frawly
#13633
üzenetére
Megnéztem. Nem nagyon vár semmire a boot során, a systemd-analyze megmondta. Sokkal inkább ez az f2fs lassúsága lesz. Mondom én, hogy ebből újratelepítés lesz. De nem sietem el, előtte alaposan kitesztelem és átreszelem a Swayt. Nem kizárt, hogy végül visszatérek Xorg Openboxra.
-
Frawly
veterán
Gondoltam már a konzolos login managerre. De az az igazság, hogy Wayland alatt nincs ilyen fagyási baj, pedig az is KMS drivert használ (i915). Tehát a hiba egyértelműen a Xorg-ban van, nem szereti a GPU-m, de Wayland alatt jó. Wayland alatt viszont a GDM az egyetlen értelmes grafikus login manager / DM.
(#13568) tvamos: a btrfs nem rossz. Csak nem használnám ki az extra feature-eit. Régen HDD-hez használtam, egész jó kis filesystem, akkor főleg az online defrag miatt tettem fel, nem kell unmountolni töredezettségmentesítéshez, meg tud röptömörítést. Viszont SSD-n már ezek egyikét sem használok, meg pl. snapshotot sem. Teljesen jó az ext4, csak elkalandoztam f2fs-es vizekre, mert mindenki istenítette, hogy milyen fasza, Flash alapú tárolókhoz és SSD-khez lett kifejlesztve. De az az igazság, hogy SSD-nek nem kell Flash-barát fs, mert a vezérlő intéz mindent, így tulajdonképp mindegy milyen fájlrendszer van SSD, csak legyen kellően gyors, meg támogassa a TRIM-et.
-
Frawly
veterán
Nekem is az ext4 jött be legjobban, gyors mint a villám. Ez az f2fs lassúcska, főleg a TRIM-elése bootkor. Nagyon nem jön be.
A Xorg-gal az a bajom, hogy az HD3000-es Intel GPU-m, ami a CPU-ba van integrálva, Xorg-gal a login managerek fagyogatnak, ha fent van a Xorg Intel driver, ha nincs (ilyenkor KMS kernel driver van helyette).
A Way Coolerrel én is szemezek, nézegetem mivel tud többet, mint a Sway (ami i3wm-klón Waylandre).
-
F34R
nagyúr
válasz
bambano
#13562
üzenetére
Hallani hallotal, de nem hasznaltad. Amennyiben hibakrol beszelunk a Debianon is van egy jo nagy, nevezetesen systemd. A realesek alaposan elo vannak keszitve a stabil hasznalatra. Egyebkent a kerdes
mar megvalaszolt volt akkor mikor feltetted.#13565) Frawly
F2FS a samsung omlengese, nem egy igazan nap mint nap hasznalhato FS. XFS/Ext4 amit en ajanlok.
Blikkre mondanam neked hogy Xorg es Openbox.
De itt van meg neked egy talalatom : [link] -
Frawly
veterán
A napokban fogom újratelepíteni az Archom. Elégedetlen vagyok az f2fs-sel és a Gnome 3-mal. Visszaállok ext4-re, de grafikus felületnek nem tudom mit tegyek fel. A Sway-jel szemezek leginkább, de szóba jönne a Waybox is. De félek ezekkel is ugyanott leszek, hogy nem fogom tudni rendesen témázni. Ami még szimpatikus Wayland alapokon az a Liri Desktop. Vagy kaphat újra esélyt a KDE5.
Esetleg lehet visszaállok Xorgra, és mondjuk kipróbálom a Budgie Desktopot, vagy visszateszem az Openboxot.
-
Nem is írtam, én Intel 520 120 GB-ot nyúzok. Ha Samum lenne, simán bepróbálnám ezt a saját fejlesztésüket! Okostelón meg főleg, mert a Samu az azokban lévő flash memók miatt fejlesztette igazából az f2fs-t, de lehet, hogy rosszul tudom. 
Persze kísérletezésre bármi jó, mint azt Iscariah ft is írta.
Én is azt teszem az SSD-vel, bár kényszerből, mert a kapott Toshiba laposban nem volt semmilyen meghajtó, így át kellett tennem. Fut is rajta pár már SSD-n lévő disztró. -
Így van, SSD-re F2FS ajánlott
Azt már olvastam, hogy kifejezetten nand alapú meghajtókra készült, hogy ajánlott lenne SSD-re? Eddig Linux alatt SSD-re én az ext4-et gondolom legmegfelelőbbnek, az említett Phoronix tesztnél semmi szignifikáns különbséget nem érzékelhetnél, egy tesztnél van nagyobb különbség, de ott épp az ext4 a jobb. sqlite
Tegyük hozzá, hogy az ext4-et is deadline i/o scheduler és nem noop alatt tesztelték! Noop alatt, mint tudjuk, jóval gyorsabb az SSD Linuxon!
Így aztán hiába szuper a Samsung fejlesztése nand alapú flash meghajtókra, az ext4 noop i/o ütemezővel inkább ajánlott SSD-re Linux alatt! szerintem
-
Raynes
tag
válasz
Apollyon
#5884
üzenetére
Így van, SSD-re F2FS ajánlott, nem csak azért, mert kíméli a felesleges írásoktól a lemezt, hanem azért is, mert a 4-es kerneltől ez a leggyorsabb fájlrendszer SSD-khez, főleg párhuzamos fájlműveleteknél mutatnak nagy előnyt a Phoronix tesztjei. Egyszerűen must have a F2FS SSD-nél desktopra, esetleg a Btrfs is szebben muzsikál rajta, mint az Ext4. Fontos hangsúlyozni, hogy tényleg csak a 4-es kerneltől, 3.x-en nincs közöttük nagy sebességbeli különbség, pláne nem HDD-n.
@bamba nő: te ilyen muzeális fetisiszta vagy-e? Debian 5, Firefox 10, Ext 2, Wtf 1
-
#4165
lionhearted
őstag
Ez az F2FS vajon elég stabil napi használatra? Épp vettem egy SSD-t, de még tanakodom holnapig a fájlrendszerén...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Arc Raiders
- Békéscsaba és környéke adok-veszek-beszélgetek
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Google Pixel topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- MIUI / HyperOS topik
- Amazfit T-Rex 3 Pro – világítós dínó
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- exHWSW - Értünk mindenhez IS
- AMD vs. INTEL vs. NVIDIA
- További aktív témák...
- LG UltraGear 39GS95QE-B OLED Monitor
- IPAD 7 2019 Wifi+Cellular 128GB , ÜZLETBŐL, GARANCIÁVAL, 27% ÁFÁ-s
- Ps5 slim digital bontatlan 2 év MM gari!
- ÚJ Bontatlan Apple Macbook AIR M2 , M3 , M4 Legújabb magyar billentyűzet 1 év Garancia Deák Térnél.
- AKCIÓ ÚJ Bontatlan Macbook Pro 16 M4 Pro 14CPU/20GPU 24GB/512GB SSD Magyar billent Azonnal átvehető.
- AKCIÓ! LG UltraFine 27" 5K IPS 99% DCI-P3 1 év garancia
- í kilenc! AKCIÓS PRECÍZIÓS KÉSZÜLÉK! 7670 i9-12950HX 64GB RAM 1TB SSD Nvidia RTX A3000 12GB 1 év gar
- GYÖNYÖRŰ iPhone 12 mini 128GB Blue-1 ÉV GARANCIA - Kártyafüggetlen, MS3415 94% Akkumulátor
- HIBÁTLAN iPhone 15 Pro Max 256GB Blue Titanium -1 ÉV GARANCIA -Kártyafüggetlen
- HIBÁTLAN iPhone 14 Pro 128GB Gold-1 ÉV GARANCIA - Kártyafüggetlen, MS4096
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest