-
Fototrend
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
válasz
fekete.puma #104391 üzenetére
Szerintem manuális partcionálással érdemes csinálni, én is csak azzal tudom majd. Kijelölöd az EFI-t neki és csinálsz egy /-t Btrfs-re, videón is ezt csinálja az ember, mondjuk fura, mert nem a manual particionálást választotta előtte vagy csak nem vettem észre!
-
válasz
fekete.puma #104386 üzenetére
Azt írja, hogy hozzon létre egy 8MB-os formázatlan particíót bios-grub jelzővel.
Ez érdekes, mert az oldalán lévő videóban a 100MB EFI-t kattintotta be az ember, nem volt szó külön 8MB particióról. No mindegy, kíváncsivá tett a dolog, ha hazaértem, meg is nézem. Melyik verziót töltötted le, a minimalt vagy a normált? A zram megléte nem sok vizet zavar egyelőre... -
válasz
fekete.puma #104383 üzenetére
Bár úgy lenne..
Ha ez a Big Linux, akkor viszont rossz hírem van, BTRFS-t még nem kezdtem el megismerni, így ezek a subvol valamik is csak ismerősek, de manuálisan nem tudnék velük mit kezdeni! Nyilván elsők között a particionálást érdemes rutinná tenni. Szóval ebben nem tudok segíteni, sorry!!
-
válasz
Dißnäëß #104371 üzenetére
Sok érdekes dolgot vetettél fel, sajna a LUKS és társai nekem sötét ló. Amúgy a Live Linux nem fogja trimmelni a külső meghajtót, de még a belsőt se. Alapból teljesen más a külső SSD-k kezelése, de nem is csak a Linuxtól függ. Ha a header megváltozik, az egyértelmű helyzet, de akkor viszont meg már az a biztonsági kockázat, ha fenn marad a régi.
Szerintem ásd bele magad ezekbe, mert tuti ott a válasz is valahol:
Frequently Asked Questions Cryptsetup/LUKS
Enable TRIM on external LUKS encrypted drive
Tetszik az előbbi Cinnamonos desktop képe, csak nem valami NER-es jómunkásember yachtja látható rajta!?
Nekem csak a T-REX van most a desktopon...innen tudom, hogy a négy hasonló rendszer közül melyiken vagyok.
-
válasz
tordaitibi #104357 üzenetére
Nem nagyon lenne műlödőképes ssd ha ezt így csinálná.
Vagy mégiscsak!
Nem nagyon érdemes belemenni, most hirtelen nem is ugrik be, de itt is külön vehetjük a user meg az OS meg a controller szerepét. Utóbbi egy vagy két dologért felel ráadásul, most hirtelen meg se mondom, melyik vakegér szaladgál cellákat törölgetni és melyik a blokkokat rendezgetni.
Kb ez a zanzája:
"Az SSD legkisebb egysége a lap, amely több memóriacellából áll, és általában 4 KB méretű. Az SSD-n több lapot egy blokkba foglalnak össze. A blokk az SSD-k legkisebb hozzáférési egysége. Jelenleg többnyire 128 oldalt egyesítenek egy blokkba; így egy blokk 512 KB-ot tartalmaz." (ez így lefordítva kicsit értelmetlen, de most már mindegy, szóval ne zavarjon, ha úgy is szerepel valami, mint a legkisebb egysége és úgy is, mint a legkisebb hozzáférési egysége)
Az adatok írása/olvasása a blokkokban/ból történik, fura is lenne, ha a layout felépítése ellenére neked 1M méretű képet egy helyre akarna pakolni. De miért is tenné? Gyakorlatilag ugyanannyi idő neki elérni a blokkokat, akárhol is vannak.
Gyakorlatilag minden szétszórva, mint anno a HDD-n, csak ez itt nem számít töredezettségnek, de egy vakegérke mindig szaladgál, így van amelyik rendszerhasználat alatt is dolgozik és van amelyik csak akkor, ha hallja, hogy nem mozog semmi.
csixy komám ezt most értelmesebben leírta, mint én!
-
válasz
tordaitibi #104363 üzenetére
Ha nagyon akarod szétpattintom bár fel van sziloplasztozva a monitor hátuljára.
Ha egyszer lesz kedved, szétpattinthatnád, de jól olvashatóan fotózd ám le a NAND-ot meg a controllert meg ha még van benne valami. Ha egyáltalán van rajta valami írsá, számsor.
Vagy mennyire kamu?
Ez a piros csoda mennyire kamu?
Szerinted? 4TB külső SSD 12rugóért? Sokszor valami kisebb méretű SD Card van beapplikálva egy NYÁK-ra, de behazudja kiolvasáskor a rendszernek, hogy 4TB, csak ha majd írsz rá, akkor áll meg 128gigánál.
Szerintem ezt ne próbáld be.
Aliról szoktak sokan venni 16TB-os SSD-ket 8-10000 pénzekért.
Az a durva, hogy ezeket sokszor fel is rakják ide az apróra, ha valaki jelenti őket, akkor meg azt rúgják sejhajon, mert hát nem is hamisítvány!
-
DRAM cache-sel szerelt SSD-re gondolsz? Amúgy PCIe NVMe esetén jóval kevésbé hiányzik a DRAM cache, ráadásul itt már bőven pótolja a NAND-on belül beállított saját cache vagy a host memory buffer, ezért is csak a jóval drágább NVMe SSD-ken van DRAM cache. Legjobb példa erre a Samsung 980 és a 980 Pro, előbbi csak HMB-s, de sokkal olcsóbb. Volt anno. Amúgy meg normál Linux használatnál nincs is sok jelentősége a DRAM cache-nek, de a parasztvakító szekvenciális sebességnek se nagyon. Nem véletlenül szerelik a használtüzleti notikat adott modellkategórián belüli alkatrészekkel, de jóval lassabb szekvenciális sebességre programozott controllerrel, igaz ez főleg a melegedés kivédése miatt van. Van pár kivétel persze, ahol az energiafogyasztás csökkentésével tudták megoldani az óvatosabb melegedést és a szekvenciális sebesség maradt ugyanakkora, mint a konzumer kiadásnál. Ilyen a SK Hynix PC801 például, ami a rohadt drága SK Hynix Platinum P41 OEM verziója. Épp egy ilyenre vadászok megint, mert ami volt, azt beraktam családon belüli gépbe, de saját Dell Latitude-ban se tudtam rendesen letesztelni, mert csak x2-es PCIe 4.0 csatlakozó volt benne. A mostani Zbookban is van két M.2 PCIe hely, de fogalmam sincs, melyik milyen, most valami ezeréves Samsung OEM van benne, az tuti csak PCIe 3.0.
-
válasz
tordaitibi #104350 üzenetére
Ennyiért ingyé vót
Egy Intenso? Ha úgy nézed, hogy kidobtál az ablakon egy huszast, de az SSD meg ingyér van, akkor úgy OK!Ha még le is írja az eladó, hogy van valami érdekes nyűgje...gondolom nem zavart, hogy fogalmad sincs, mi okozza ezt a leállást és bármikor végleg megnyekkenhet!
Engem pont az zavar egy ilyen eszközben, ha nem tudom, mi miért történik. Anno 1,92TB Samsung PM883-at vettem használtan, rohadt drága volt, de benne volt az árában az is, hogy sose megy tönkre és amikor M.2-es platformra váltottam, majd ugyanannyiért el tudtam adni szintén az aprón. Nincs kedved szétszedni, hogy megnézzük, milyen NAND meg controller van benne?
-
válasz
Petya XT #104348 üzenetére
Lehet szóba is került már ez az Intenso SSD-d, a Kingstonra emlékszem inkább. Nem egy kategória volt a kettő régen sem, de az Intenso ugyanúgy lehet teljesen jó, mint ahogy kukaszökevény, ennél a zsákbamacskajelleg az idegesítő. Gyakorlatilag kínai dzsunkaSSD mintájára történik a gyártás, amit találnak a hardverpiacon, abból összeforrasztják az eszközt és ezek az esetek többségében működnek is.
Nekem is volt/van tartalékba sok régi 120GB meg 250GB SSD-m, többnyire használtan vettem ezeket, jók ezek, mert ha kell családban is régebbi notikba hirtelen, van mihez nyúlni. Viszont soha nem voltam olyan bátor, hogy Intensot vegyek!
NVMe SSD-ket is egy ideje az apróról veszem, ami meg a használtüzleti notikkal jön, mind elrakom, mindig jól jöhet. El még nem pusztult SSD-m, valami Kingston Fury 120GB rosszalkodott minap, de gyorsan ki is cseréltem legelső újonnan vett SSD-mre, Intel 520 120GB, no ez rohadt drága volt anno, igaz kb sose fog tönkremenni.
Az ócskább SSD okán lehet olyan funkció, ami nem kerül bele, vagy minden típusú SSD-n ugyanazokat a beállításokat használja az adott rendszer?
Szerintem ilyen ócskább/nem ócskább alapon nem szelektál a rendszer!A spécibb SSD tulajdonságokkal nem is foglalkozik, beazonosítja, hogy Sata meg milyen NAND van benne, nagyjából ennyi.
Ha a Linux Mint upgrade-elt verzió, akkor úgy érthető, ha már nem egy eredeti állapot van a systemd.service résznél. Régebben én is variáltam ezekkel telepítés után, mert mindig van, amiket ki kell lőni, vagyis inkább érdemes, mivel sok időt elvisznek a bootból. Viszont mióta EFI boot van, nem foglalkozom vele, úgyis sok a bootidő.
-
válasz
Dißnäëß #104346 üzenetére
sh4d0w és cigam kolléga lényegretörően megválaszolta(hamarabb is észrevehettem volna), de itt valóban elég speciális helyzet van, ezért kb ennyi a lényeg:
Solid state drive users should be aware that, by default, TRIM commands are not enabled by the device-mapper, i.e. block-devices are mounted without the discard option unless you override the default.
For a LUKS2 device, TRIM support can be enabled by using the
--allow-discards --persistent
options when opening it. Theallow-discards
flag will be written into the LUKS2 header and the option will be automatically used whenever the LUKS2 device is opened. -
válasz
cigam #104341 üzenetére
Azért elég sokan cserélnek/vesznek új SSD-t a gépükbe, notebookba. "Mit kell ahhoz érteni, rendelek egy super M.2-es SSD-t mert az kell bele!
Sok hülye okoskodik, hogy picit nem árt érteni is az SSD-khez."
Megjött az SSD! Juhúúú....de jaj istenem valami baj van, semmi nem ismeri fel, pedig jó helyre csatlakoztattam!
brühühü...mi lehet a baj??? Rohaggyonmegabót átbasztak!!!! Juj gyerünk az SSD topikba!
Gondolom sejted mi lehet a probléma a nagymellényen kívül!?
Érdemes nézegetni az SSD topikokat, milyen kérdések merülnek fel állandóan.
-
válasz
cigam #104336 üzenetére
Én pl. azon csodálkozom, hogy miért nem oldja meg házon belül, ahogy az M.2 csatolós eszközök esetében.
Érdekes lenne, de mivel ez egy ősrégi PATA/SATA utasítás és az OS-ek kompetenciája, így ebbe a gyártók nem fognak belenyúlni értelemszerűen.
A PCIe NVMe SSD-k TRIM-melést viszont már nem az OS végzi, hanem az eszköz vezérlője.
De mint említettem is többször, nem nagy gond, ha nem foglalkozik vele a user SATA esetén, mert még mindig ott a garbage collection, ami nevéből adódóan tisztogatja a már törölt adatokkal terhelt blokkokat.
De egyébként az SSD is egy hardver, mint a VGA meg a többi. Ha rengeteget foglalkozik a topik a VGA-k vezérlésével, miért lenne gond az SSD-k vezérlése, optimalizálása? A VGA is olyan eszköz, hogy nem kell ismernem a működését, felrakom a rendszert, aztán az használja okosan a megjelenítésért felelős hardvert. Nem? De!
Én csak arra utaltam imént, hogy gondolkodjunk okos pingvinként, ne hátbalőtt tapírként!
Ne üldözzük a gép egyik fontos elemének megismerhetőségi lehetőségét egy Kezdők OS-sel foglalkozó topikjából.
-
válasz
Petya XT #104331 üzenetére
Csak az jött vissza, hogy /mnt/Archívum meghajtóm nem támogatja a discard funkciót
Manual fstrim előtt akár le is csatolhatod a HDD-t, bár elméletileg úgy volt, hogy a libata tartalmazta a nonrotate kitételt is, így a hagyományos merevlemezeket nem vette figyelembe.
Ott gyanús lett, hogy itt valami nem jó.
Valami tényleg gyanús, de ha telepítéskor default az ütemezett fstrim, akkor nem tudom, mi inaktiválta!? Mondjuk nem árt telepítés után ellenőrizni, hogy aktív-e, mert pár éve épp Kapitány jelezte, hogy a Manjaron kicsit elfelejtették berakni az fstrim.service-t az aktív ütemezetten lefutó feladatok közé.
De jellemzően vagy az online vagy az ütemezett TRIM minden disztrón alapból aktiválva van.
Lényegében egy jó SSD-t csak be kell szerelni, telepíteni rá és használni...Intenso SSD az más tészta. Annál csak a gyártás idején készült összeszerelő üzem dokumentációja tartalmazhatja, milyen komponensekből áll.
-
válasz
fekete.puma #104332 üzenetére
Igen függ a tárhely méretétől meg a végrehajtott műveletektől.
Ezt nem a user számára látható szabad tárhelyre értettem, pont itt esett szó róla a napokban. Gyakorlatilag az 1terás tárhelyen nincs szabad hely a meghajtón, de a rendszer és a programok csak félterát foglalnak el, az az SSD vezérlőjének pontosan egy féltera szabad helyet jelent, míg a usernek nullát.Egy tesztere azért kíváncsi lennék, hogy a hét végére heti TRIM esetén ez valójában mit jelent.
Ezt kb akkor tippelheted meg, ha vasárnap 23:50-kor futtatsz egy manual fstrim parancsot, no kb annyi lenne a hétfő nulla órakor lefutott ütemezett fstrim eredménye. De nem érdemes nézegetni, az SSD nem kopik, a NAND-ok elhasználódása meg olyan ütemben történik, hogy mire elfogy a TBW-ben jelzett érték, már háromszor is lecseréled a tárhelyet. Amúgy meg a TBW marketingérték, csak a garancia miatt határozza meg a gyártó. Ha írsz rá 600TB-ot, ami a standard TBW egy TLC NAND SSD-nél, akkor sem történik semmi, csak megszűnik a garancia, ha egyébként még az évben meghatározott gariidőn belül van az eszköz.itt a Samsung 860 EVO 1TB Sata SSD adatlapja és a TBW értéke:
TBW 600TB (conforms 600TB per TB capacity)
[link]Ugyanez az SSD industrial kiadásban már más TBW-vel rendelkezik, pedig ugyanaz a NAND és a controler is benne! Nyilván van plusz védelem is, de ez a NAND használatot nem különösebben befolyásolja.
1.4PB (conforms 1458.3TB per TB capacity)
[link]Ilyenkor mindig letolnak, hogy Linuxos topikban SSD-ről írok, pedig szerintem nem árt, ha mindenki ismeri a működésüket és az elhasználódásukat. Elvégre erre az eszközre telepítjük a Linuxunkat is!
-
válasz
Petya XT #104328 üzenetére
Ezek a mai FSTAB-ok tényleg nem raknak már be különböző opciókat, anno volt amelyikban a default opció volt, de egyes disztrók a discard-ot is berakták. Szerintem egyelőre ne variálj azok az Intenso SSD-n, az a biztos!
No de hogyan tűnt fel neked, hogy nem megy a TRIM?
Még régen ilyenre szerkesztettem az FSTAB-ot, de ma már rá se nézek: ez épp egy 2016-ban telepített Mint Rosa Cinnamon disztró, de mindben ugyanez az FSTAB volt
ubyegon@ubymint-rosa ~ $ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=94b359d7-74f2-4adf-ae6e-77dfc652d5cd / ext4 discard,noatime,errors=remount-ro 0 1
# swap was on /dev/sdb7 during installation
UUID=efb3da91-6ce9-4955-b6e4-1ef0cf1fe220 none swap sw 0 0
UUID=929741bd-5267-468e-bac2-673258cf3a99 /media/TORRENTEK ext4 noatime,nosuid,nodev,nofail 0 2
UUID=0b26696b-8d0d-4432-8595-9f2d49145952 /media/Data noatime,nosuid,nodev,nofail 0 2
#tmpfs to .cache
tmpfs /home/ubyegon/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0
# Modification for SSD
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
#tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
#tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
-
válasz
fekete.puma #104325 üzenetére
Ez az AI válasz használhatóbbnak tűnik!
Nyilván akkor érvényesek ezek a megállapítások, ha relatíve kevés hely van a meghajtón ill emellett kevés az overprovisioning is! Egyébként home usernek bőven elég a beállított ütemezett TRIM is a default heti ütemezéssel, de ezt is át lehet állítani napi lefutásra, ha szükséges.
Az a kérdés is felmerült anno, hogy lehet-e discard beállítva és emellett aktív ütemezett TRIM is. Persze, max ha valaki hétfőn nulla órakor épp TRIM-melteti discard-dal az SSD-t, addig nem indul el az ütemezett fstrim.
-
válasz
fekete.puma #104321 üzenetére
Folyamatos trim-nek discard esetén mi a hátránya?
Amit growler írt, csak annyit mutat, hogy az AI valóban összeszedett régi valós infókat, de normál használat esetén nincs hátrány. Említi a Samsung SSD-ket az AI, ami ezeréve valóban érintette a Samsung SSD-k néhány tipusát és még jó pár más SSD-t is. Itt az volt a gond, hogy a vezérlő sorbaállított TRIM használatakor azonnal hajtotta végre a parancsot vagy nem megfelelően priorított, így nagy és folyamatos I/O műveleteknél belassulást okozhatott a TRIM, de ezek a műveletek mondjuk videóvágás, szerkesztés és ehhez hasonló műveletek.
Anno az SSD blacklist felsorolta az érintett SSD-ket a ibata-core.c fájlban, de ebben a SSD blogban is szóba került ez a téma, ami már 10 éve íródott, ebből is látszik, hogy elég régi téma ez.
Ez a téma tökéletes bizonyítéka az AI válasz használhatóságára egyébként. Gyakorlatilag teljesen félrevezeti az egyszerű usert.
Az nem igaz, hogy az SSD ettől belassulhat, legfeljebb az adott nagy terheléssel járó I/O művelet alatt, az adatvesztés is akkor lehet érvényes, egyébként nem.
Ahogy látom, azért a biztonság kedvéért a devices that don't properly handle queued TRIM command alá felsorolnak újabb Sata Samsung eszközöket is. De ezt is leírják egyébként:
As defined, the DRAT (Deterministic Read After Trim) and RZAT * (Return Zero After Trim) flags in the ATA Command Set are * unreliable in the sense that they only define what happens if * the device successfully executed the DSM TRIM command. TRIM * is only advisory, however, and the device is free to silently * ignore all or parts of the request. * * Whitelist drives that are known to reliably return zeroes * after TRIM.
Egyszóval, aki ezt a topikot olvassa, nyugodtan használhatja FSTAB-ba szerkesztve a
discard
parancsot. -
válasz
Petya XT #104318 üzenetére
Ezeket akkor láttad gondolom, mert csak a -v az kevés! Valami cél kell neki, vagy a / vagy -a, --all, etc.
Az viszont érdekes, ha nem volt engedélyezve az fstrim.service. Default heti ütemezésű.
Egyelőre hagyd úgy, ahogy az előbb mutatta a kimeneted és az abban jelzett nap után megnézzük, lefutott-e. Intenso lévén kicsit azért bizakodni is kell, hogy működjön addig.
-
válasz
fekete.puma #104268 üzenetére
Persze ha nem csak az a fontos, hogy a reklámok legyen szűrve, hanem az adatvédelemre is ad valaki, amit sokan lesz@rnak...
Nem feltétlenül lesz@rás ez, elég ha valaki benne van a Google systemben, márpedig nagyon kevesen tudják ezt elkerülni. Igen ritka, ha valakinek nincs gmail címe, nem vásárol semmit neten, mobilnetet se használ, etc... -
válasz
fekete.puma #104263 üzenetére
Nem Flatpakozunk.
Amúgy sejtem, mi lehet a gond és az a csuda Opera böngirnyó is megnyekkenne simán.
A Zbookon elég sok acpi meg számomra ismeretlen error meg warning sorral kezdődik a bootplash plusz felraktam a rendszer által felajánlott legújabb Nvidia drivert, amivel szintén vannak gondok, emiatt nyekkent meg a FF. De nincs is szükség a gyártó driverére igazából, de addig nem akarom leszedni, míg a switchero vagy mi panelapp nem hajlandó váltani a noveau és a gyári driver között. Amit hiányol a panelapp a helyes működéshez, az mind fenn van.
Szóval lófütty fog Flatpak és társait használni meg valamilyen klón böngészőt, ami felvette egy régi super böngésző nevét.
Ne rakjak fel mindjárt XP-t én is!?
Ja és ezer év alatt amúgy semmi gond nem volt a Firefox-szal.
-
válasz
tordaitibi #104247 üzenetére
Jelenleg az idióta felesleges funkciókat gyomlálom ki belőle, ez még eltart 1-2 napig.
Megy az a W11 gyomla 1-2 perc alatt is! Zbook tanusíthatja.
De előző notinál megfogadtam a tanácsod és külön meghajtón tárolom azóta is a Dell Latitude Win11-ét.
itt van e:
A Copilot+Edge páros valami eszméletlen nagy találmány!
Még a maradék agysejt tornáztatástól is kímélni akarod magad? -
válasz
tordaitibi #104228 üzenetére
Ejj Uby eddig kb. 5 éve elvoltak az általad vegyesnek titulált partícióim.
Ja OK, akkor semmi gond.Még nem érkezett panasz
Most sem volt gond, nem is értem a nyekergés okát akkor.
Eszerint csak particiókkal volt valami és a 10milliós vegyesnépek közül Te vagy a legelső, akinél ez előugrott.
ki se merem mondni, mi van ha ezeket épp egy linux hozta létre...?
De kimondtad sajnos! Szerinted amit a Linux hozna össze, azt Linux alól akármelyik particionáló nem ismerné fel, nem tudná kezelni? Ne szórakozzunk már!Persze így, hogy nem dokumentáltad semmilyen formában, így mondhatod rá, hogy akármi meg a Linux hozta létre...
az angolom sajnos még mindig gyér.
Ha a Windowson egy qrva screenshotot se lehet csinálni... isten tenne a kopaszok közé, nem elég ez a rohadt meleg, még Te is forralod a zemberek agyvizét. -
válasz
tordaitibi #104225 üzenetére
Mi is köszönjük, ebből megint sokat tanultunk:
Volt a partícó végén 27GB nemtudommi...
No de ugye közös lónak túrós... szóval ezek a vegyes fájlrendszerű partíciókkal teletűzdelt meghajtók nem igazán szerencsések, de esetedben mintha lóval imádkoznánk... Most ilyen lós dolgok ugranak be ulláccik!
-
válasz
tordaitibi #104209 üzenetére
Fene vinné el, írtam egy féloldalt és összeomlott a FF, eltünt a sok okosság!
Mindegy, berakok két linket, nem magyarázom el újra, hogy nem a googlet kell használni, ha van topik kereső is... [link] [link]
Mutatom a valós kimenetet is: (arra érdemes készülni, hogy akár percekig is eltart a művelet és ezalatt a terminal kvázi lefagyott állapotot mutat, várni kell türelmesen)
ubyegon@LMC221-HP-ZBook-15-G5:~$ sudo fstrim -v -a
/media/ubyegon/ee1dd463-be0d-4c53-8635-344816fd308f: 58,6 GiB (62949675008 bytes) trimmed on /dev/sda1
/boot/efi: 500,5 MiB (524767232 bytes) trimmed on /dev/nvme0n1p1
/: 824,8 MiB (864813056 bytes) trimmed on /dev/nvme0n1p3
ubyegon@LMC221-HP-ZBook-15-G5:~$
Amit még hosszan ecseteltem, az annyi volt, hogy van a user, van a garbage collector és van a vezérlő, Te az első vagy, így nem neked szül az a 212GB TRIM-melt hely, hanem a vezérlőnek.
Ha érdekel a garbage collector és a vezérlő TRIM utasítása közti különbség, itt említettem, vakegér a kulcsszó.
De legalább megúsztad a szofisztikált dícséretet!
Rohadjon meg ez a Firefox....
Egyébként az SSD vezérlője ide-oda pakolássza szabadon a fájlokat, nem is lát particiót sem, szóval inkább a particionálásnál van valami gond, ami miatt nem tudsz zsugorítani.
-
válasz
fekete.puma #104183 üzenetére
Volt említve valamelyik topikban, hogy sokban függ ez a jelszókérés a telepítéskori autologin kiválasztásától. Legalábbis Linux Mint esetén, egyébként a Mint nálam autologinos, de a Debian nem, annál max utólag tudom megoldani a lightdm config szerkesztésével. Valóban az FSTAB a megoldás ezekre a meghajtó/partició automountokra.
-
válasz
tordaitibi #104181 üzenetére
Sejtettem, hogy megvicceltek az előző linkek, én is jártam már így, pedig még vágólapkezelőt se használok.
Amúgy amit írtok, az a Linux Mint-nél mindig is így működött, de például Debiannál már nem így van, ott ha másik particióra kattintok, kéri a jelszavamat.
Épp be akartam rakni a Mint és Debian screenshotját a mount parancs kimenetéről, hogy mazsolázgasson, hol vannak a különbségek...ez sajna nem sikerült, mert Debian bootot eléggé megzavarta egy utólag berakott Sata SSD sda1 particiója és azt vizsgálgattam, de aztán kiderült, hogy nem is az a meghajtó van benn, amit gondoltam, így inkább kiszedtem, mert annál már régen is voltak badsectoros trükközések.
Közben voltak még anomáliák, Debian is csak konzolból indul, egyik EFI particióval is valami gondja volt, azt töröltem, de szerintem abban talán nem is volt bejegyzés...
Mindegy, csináltam két mount kimenetet, aki tudja, megfejti, nekem kicsit sok ez így. Meg kezd meleg is lenni...
ubyegon@uby-HP-ZBook-15-G5:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=16257168k,nr_inodes=4064292,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3270720k,mode=755,inode64)
/dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=16567)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3270716k,nr_inodes=817679,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /root/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
gvfsd-fuse on /root/.cache/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
ubyegon@uby-HP-ZBook-15-G5:~$
ubyegon@Trixie:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=16283928k,nr_inodes=4070982,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3271360k,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p4 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=40,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=5614)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=16356784k,nr_inodes=1048576,inode64)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/getty@tty1.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3271356k,nr_inodes=817839,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
ubyegon@Trixie:~$
-
válasz
tordaitibi #104177 üzenetére
Tényleg az Az Ókori Egyiptom Teljes Története | DOKUMENTUMFILM utolsó bekezdésében lenne a megfejtés?
Vagy nem azt akartad linkelni?
-
válasz
Dißnäëß #104141 üzenetére
Elég nagy verzióugrások vannak Debian stable és testing között, határozottan jó a HP Zbook-on használni! Nem érzem szükségét homeuser használat mellett az nVidia gyári drivernek sem,
nouveau
teljesen jó X11-en, wayland se hiányzik.mesa 22.3.6 /stable
mesa 25.0.5-1 /testing
ubyegon@MiWiFi-R3G-srv:~$ inxi -Fxxx
System:
Host: MiWiFi-R3G-srv Kernel: 6.1.0-35-amd64 arch: x86_64 bits: 64
compiler: gcc v: 12.2.0 Desktop: Cinnamon v: 5.6.8 tk: GTK v: 3.24.38 vt: 7
dm: LightDM v: 1.26.0 Distro: Debian GNU/Linux 12 (bookworm)
ubyegon@Trixie:~$ inxi -Fxxx
System:
Host: Trixie Kernel: 6.12.27-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 14.2.0 clocksource: tsc
Desktop: Cinnamon v: 6.4.10 tk: GTK v: 3.24.49 wm: Muffin v: 6.4.1 vt: 7
dm: LightDM v: 1.32.0 Distro: Debian GNU/Linux 13 (trixie)
Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X:
loaded: modesetting unloaded: fbdev,vesa dri: nouveau gpu: nouveau
display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: eDP-1 model: AU Optronics 0x24ed res: 1920x1080 hz: 60 dpi: 142
size: 344x193mm (13.54x7.6") diag: 394mm (15.5") modes: max: 1920x1080
min: 800x600
API: OpenGL v: 4.3 Mesa 22.3.6 renderer: NV137 direct-render: Yes
Display: x11 server: X.Org v: 21.1.16 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: nouveau gpu: nouveau display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: eDP-1 model: AU Optronics 0x24ed res: mode: 1920x1080 hz: 60
scale: 100% (1) dpi: 142 size: 344x193mm (13.54x7.6") diag: 394mm (15.5")
modes: max: 1920x1080 min: 800x600
API: EGL v: 1.5 hw: drv: nvidia nouveau platforms: device: 0 drv: nouveau
device: 1 drv: swrast gbm: drv: nouveau surfaceless: drv: nouveau x11:
drv: nouveau inactive: wayland
API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 25.0.5-1 glx-v: 1.4
direct-render: yes renderer: NV137 device-ID: 10de:1cbb
-
válasz
fekete.puma #104125 üzenetére
Linux alatt mit lehet kihozni egy 4K 165-240Hz-es monitorból?
pl 4K 240Hz-en általában megy?
Fogalmam sincs, nagyon rég nem használok monitort, nem is értek hozzájuk.De ha most vennem kéne, tuti minimum 4K-sat vennék...
-
válasz
Vasti74 #104133 üzenetére
Nem is gondoltam arra, hogy olcsószart vettél, de szerintem elég jól körülírtam a pénznemszámít mentalítású vásárlást, ami sajnos együtt jár azzal, hogy nem is gondoljuk, hogy ha valami drága árfekvésű, attól még lehet akár nem megfelelő is.
De mivel egy Háború és Béke-nyi írás kelezkezett már a nyamvadt 4K monitorod miatt, gondoltam akár le is írhatnád, pontosan mi a tipusa.
Néha olyan érzésem van, hogy csak ki akarod írni magadból a frusztráltságod, ezért is javsoltam a thread legelején, hogy írj blogot. Az arra is jó lenne, hogy a 69milliárd karakter nem totál szétszórva lebegne a topikban, hanem egyben lenne az egész történet.
Szerintem vegyél most már 8K monitort, úgyse működik a 4K se, akkor meg miért ne?
Ja és arról már biztosan esett szó, hogy ha megjelenítési gondok vannak, éppen a Debian az, aminél érdemes csekkolni a codec és egyéb megjelenítéshez szükséges csomagok fennlétét.
-
válasz
tordaitibi #104119 üzenetére
Igaz nekem ezekszerint a kompromisszumkészségem kimagasló...
Agyam eldobom! Ugye most szabad ég alatt irkálsz? Már csak amiatt, nehogy rádszakadjon a menny(ezet).
-
válasz
Vasti74 #104118 üzenetére
Autós fórumon kapásból rákérdeznek az autó pontos tipusára! No szóval milyen monitorod van? Mindig csak annyit írsz, hogy 4K...
Ahogy látom pikkpakk megveszel bármilyen hardvert és sajnos SSD topikban is sok érdekes dolgot tapasztaltam évek során.
Azt meg nyilván tudjuk, hogy a Linux jóval kevésbé tolerálja a pikkpak megvett hardvereket.
-
válasz
Vasti74 #104076 üzenetére
Blocking YouTube in the FRITZ!Box parental controls
A filter kulcsszó miatt is érdemes lenne nézegetned a fenti linket.
Mivel több disztrón is ugyanazt tapasztalod, nyilvánvaló, hogy hardveres téren kell keresned a bibit. Mivel az alap routerekkel nem nagyon szokott gond lenni, de a komolyabbaknál vannak azért beállítási opciók rendesen.
-
válasz
tordaitibi #104052 üzenetére
Valami driver mentő/felrakó app volt valóban, de okkal nem bíztam ezekben.
Mindenféle szutykot használtam én is Win alatt, de aminek értelme volt az valami furanevű CD gyüjtemény volt, tele DOS meg egyéb nonWin programokkal.
De ha újrakezdeném a Windowsos időket, annyival lennék okosabb, hogy jóval hamarabb Linuxra cserélném.
-
válasz
Necronom #104046 üzenetére
Anno engem a Win7 bosszantott fel, lépésről lépésre, igaz rutinossá váltam már az újratelepítésében, de a félnapokig tartó driverek levadászása nagyon nem jött be. Nyilván az akkori használat betett a rendszernek állandóan, emiatt kellett újrahúzni, crackelt game és társai...hiába volt virusírtó, ami persze rohadtul lelassított mindent, főleg a bootidőt.
Tény, hogy ha nem szoktam volna el teljesen a Windowstól, ma már ellennék Win10-11-gyel is, de amikor nemrég elkezdte felrakni magát frissen vásárolt használtüzleti notimra és újraindulgatott, az már elég is volt nekem a jóból.
-
válasz
fekete.puma #104044 üzenetére
Félreértettél valamit, éppen a Linuxot említettem, mert aki totál nulla számtech ismerettel foglalkozik vele, az nevezheted bohóckodásnak, de ha a napi rutintól eltérő agyi tevékenység történik az már jó. A rutin a kulcsszó, mivel ha már demenssé válik valaki, akkor meg éppen nem szabad a rutintól eltéríteni.
Egy példa a Linuxos bohóckodásra, 10+ éve majd 2 év alatt sikerült végre megölnöm a Debiant, aminek pont az volt a célja, hogy ismerkedjek az alapokkal. A Cinnamon felrakása stable verzióra experimental repoból kicsit sok volt neki. Kizárólag konzolt láttam boot után és egyetlen gép volt, mobiltelefonon sem volt még netkapcsolat. Ültem és szépen jöttek elő az addig olvasottak és fejből konzolból sikerült helyreállítani a rendszert! Még egyszer mondom, nulla ismerettel indultam, amikor felraktam a Linux Mint-et és a Debiant. Előtte soha nem tanultam és első PC-mre a Win95-öt is kollégám jött el feltelepíteni.
Senki nem állította, hogy bármilyen más rutintól eltérő agyi tevékenység ne dolgozna a dementálódás ellen. Nem kell mindenben Linux-Win flame próbálkozást látni.
Remélem átment, miről beszéltem.
Csak halkan jegyzem meg, valami miatt a mindenben azt keresem, bele lehet-e kötni tevékenység nem annyira jó demencia elkerülésére.
Sőt!
-
válasz
Necronom #104041 üzenetére
De az en ket mondtom sem zarja ki egymast, meg ha egymas melle teszed sem
Tényleg nem, de gondolom észrevetted, hogy aki helperkedett a threadben, egyértelműen arra asszociált, hogy nem vagy konzol/terminal-barát.Jomagam annak orulok (mar ha ez orom), hogy jo szamtech korszakban szulettem
Azért a jó korban születés csak egy dolog, bár mindenképpen hasznos, viszont az abban a korban születettek igen kis része ment végig azon a számtech fejlődésen, amint pár szerencsés!
Nekem első gépem '98 körül lett meg, gondolom 386-os PC, az öcsém már kapott C64 meg Amiga ketyeréket, így valamelyest ismertem azokat is. Így aztán szerintem a tesóm született jó időben.Az viszont jó dolog, hogy aki jó régen született, nyomon követhette a fejlődés szakaszait, így vagy úgy. Talán az is jó részben, hogy iskolákban még semmilyen IT okítás nem volt, így autodidakta módszer maradt, márpedig amit az ember nulláról saját maga megtanul, az elég erősen megmarad és lehet rá építeni többnyire.
Egyáltalán nem baj szerintem, hogy leírtad a folyamatokat, hardvereket az őskortól kezdve, hiszen egyrészt érdekessség, nosztalgia is, másrészt ez az út vezetett sokaknak a home user Linuxozáshoz.
-
válasz
cigam #104040 üzenetére
Fene tudja, a felnőtt lakosság jelentős részét érinti ez és ugye a demencia egy gyüjtőfogalom, rengeteg fajtája van és fokozatosan jelentkezik. Ja és a közhiedelemtől eltérően nem csak a kifejezetten időseket érinti! Ami jó hír viszont, hogy aki használja az agyát rendszeresen az erősen késleltetett elérésben van. A Linuxot használókra ez eléggé érvényes szerencsére.
-
válasz
tordaitibi #104036 üzenetére
Tudod mi a borzasztó...?
Én is magamnak..!Ne foglalkozz vele, ilyen az időskori személyiségváltozás! Én is megkapom ezt elég gyakran, csak az a gond, hogy aki emlegeti, elég profi demencia szaki.
De szerintem annyira még nem lehetünk dementálódott állapotúak.
(bár inkább csak a magam nevében beszélnék)
Közben gyorsan átjöttem Debianra, no ilyen az új frissítendő csomagok listája...
-
válasz
Necronom #104034 üzenetére
Nekem soha nem volt ellenseg a terminal...
Ööö...azért volt egy rohadt erős sugallat, ami miatt azt hihette az ember, hogy a Tibik nem terminal-imádók, mer'ugye ezt is tőled olvashattuk:
"Azert GUI mert meg kezdo vagyok es a terminalozas helyett inkabb megcsinalnam grafikus feluleten a dolgokat..."
No de így még jobb, tényleg az van, hogy ha akár kezdők vagy homeuserek is egyszer kényszerből rácuppannak a terminalra, onnantól kezdve már látják, hogy nem is annyira ördögtől való az. Nekem totál laikusként az volt a szerencsém, hogy az elején felraktam egy Debiant és ott még inkább érdemes terminalozni, 10+ éve meg főleg így volt.
Sajna ma már lusta vagyok, minap is fel akartam rakni egy Debiant, hogy megnézzem az új apt csomagkezelőt, de nem a Trixie-t raktam fel, hanem a stable-t és valamit elbarkácsoltam az a stable-testing upgrade-nél, de inkább felraktam a Trixie-t, mint hogy megpróbáljam helyrepofozni a dolgot. A Trixie meg persze nem volt hajlandó frissülni, mert a sources.list üres volt, írta is a weboldal, hogy irkáld be magadnak a repokat, ha frissíteni akarsz.
Amúgy nem is bántam, mert legalább ezt se felejtem el teljesen.
No de az apt csomagkezelő tényleg kicsit ráncfelvarrottabb lett...
Most látom itt írnak is róla. Ha nem szoktam volna át a nala-ra, maradhatna az apt 3.0 is, jóval áttekinthetőbb lett valóban.
-
válasz
tordaitibi #104029 üzenetére
Kezdesz gyanússá válni!
Amit gyorsan ideskríboltál a cli parancsokról meg a parancsértelmező környezetről...
Látom azért csak készülsz szépen az öreg Ubuntud kimúlására és felvértezed magad terminalos skillekkel! Ne is próbáld tagadni, annál gyanúsabb!
-
válasz
Necronom #104020 üzenetére
Super! Ügyesek vagytok és elég kitartóak is! Ráadásul előbb-utóbb mindenki ráébred arra, hogy legtöbb esetben a CLI/terminal a legjobb út a sikerhez! Nyilván múzeumi szökevény disztróknál talán még inkább így van ez.
Ami külön szerencse, hogy megvan az áhított óra az asztalon, de legalább alig látod, az a háttér+betűszín...de most már tudod, hogyan kell kavirnyásznod terminallal a configokban!
-
válasz
Necronom #103987 üzenetére
Igazából 2 napod van 20.04-re frissíteni, utána azt is frissítened kell tovább 22.04-re. A 20.04 május 31-én lesz EOL ugyanis.
Próbálj leírásokat nézegetni, mint ez is:
How to upgrade from Ubuntu 18.04 LTS to 20.04 LTS today
Viszont így is nyűgös ez a verziófrissítés, mivel az addigi
.deb
csomagok esetén a rendszer követelni fogja a.snap
csomagokra váltást. szerintem...akkor frissitsek inkabb? akkor beken hagyhatom a kis gepem es lesz oram?
De nem akarok csuklani, szóval érdemes felkészülnöd mindenre is! Viszont lesz a jobb sarokban órád! Valahogy, valamikor...
Szerintem ugorj bele, úgyis sokan fognak segíteni, csak az a lényeg, hogy minél több és pontosabb infókat adj meg az adott helyzetről/problémáról! Tibikomám, ha felébred szolgálat után, tuti nagy segítséged lesz, rajtatok kívül nem használ már sok user 18.04-et.
-
válasz
Necronom #103981 üzenetére
Ahogy már többször is elhangzott, a 18.04-hez nem nagyon lesz már aktuális/friss app. A Pro nagyszerű dolog, de az meg csak biztonsági frissítéseket biztosít, alkalmazások csomagjai nem fognak frissülni. A böngésző is előbbi miatt frissül.
nem lehetne ezt ugy, hogy nem szedjuk darabjaira az oprenszert?
Tibikomámmal jó csapat vagytok! De nem darabjaira kéne szedni egy oprendszert, hanem repüljpáva üzemmódba rakni, mert már 8. éves! Persze ezen már túlvagy itt a topikban.hat ezt tettem fel vagy 2 eve, azota ez van...
2 éve!?Jól is tetted, akkor még csak a 6. évét taposta.
-
-
válasz
alak8 #103972 üzenetére
Ha dd-zni nem akarsz, próbáld meg a BalenaEtcher-t.
Ha semmivel nem megy, akkor előtte adj neki ezzel:
-
válasz
mcwolf79 #103966 üzenetére
Kivételesen egész jó választ adott a google AI, ha nálad valamiért nem jelenne meg, bemásolom, gondolom neked a 3. utáni rész kell. Ha BTRFS-t használsz, gondolom ismered az EXT4-től eltérő mount opciókat. Talán ez a leírás kicsit emészthetőbb,
(mindenképp nézz rá googléra, mert a bemásolt szöveg nem elég tagolt, így nagyon nem egyszerű értelmezni)
AI-alapú áttekintésTo automount a Btrfs filesystem on Linux, you need to add an entry to the /etc/fstab file. This file specifies which filesystems should be mounted at boot and with what options. First, you'll need to identify the Btrfs partition and its UUID, create a mount point, and then add the appropriate entry to /etc/fstab.
Here's a step-by-step guide:
1. Identify the Btrfs partition and its UUID: Open a terminal and run the command sudo blkid to list all block devices and their attributes, including UUIDs and file system types. Locate the Btrfs partition you want to automount and note its UUID.
2. Create a mount point: Choose a directory where you want the Btrfs filesystem to be mounted. A common location is within /mnt or /media, or even in your user's home directory.
For example, to create a mount point in /mnt, you can use: sudo mkdir /mnt/mybtrfs.3. Edit the /etc/fstab file: Open the /etc/fstab file with a text editor (e.g., sudo nano /etc/fstab). Add a new line at the end of the file with the following format:
Kód:
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/mybtrfs btrfs defaults,noatime 0 2
Replace xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx with the actual UUID of your Btrfs partition. Replace /mnt/mybtrfs with the mount point you created. btrfs specifies the filesystem type. defaults is a common option, which provides default mount options. noatime disables updating access times, which can improve performance. 0 2 specifies the dump frequency and filesystem check order. Save the changes and test: Save the /etc/fstab file. You can try mounting the filesystem manually to ensure it works: sudo mount -a or sudo mount /mnt/mybtrfs. If everything works, the Btrfs filesystem will be automatically mounted on system boot.Important Considerations: Mount Options: You can customize the mount options in /etc/fstab to suit your needs. For example, space_cache and autodefrag can be helpful for Btrfs.
Subvolumes: If your Btrfs filesystem uses subvolumes, you may need to specify the subvolume using the subvol=/@ option in fstab. User Mounts: To allow a user to mount the filesystem, you may need to add the user option in fstab. Error Handling: If you encounter issues, ensure the UUID is correct and that the filesystem is properly formatted as Btrfs.
Example with Subvolumes: If you have a subvolume named @home in your Btrfs filesystem, the fstab entry might look like this:
Kód:
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /home btrfs defaults,noatime,subvol=@home 0 2
-
válasz
Necronom #103965 üzenetére
A(z) „http://ppa.launchpad.net/ubuntuhandbook1/conkymanager2/ubuntu bionic Release” tárolónak nincs Release fájlja.
Valami itt nem kerek, mivel ebben a PPA-ban csak 20.04, 22.04 és 24.04 + a köztes verziókhoz van conkymanager2, nálad a fenti kimenet meg bionic-ról ír, ami a 18.04
A régi PPA-kban a conkymanager meg ha jól látom, a 16.04-ig tartalmazták a cm-et.
Viszonyleg sikeresen titkolod a disztród verzióját, nem lenne akár az is megoldás, hogy beraknál egy
inxi -Fxxx
kimenetetProgramkód gombbal természetesen, hogy ne folyjon szét
Kb minden kérdésed megválaszolásában rohadt nagy könnyebbség lenne!
-
válasz
csixy #103910 üzenetére
Nem tudom, csináltam-e valamit, de ahol ecceri homeuser keresné, ott nem volt semmi, viszont prtscr+Shift vagy Alt vagy Ctrl gombok kombójára meg működött. Az is lehetett gond, hogy a Dell Latitude 5520 felső gombsora totál káosz volt nekem. Zbookon még nem próbáltam, mivel a Képernyőkép app komfortosabb sokkal, alapból mentés előtt el tudom nevezni a screenshotot, kiválaszthatom hová mentse...
-
válasz
tordaitibi #103890 üzenetére
Ebből a listából én a Plasmáért vállalom a felelősséget, és most 2 órája ugye az Openboxért.
Akkor valaki még rájárt a gépedre, mondjuk a kuplungon álló szomszédasszony!
Az Ubuntu-ba már jártam, az rettenet, fönnt a panel, agyrém az egész, nekem idegen.
Ne szórakozz már, hogy fönn a panel, hát odarakod, ahová akarod.
Egyszer rámjött és Ubuntut átkutyulásztam majdnem teljesen Cinnamon kinézetűre, mondjuk bogarásznom kellett, mit hogyan, de a lényeg, hogy át lehet úgy alakítani a Gnome felületét, hogy nem ismersz rá! Régebben a Zorin is ilyesmi volt.
No épp ideje már, hogy felrakj egy Cinnamont is, ha már a Linux Mintet nem bírtad rávenni a 30 éves retro vackaiddal való együttműködésre!
-
válasz
Imi1981 #103888 üzenetére
Amúgy a linuxokat le lehet menteni ilyen pendrive-ról bootolható hasleo backup vagy acronis vagy egyébb backup programmal ?
Szerintem vannak ilyen programok bőven, sose használtam őket, max próbálgattam. Timeshift meg a Disks alkalmazás csinál mindenféle lemezképeket, Tibikomám nagy ügyködője ilyesmiknek.
-
válasz
urandom0 #103884 üzenetére
Szerintem az akkori LXDE-től nem volt elmaradva.
Hát ugye az LXDE atomegyszerű és stabil volt, gondolom a QT(Razor) GTK összekutyulással látrehozott LXQT is hasonló stabilitást mutathatott.De bocs, tényleg csak kívülről vauzok bele, mert egyiket se bírtam használni sajnos. Nem akartam háttal ülni a monitornak, hogy ne kapjak arcidegzsábát.
-
válasz
Imi1981 #103873 üzenetére
Nem vagyok nagy KDE user, de amikor néha használtam és témákat akartam felrakni, kb 5-ből 2 sikerült, jobb statisztikát nem tudok mondani, mert feladtam a további próbálkozást.
Ami meglep, hogy a Linux Mint Cinnamonnál nem találtál megfelelő témákat, skinezéseket. Ha nem is annyira harsány csilivili, mint a KDE skinezés, teljesen jól lehet alakítani azt is. Új Cinnamon kiadás esetén szokott olyan kiegészítő vagy kisalkalmazás lenni, ami pár hétig nem működik, de sok jó téma van, mondjuk én felrakok egy sötét témát, talán a PoP OS-tól lenyúltat meg transparent panelt, pár panelappot és minden tök szép.
-
válasz
tordaitibi #103860 üzenetére
Kizárt? Úgy érted, hogy hirtelen megjavult volna az eddig eléggé rottyon lévő memóriád?
Megtaláltad a kavintonyodat?
-
válasz
tordaitibi #103849 üzenetére
Ne tegyél a sírba! Nincs olyan Ubuntu, amin alapból fel vannak telepítve más DE-k is, minek is lenne? Benne vannak ezek a tárolóba és anno kíváncsiságból rákattingattál a szoftverközpontban, csak már elfelejtetted!
Sebaj, ennyi idősen már belefér.
-
válasz
tordaitibi #103842 üzenetére
Ez az egész anno 7 éve az Ubuntuval jött, én életemben nem bootoltam bele a mai napig emlékeim szerint.
Atyaég...az még rosszabb! Amúgy ha nem is emlékszel, tuti Te raktad fel anno kíváncsiságból, de akkor ez nem is LXQT, hanem még az elődje, az LXDE. Ami azért is jó, mert az meg hozzá se szagol a QT komponenseihez.
Kíváncsi lennék, mik rejtőznek még abban a csudaUbuntuban! Ha jól rémlik, nem is Kubuntu, hanem a KDE-t is felszenvedted rá...de lehet tévedek most kivételesen.
Ha nincs semmi még egy terminál se amit meg tudnék nyitni?
Hát rakj fel konzolból egy terminalt is! De látod jól tippeltem, Kapitány legalább ismeri az LXQT és azt írja, külön fel kell rakni mindent is még!
-
válasz
tordaitibi #103838 üzenetére
Jajjjjistenem! Ha külön felraksz egy pucér DE-t, az nagyon nem ugyanaz lesz, mint egy erre az ablakkezelőre felépített teljes disztró esetén!
Rakj fel ablakkezelőt is szépen meg mindent, hiába QT a KDE is, tutira nem használja a komponenseit az LXQT, ami inkább hibrid, mint tiszta QT.
...én vagyok a tordaitibi, nem tagadhatom meg önmagamat Linux vonalon, meg a Linux sem tagadja meg magát irányomban
Megint képes lennél a saját balfackodásodat a Linux hibájának beállítani!
Ja meg hogy KDE után fapados az LXQT! AZért ez remélem nem okozott nagy meglepetést.
-
válasz
Necronom #103831 üzenetére
Ezért érdemes belenézni a Baobab Lemezhasználat elemző-vel, mert látnád, melyik mappában maradt kevés hely és adott a mappán jobbgombbal meg is tudod nézni, mik vannak benne, hátha ismerősek lesznek. Külsős telepítésű programokat nekem a /opt-ba szokott rakni a rendszer, ha ezek nem kellettek és ezeket nem távolította el semmi, akkor függőségeik sem voltak, így töröltem őket. Régebbi kernelek is foglalhatnak helyet, de akár a /var-ban is sok felesleges dolog gyűlhetett össze.
-
válasz
tordaitibi #103804 üzenetére
Minden malacot látni fogsz, ha az új telepítésnél nem választod a GRUB felrakását és a napi használatos disztróra visszamenve futtatod a grub-update parancsot. Ha ezt nem teszed, tutira nem fogod látni az új malacodat! Ilyen nem lesz, hogy mindenki a saját malacát látja, GRUB-nál legalábbis tutira nem. Max annyit tehetsz, hogy az első grub-update betallózás után kilövöd az os-probe műveletét- így a későbbi kernel frissítések után már os-probe nélkül fur le a grub-update. Minden OK kell legyen...kivéve, ha el nem bacarintod.
vagy valami (ha mégsem úgy történik minden, ahogy megálmodtad, szólsz cigam kollegának és gyorsan ír egy bugreportot)
-
-
válasz
tordaitibi #103788 üzenetére
Ezek szerint nem nagyon elemezted az újmalacos példámat a 103772-ből!
-
válasz
tordaitibi #103787 üzenetére
Majd belemélyedsz a systemd-boot tanulmányozásába, ha egyre több disztrónál ez lesz a default boot manager.
Pár disztró már most is ezt használja.
-
válasz
tordaitibi #103781 üzenetére
Rengeteg opciód van egyébként, mondjuk így bele a közepébe módszer nem biztos, hogy jó lenne, de új rendszernél el lehetne kezdeni például ezzel is:
Grub vs. Systemd-boot: Which One Should You Use as the Bootloader
grub.cfg az tényleg veszett hosszú tud lenni egy idő után, anno már sok disztrohopperkedésen túl voltam és a felrakott Manjaro negyedórát szuttyogott a GRUB frissítéssel, persze elég sok initrd.image meg vmlinuz volt a különböző boot mappákban.
De amúgy lassan úgyis fel kell készülnöd a teljes megújulásra, de nem kell félni, nem fog fájni!
-
válasz
tordaitibi #103776 üzenetére
A gond ugye akkor lett amikor legyalultam őMintsége ptarícióját, grub error.
Ja hoppa, efelett elsiklottam. Ez alap user error, nem volt köze a művelethez. Az aktív(utoljára telepített) Linuxot sose töröljük, mert ugye annak a GRUB-ja aktív. Régebben jártam már így én is és nem voltam vidám. Most például a Debian felrakása után amikor átbootoltam a Linux Mint-re, ami az állandó disztróm, egyből aktiváltam is a Mint GRUB-ját, mert lehet cserélem a Debian stable-t testingre majd ha lesz kedvem, viszont ha a Debiant most letörlöm, akkor bakfitty.
ubyegon@LMC221-HP-ZBook-15-G5:~$ sudo grub-install /dev/nvme0n1
[sudo] ubyegon jelszava:
Telepítés a(z) x86_64-efi platformhoz.
A telepítés befejeződött. Nem jelentettek hibát.
-
válasz
zoltanz #103771 üzenetére
Ha az Ubuntu az utolsó telepítés és az MX-en nem történt se kernel upgrade se külön
sudo update-grub
parancsot nem alkalmaztál, akkor az MX számára az ő GRUB-jában még nem létezik az Ubuntu. Futtass egysudo update-grub
parancsot és látni fogja utána az Ubuntut is.Tibikomám style példával illusztrálva, ha egy hétig nem voltál otthon és közben a család vett egy új malacot, de nem szóltak róla, akkor addig nem fogod tudni, hogy van egy új malac, amíg meg nem rugdalod az ólajtót és ki nem szaladgál az összes! (kivéve, ha alapból kinn szaladgálnak, de ezt is csak akkor látod, ha elbattyogsz az ólig)
-
válasz
tordaitibi #103765 üzenetére
Az UEFI csodáiról meg miért értelmetlen megtanulni, hogyan működik(gyártónként és kiadásonkánt változik) mindkettőtöknek iderakom ezeket a viaskodásaimat a legelső UEFI próbálkozásomról. [link] [link] No meg a csodás UEFI bootidő is...merthogy sokak szerint gyorsabb a Legacy bootnál.
Tibikomám
Akkor mit, hova tett a Mint telepítője, mit írt felül hogy az Ubuntu eltűnt az UEFI listából és csak a Mint maradt...?
Nekem gyanús, hogy nem is írt felül semmit, csak egyszerűen a GRUB-update során az os-prober nem észlelt értékelhető OS-t a régi Ubuntud esetében. Mondanám, hogy a logokban bogarászgass, hogy mi is történt, de már nincsenek Mint logjaid. -
válasz
fekete.puma #103760 üzenetére
Teljesen más a Debian, Ubuntu, Kubuntu, Linux Mint, érdekes a csomagkezelés is mennyire más ezeknél, kivéve az Ubuntu-Kubuntut, plusz ugye mindnek más az asztali felülete. Debiannal annyira nem számít az asztali felület, mert ott az alapot kapod, nem nagyon cifrázgatják. Nekem anno sose volt gondom, amikor egymás mellé raktam több disztrót egy eszközre, főleg amikor még lehetett MBR/legacy-t választani, az EFI nyűgösebb nyilván, de nem vészes. Persze nagy könnyebbség, ha a Windows nincs a képben. De persze ha valami nem jön úgy össze, ahogy a user szeretné, nem a rendszert kell hibáztatni. Mindig user error van.
-
válasz
tordaitibi #103744 üzenetére
Ha jól emlékszek a debian a mint az ubuntu is Ubuntu az efin.
Annyira azért nem oly rég raktam be screenshotot a Debian és a Linux Mint EFI mappájáról!A swapfile már régóta készül Ubuntun is, de ugye honnan tudhatnád, 8 éve még nem így volt.
Már csak arra kéne rájönni, miért ragaszkodik makacsul ahhoz az efi partícióhoz a telepítő amit kiszemel magának.
Lehet nem fogunk rájönni, aztán valami tök egyszerű oka lehet. Például az, hogy nem véletlen női neve van minden Linux Mint-nek!A végén telerakod pirospontokkal ezt a jó kis Mint-et.
De úgy látom utólag egész jó tippeket kapsz...kár, hogy már nincs meg a Mint-ed.
-
válasz
tordaitibi #103741 üzenetére
Az lehet a bibi, amit az imént berakott screenshotomon is láthatsz! A Mint EFI is Ubuntu néven szerepel, így szépen beugrottak a bejegyzések a régi Ubuntud EFI-jébe!
Tudom, hogy nem örülsz ennek, de most már mindegy...
-
-
válasz
tordaitibi #103734 üzenetére
Azért azt már az elején többen leírtuk, hogy 0% esélye van egy Mint 22 működésének, ha rátukmálod az Ubuntu 18.04 /home-ját. Új telepítésű Ubuntu 18.04-re működhetne, de mint mondtam, az ezeréves fura programjaid attól még nem kerülnek fel, max a configjaik.
Azokat külön felrakni meg igen óvatosan kéne, ügyelve, hogy a régi configok maradjanak meg.
-
válasz
cigam #103729 üzenetére
„Ez a Mint éppen olyan jó, éppen azt teszi, amit kell…"
No végre, egyet tudok veled érteni teljesen. Nyilván egyéni óhajokat még nem teljesít, mint ami neked volt nemrég, hogy találja ki helyetted, melyik particióra szeretnéd a telepítést, hanem galád módon a particionáló részre akart továbbküldeni!Pedig milyen jó lenne, ha 15 partició megléte esetén nem két csempét ajánlana fel, hanem 15 darabot, ha már nem találja ki a gondolatodat.
Tibikomám,
sajnos a Debian se vette figyelembe a kijelölt másik EFI particiót, de ahogy láttam, mindkettőt aktívnak jelöltem, viszont talán inaktiválni kellett volna az első EFI boot flagjeit, azt meg nem akartam, mert akkor fene tudja, mi lenne a Linux Mint meg a többi EFI bejegyzésekkel. Igaz nem is nagyon foglalkoztam most a telepítéssel, itt hagytam a nyuszira, pár Tovább katt kellett neki osztjónapot. Azért az fura lenne, ha magától eltüntetné az Ubuntud bejegyzését, de persze ha ügyes voltál, akkor sikerült.Itt megvan még a Linux Mint EFI mappája szépen, igaz Ubuntu néven.
-
válasz
tordaitibi #103719 üzenetére
Atyaég! Nekem elég kínai, amiket írsz, de az EFI mappa megadása kéne, hogy működjön, nyilván duplakatt és elfogadás, de amikor a végrahajtás gombra kattintasz, akkor ott egy kisablak felugrik és ha nem jó, akkor vissza kell menned és addig próbálkozni, amíg nem lesz OK. Nagyon rég csináltam már, de mindig működött.
Ami még megdöbbentőbb nekem, hogy miért nem ugyanekkor, az install particionáló részében jelölöd neki a /home particiót? A felülírásra írtam is, hogy teljesen nem fogja engedni felülírni.
Mindjárt le is csekkolom ezt a külön EFI-be boot erőltetést...bár mondjuk ez Debian lesz, de működnie kéne mindenütt.
Megint olyan érzésem van, hogy amit pár kattintással el lehetne intézni, azt jól megbonyolítod.
Ha a rendszer nem azt csinálja, amit szeretnél, az mindig user error. Sajnálom, hogy megint ez kell mondjam, de ez van!
cigam kolléga mindjárt be is egerészik ide egy ezzel kapcsolatos szarkasztikus megjegyzést.
#/boot/efi was on /dev/sda1 during installation
Ez egyébként csak tájékoztat is téged, hogy a telepítés során a boot/efi az sda1-en volt. És ennek nem örülsz, ha jól sejtem.
Az a Mappa FSTAB-ba csatolás még nekem se ismerős túlzottan, ill sose próbáltam.
Egyébként ez a meglévő másik EFI installkor történő kijelölése nem sokban különbözik az itt leírtaktól.
-
válasz
cigam #103714 üzenetére
Köszi, amúgy nagyjából értelmezem én, mit akarnak ezekkel a sorokkal, csak a jelölések nem mind tiszták. Persze logikailag kicsit érdekes, mint írod is, egyeznie kell meg az -image- után is egyértelmű, milyen szám/betűkombóról lenne szó.
De ugye az autoremove egy jövőben bekövetkező művelet... Érted, mi a fura ebben!
-
válasz
tordaitibi #103710 üzenetére
No szépen vagyunk! Tegnap még az volt, hogy ha kell menjek érte!
-
válasz
cigam #103697 üzenetére
Ha az íjra hasonlító jel
};
definiálására gondolsz, azt Kezdő topikban simán megértik, szóval ismerkedjen a viziragya reguláris kifejezésekkel! Még Haladó Linux vagy Shell topikban OK, ha ilyen kívánalom merül fel, de itt marhabaromságnak tűnik!De ha már ennyire szeretnéd látni a szabatos kifejezést, leírhattad volna mi a neve a nyíl jelnek!
-
-
válasz
csixy #103690 üzenetére
Biztosan nem akarod bepróbálni? Én a configok nagy részét csodálattal adózva szoktam érintetlenül hagyni, főleg amikbe ilyen íj formájú karakterek vannak.
Viszont ebben az apt.conf.d fájlban a
NeverAutoRemove
résznél lehetne operatívkodni, max kihúzza a rendszer alól az összes kernelt, de ha így lesz, kicsit polírozod a recovery skilledet, no mondd már...APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
};
VersionedKernelPackages
{
# kernels
"linux-.*";
"kfreebsd-.*";
"gnumach-.*";
# (out-of-tree) modules
".*-modules";
".*-kernel";
};
-
válasz
zoltanz #103678 üzenetére
No várjál, most az van, hogy bezártad magad a 4 elsődleges particiók elhasználásával? Az akkor bakfitty, ha nem törölsz egyet legalább, amiből extended particiót csinálnál és azt már sok logikai particióra lehetne osztani! Sajnos kevés dolog van, amit utólag nem lehet javítani, csak baltával, fűrésszel és az egyik a 4 elsődleges partició elhasználása. Akkor igen bosszantó ez, ha a meghajtó fele még ott vigyorog üresen.
Ha viszont még megvan a 4. particiód, akkor miért ne csinálnál extended-et? Az abból készített logikai partició is teljesértékű.
-
válasz
tordaitibi #103685 üzenetére
Szegény zoltanz kollegára jól ráküldenél az MBR miatt! Csak ugye ha Windows is képben van, akkor azzal csak egyféleképpen tudok operatívkodni, de a kolléga nem szeretné, ha nyomtalanul eliminálódna az a jó kis Windows a gépéről!
Nem akarlak felzaklatni, de az MBR logikai particiói alkalmazás szempontjából ugyanolyanok, mint az elsődleges particiók! Ezeréve sok partíció volt a meghajtóimon és ezek javarészt logikaiak voltak. Úgy futott rajtuk minden OS, mint a nyúl!
-
válasz
csixy #103679 üzenetére
Azért azt látod, hogy ez nem a csomagkezelő/frissítéskezelő által felrakott kernel volt? Szerintem a generic verziókat rakja fel a csomagkezelő, nem a hwe-ket. Nálam alapból csak 6.8-as kernelekkel operál a rendszer(nem én, hanem a rendszer!). Szóval akkor újra, ha nem a rendszer saját csomagkezelője frissíti a kerneleket, hanem belenyulsz, akkor amit nem a rendszer ajánlott upgrade-re, azoka nem is fogja leszedni az autoremove.
Épp javasolni akartam, hogy kezdd el bogarászni ezeket pihenésképpen...
Nálam is ott vannak a 6.11-es kernelek, de a rendszer azokat nem piszkálta, csak a 6.8-asokat. Nyilván Te innen manuálisan kattingattál rájuk.
-
válasz
csixy #103676 üzenetére
Az érdekes, mert a nala configban is van kernel eltávolítással kapcsolatos beállítás. Nálad ez már volt nemrég, valami kutyulást sejtek...akkor az volt, hogy az autoremove se szedte le őket. Ezek hivatalos tárolóban lévő kernelek, gondolom és nem külön raktad fel őket.
Mi van, ha a fenti screenshothoz hasonlóan minden bejelölést visszavonsz és úgy futtatod a nala-?
Új hozzászólás Aktív témák
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Autós topik
- Yettel topik
- Azonnali alaplapos kérdések órája
- CMF Phone 2 Pro - a százezer forintos kérdés
- EAFC 25
- Napelem
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Apple asztali gépek
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- További aktív témák...
- BESZÁMÍTÁS! Asus TUF B365M i7 9700F 16GB DDR4 512GB SSD RTX 3060Ti 8GB Rampage SHIVA Zalman 600W
- BESZÁMÍTÁS! HP ZBook 15 G6 munkaállomás - i7 9850H 16GB DDR4 RAM 512GB SSD Quadro T2000 4GB WIN10
- 126 - Lenovo Legion Pro 7 (16IRX8H) - Intel Core i9-13900HX, RTX 4080 (ELKELT)
- AKCIÓ! Gigabyte H610M i5 13600K 16GB DDR4 512GB SSD RTX 3060Ti 8GB Zalman S2 TG Seasonic 650W
- ÁRGARANCIA! Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged