-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
samujózsi
senior tag
válasz
Frawly
#29632
üzenetére
De mint azt két alkalommal említettem, maradnék a gnome környezetben. És ezzel a megkötéssel elég szűkösek a lehetőségeim.
A másik probléma, hogy amelyik wm olyan, hogy fel tudja osztani a képernyőt, az tudtommal ezzel egyidejűleg nem teszi lehetővé, hogy a maradék területen hagyományosnak nevezhető ablakozás működjön. Számomra az lenne a poén, hogy az egyik oldalon egy eltakarhatatlan böngésző, a másikon meg terminal, IDE stb.
Régebben (bár lehet, hogy az windows volt) volt rá lehetőség, hogy egyes ablakokat megjelöljünk, hogy azt a többi ne tudja eltakarni, de ez mára a legtöbb helyről kihalt vagy csak én nem találom.
-
bucihost
senior tag
válasz
Frawly
#29606
üzenetére
Látom a lényegi részét nem sikerült elcsípned... Szerinted az EPR gyártók nem fejlesztettek semmit 22 év alatt? Vagy épp a cég nem faragta / faragtatta a saját igényei szerint az adott rendszert?
Mi a gond a belakással? Szerinted 2-3 évente EPR fejlesztő cégeket kellene cserélni? Vagy mi?
Mondj már nekem egy hazai céget, akinek 98'tól linux alapú EPR-t dobott a piacra, ami tudja az alább felsoroltakat mindegyikét egy cég számára.Logisztika, Raktározás, szerződéskezelés, beszerzés, értékesítés, e-kereskedelem, CRM, Pénzügy, Könyvelés, Gyártás-termelés és még sorolhatnám....
-
bucihost
senior tag
válasz
Frawly
#29604
üzenetére
Senki nem mondta, hogy nincs linuxos alternatíva. Az alap "vita" abból robbant ki, hogy miért olyan elvetemültek a cégek, hogy windowst használnak. Erre reagáltam, hogy a cégek nagy része akik a felsorolt dolgokat használják( kisker, nagyker, gyártócégek) 99%ban windowsoznak, mivel az EPR rendszerek (pl visionsoft, jutasoft, és még sorolhatnám a hazai nagyokat) Mind windowsra íródtak. És igen, lehet rá linuxos alternatíva, de pl egy 98' óta win rendszeren futó komplett kereskedelmi rendszert / adatbázist nem túl egyszerű és és kifizetődő átcuccolni egy másik akár linuxos rendszerre, egy már belakott jól működő windowsosról. részemről ennyi volt a reakció
-
bucihost
senior tag
válasz
Frawly
#29575
üzenetére
Maximum csak nagyon elméleti esetben tudom elkézelni, mondjuk egy dizájnstúdiónál, hogy tényleg valami olyan szoftvert használnak, ami csak Windowsra elérhető, semmi másra, és más rendszer alá sem tudnak saját megoldást íratni, mert annyira komplex, hogy a fejlesztést nem tudná a cég fizetni, nem éri meg neki. Ilyen esetben adott valóban mit használjanak, de ez az összes cégnek kb. <1%-át teszi ki, ahol indokoltan használnak azt, amit használnak. A SAP nem ilyen.
Csak 1%? A vállalat irányítási rendszerek, kasszarendszerek, logisztikai, számlázó stb rendszerek 99%-ban only windows...
-
I02S3F
addikt
válasz
Frawly
#29561
üzenetére
"valami házilag összegányoltatott ezer éves disztrón ragadnak be, pl. Ubuntu 10.04, Debian 6, frissíteni meg megint nem frissítenek, mert valami ósdi, legacy gányolásuk eltörne a frissebb verziókban." - Ha jól emlékszem Torvalds erről beszélt, hogy ez a Linux hátránya. Emlékeim szerint fregmentációnak hívta a problémát.
-
felora:)
tag
válasz
Frawly
#29555
üzenetére
megtenném, de olyan szinten be van állva, hogy a kurzor elmozdítása is nagy erőfeszítésbe tellik neki, így nem tudok mit tenni, de ilyesmi hibára tippelek én is. A gépben 2 gb memória van amúgy, lenovo g50-30 ocsógép.
(#29554) samujózsi
Ha a hiba jelentés gombot megnyomom elküldi a hibát és az ablak bezárul. Semmi + infot nem ad ki... :/ -
haddent
addikt
-
inf3rno
nagyúr
válasz
Frawly
#29540
üzenetére
Itt helyben is Windows és SAP van az egyik nagy cégnél, a helyi informatikus gárdát meg teljesen leépítették. Nem értem személy szerint, hogy minek az SAP, amikor a régi ügyviteli rendszer is működött, amit az itteni informatikusok heggesztettek össze, és irdatlan összegeket költöttek az átállásra. Nem látom értelmét az outsourcing-nak, de biztosan működik, ha ennyi cég csinálja...
-
válasz
Frawly
#29520
üzenetére
Nem, és még mindig nem érted. Saját céged rendszerének azt használsz, amit akarsz, ellenben ha alkalmazott vagy, akkor nem a saját preferenciádnak megfelelő rendszert fogod használni, hanem a munkaadódét.
Az IT nem dept. arra van, hogy az alaprendszert mókolgassa, hogy működjön, hanem arra, hogy a cég alkalmazásai fussanak, mert azok termelik a bevételt. Ebben az esetben viszont csak az kerülhet szóba, amire van 24/7 support.
-
válasz
Frawly
#29502
üzenetére
Még mindig nem érted. Rolling eleve szóba sem jöhet cégnél - nincs megfelelő tesztelés, nincs céges support. Arch-nál évente többször előfordul, hogy frissítés miatt ledöglik a rendszer. Ez olyan kockázat, amit cégek nem engedhetnek meg maguknak. Cégeknek kitesztelt, 24/7-es támogatású rendszerek kellenek, amik mögött ott az ügyfélszolgálat. Ráadásul az ilyen supportba gyakran beletartoznak az egyedi patchek is.
Otthon nyugodtan dobhat hátast a hobbi rendszered, de ha egy cég bizonyos profittermelő rendszereivel történik ez, akkor a tulajok tajtékozni fognak és valaki(k) meg fogja(ák) ütni a bokáját(jukat). Első körben az informatikai vezető, aki engedte az instabil rendszer használatát, másodikban az admin, aki early adopterként feltette a galibát okozó frissítést.
-
samujózsi
senior tag
válasz
Frawly
#29502
üzenetére
Például olyan, mint a java licenc változása?
Vagy pusztán a tény, hogy kevésbé van lehetőség összehangolni a különböző csomagokat egy folyamatosan változó, egyre újabb verziókat összeszedő rendszeren, mint egy olyanon, amit összeraktak adott verziókkal és később csak hibajavítások jönnek rá, új funkciók, új főverziók nem annyira. -
válasz
Frawly
#29486
üzenetére
Bármi ami rolling vállati környezetbe teljesen alkalmatlan. Valami kétes licensz-el rendelkező dolog bekerül akkor az tud rohadt nagy gondokat okozni. Kritikus szerver az Redhat vagy nem open Suse.
haddent: ráadásul most már a leap opensuse az konkrétan az SLES alapján megy, a .x verziók a service packek. Szóval konkrétan ki lett tolva a támogatási idő.
-
haddent
addikt
válasz
Frawly
#29486
üzenetére
Tudom ez (akartam) írtam én is kb. Utolsó részt annyival egészíteném ki, hogy itthon tök szívesen hegesztek bármit, mert jó érzés, szeretem, sikerül is meg tényleg minimál, friss, jó. De munkában biztos nem fogok nekiállni. Száz milliókat fizetünk vasért, milliókat supportért. Felrakom, menjen. Ha nem akkor kiverem a hisztit, hogy 2 órán belül azonnal bugfix, mert nem fejlesztésért fizetnek, nem végzem el helyettük a munkájukat mert se időm se kedvem ilyen keretek közt productionben nem saját cuccon. Tehát teljesen jó ez úgy ahogy van, mindennek megvan a saját helye
-
Dißnäëß
nagyúr
válasz
Frawly
#29357
üzenetére
A stream nálunk is megy, torrenten viszont már nem vagyok, valahogy elmúlt az a korszak. Mármint regisztrálós oldalra gondolok.
Régi dal az oda-vissza másolás, bár én még sosem éltem vele, mindig programmal defrag-oltam. Most viszont nagyon jól jön, hogy csak szekvenciálisan kvázi nagyobb fejleszakító seek nélkül ír ki a cél HDD mindent. Gyorsabb is, mert a rengeteg seek idő rengeteg apró olyan idő, amikor épp semmi nem történik, csak várunk, hogy a fej A-ból B-be érjen.
Szóval összességében egy 4 terás, majdnem csurig HDD-t klasszisokkal egyszerűbb úgy defragmentálni, hogy átmásolom egy másik 4 terásra, majd vagy otthagyom, vagy vissza.
Persze ez fájl szinten él, ha nekem spéci dolgaim vannak, spéci rejtett blokkok, amikre szüksége van bárminek is, blokk szintű átvitel kell (pl. dd). De nekem csak fájlokat kell most mozgatnom hálistennek.
Az más, hogy csak ilyenre luxus tartani +1 üres másik 4 terásat. Szóval csak úgy mindennap egy ilyen nem kivitelezhető kényelmesen.
-
Dißnäëß
nagyúr
válasz
Frawly
#29354
üzenetére
Kezdesz Te is már vénülni, jössz le a szerről, a sok torrentről meg marhaságról ..
Az urandom amúgy úgy van, ahogy mondod. Gyorsabb, mint a sima random, de annyira nem, hogy nálam a HDD-t kimaxolja, mondom, ilyen 60 Mb/s körülre állt be urandom-os DD-zés egy Ryzen 5 3600-ason (1 szálat 100%-ra pörgetve). Az nem valami rakéta
főleg ekkora HDD-knél. Sebességben pedig kicsivel a gyakorlati 150Mb/s szekvenciális harmada körül-felett és 1M blokkmérettel dolgoztam már, kevesebb overhead-hez. (bs=1M)Más:
rsync-elek éppen "A" HDD-ről "B"-re, úgy hagytam a gépet reggel. Egy cp-s paranccsal szemben ennek a fájlmásolásnak csak a metódusa más (nyilván sokkal több extrát is tud az rsync), de megőrzöm azt az előnyt rsync-el is, mint cp-nél, hogy a fragmentációt nem hozom át, igaz ?
A régi 4 terásom 3.7-ig be van telve, őrült sok adat és marha fragmentált már, nálam Windows automatikus defrag ki van kapcsolva tudatosan. Nem mintha a bekapcsolt sokat segítene, sőt, inkább rizikózok, hogy kinyírja a HDD-t idő előtt.
Most, hogy NAS-ba teszem, célom átmásolni mindent az újra, amire gyorsan kreáltam egy btrfs-t és most is épp csorognak át az adatok. Amit hallok az az, hogy az újnak nincs hangja, a régi pedig néha seek-elget, néha darálgat kicsit egyet, mikor hogy ugye.
Feltételezem, a régi fájlrendszer töredezettségét az átmásolással az újban megúszom, így van ?
(Ha blokkonként, dd-vel másoltam volna a régit az újra, akkor vitte volna magával a töredezettséget is - annak nem láttam értelmét).
-
samujózsi
senior tag
válasz
Frawly
#29347
üzenetére
A /dev/random szokott döglassú lenni, különösen, ha nem áll rendelkezésére... entropy magyar megfelelőjét nem tudom, de az szokott nullázódni/kiürülni.
Ez elvileg valódi véletlenszámot generál.
Az urandom alapvetően gyorsabb, de pszeudovéletlen, titkosítással kapcsolatos műveletekhez nem javasolt a használata. -
Dißnäëß
nagyúr
válasz
Frawly
#29343
üzenetére
- /dev/zero sebessége a diszk maximuma, esetemben fejpozíciótól függően átlagosan 150Mb/sec.
- /dev/urandom CPU mag 1 szál sebesség függő, nálam úgy 59Mb/sec
- szintén diszk maximumot tudsz randommal teleírva elérni HD Sentinel-el... (Windows alól)...
- és Linux alól úgy, hogy egy cryptsetup luksFormat-al leformázod, titkosított kötetté kvázi, ami tökrandom mintával tölti fel az egész lemezt, a végén pedig le-dd-zed a headert, vagy ha biztosra akarsz menni, 1mp alatt bele-urandomolsz dd-vel az elejébe, pár megába, és jónapot, eladható, randomizáltan, linux alól, diszk max sebességen végrehajtva.
-
samujózsi
senior tag
válasz
Frawly
#29343
üzenetére
Ha ott a header és teszem azt az a jelszó, hogy abcd, azt viszonylag könnyű kitalálni, ha kellőképp lelkes az "új tulaj", még hozzá is férhet a lopott diszk adataihoz.
Header nélkül cseszheti, mert nincs meg a kódoláshoz használt kulcs, ami nagyon nem azonos a jelszóval.
Ezt nem vagy képres megérteni.
Secure erase-t meg úgy tudom, egyébként sem támogat minden+ vannak hiányosságai stb. -
Dißnäëß
nagyúr
válasz
Frawly
#29328
üzenetére
Jelszó az USB stick-nek, mivel az is titkosított, GRUB Luks1-es formátumig jó. Ennek kézi jelszavas feloldását követően válik elérhetővé az a kulcs, vagy azok a kulcsok, amik feloldják a többi, Luks2-es HDD-t. Semmi extra. A többit pedig elküldöm kellően okos módon a protonmail-emre, egy veracrypt konténer fájlba téve, zip-elve, meg elrejtem még itt-ott a nagy világhálón, ha az életem akarna múlni rajta.
Így mindkettő teljesül, kellően random és nagy kulcs is a tényleges drive-ok feloldásához, meg a kényelem is és az 1 darab jó erős jelszó, ami lehet Biblia idézet, Wales-i bárdok, vagy női nemi szerv, bármi, amit akarunk
Nyilván semmi ilyen durva cucca nincs senkinek kb, csak elméletben beszélgetni érdekes ezekről.. ennyi "szenvedést" az egész nem ér egyébként, valóban.
-
samujózsi
senior tag
válasz
Frawly
#29330
üzenetére
Bocs, de ez már a ROTFL kategória.
B+, te nem gyalulod le a diszket, mielőtt akár géppel együtt, akár gép nélkül eladod???
Ahány diszket eddig eladtam, azt mindet vagy a /dev/zero vagy újabban a /dev/urand-ból vett "adattal" felülírtam, pont úgy, ahogy írod, a 0.-tól az utolsó bájtig.
Szerinted mégis mit kéne vele csinálni, hogy valami recovery szoftverrel ne tudja a kedves vásárló visszaszedni a diszkemen tárolt adatokat?A srác kérdésének megfelelő kialakítás az pont olyan (feltéve, hogy a LUKS/md-crypt nem hagy spéci ujjlenyomatot - ezt nem tartom lehetetlennek), mintha random adatokkal teleírtad volna a diszked, mivel header nincs rajta.
Az úgy tényleg csak random adat egyébként, pont azért, amit korábban már említettem: a kódoláshoz/dekódoláshoz szükséges kulcs header híján nincs a lemezen, azt meg a mai eszközökkel még reménytelennek tűnik feltörni. -
samujózsi
senior tag
válasz
Frawly
#29328
üzenetére
Újra megkérdezem: miből jön rá, azon túl, hogy ő a tolvaj és épp szedi ki a gépből?
Ha odaadja egy vadidegennek, az miből fogja az tudni, hogy értelmes infó van rajta, és nem egy eladásra előkészített, random adatokkal felülírt diszket lát? És ugye nem a dekódoláshoz használt kulcsot kell visszafejteni, hanem a user saját jelszavát, amivel a saját key slot-ját nyitja. Ami egy fokkal egyszerűbb, ha gyenge jelszót használ az ember. (hanyagoljuk, hogy nem használ gyenge jelszót, nem erről szól a történet)
-
-
Dißnäëß
nagyúr
válasz
Frawly
#29310
üzenetére
Az utóbbira van szükségem és ember meg nem mondja a random adatból, hogy mi van rajta, utána. Még egy eneszéj sem. Nem mintha nagyon paráznék bármitől, csak ha betörés lenne, akármi, és viszik a motyót, vigyék.
Van még 1-2 plussz módszer amúgyis, amivel aztán még ezt is lehet fokozni, de az már abszolút overkill. Lehet ez is. De ez még vállalható overkill
Arch passz, de rolling release ha jól tudom, a bug-okat nem szeretem.
Debian meg itt-ott kicsit poros, legalábbis a stable, de legalább beton.
Na, így a két véglet után elmondható, hogy egy Debian Testing-el az arany középutat járom
(Kb. Ubuntu szint, mert Ubuntu is testing-re alapul). Nekem bevált. De ez itt már off. -
samujózsi
senior tag
válasz
Frawly
#29302
üzenetére
Ezt csak azért kérdeztem, mert olyan határozottan állítottad, hogy nem lehet ütközés, KÜLÖNÖSEN mert luks-t használok.
Namost az a gond, hogy az LVM-nek van egy katalógusa/adatbázisa/nevezdaminekakarod, ahol tárolja a metaadatokat, köztük a neveket is. Nem fog kerülőutat csinálni csak azért, hogy UUID alapján elérhető legyen. Illetve elvben igen, mert a vg parancsoknak van egy --select kapcsolója, ahol a vg_uuid=<UUID> segítségével lehet hivatkozni a megfelelő vg-re, de így nem lehet mountolni az eddig talált infók alapján.
Az egyetlen workaround, hogy vgrename <UUID> <új név, ami eltér a meglévőktől>, majd egy vgscan -ay, ha igaz (-ay nem biztos), utána már ott lesz a /dev alatt az <új név>, így már mountolható.
Csak ahogy írtam, akkor van gáz, ha a külső diszk R/O...ui: itthon nem, munkahelyen azért előfordul...
-
samujózsi
senior tag
válasz
Frawly
#29300
üzenetére
Ö... láttál már LVM-et? Tisztában vagy vele, hogy működik?
VAN ütközés. A külső diszk nem elérhető UUID alapján sem, amíg át nem nevezem.
(ez most rajtam segít, de ha véletlenül egy read-only médián van, mert archivum... hát az nagy szopás lenne)Az meg külön izgalmas, hogy miután megpróbáltam megszabadulni az átnevezett VG darabjaitól, telefosta a konzolt hibákkal a pvscan, vgscan, lvscan...
-
samujózsi
senior tag
válasz
Frawly
#29274
üzenetére
Meg azon, hogy ne a partíció nevét adja meg eszköznév helyett.
Egyébként van két házam, ami belül SATA csatis, meg két vagy három gyárilag összerakott USB-s külső diszkem, még nem találtam olyat, amelyik a
smartctl -d sat ...
vagy a
smartctl -d scsi ...
parancsra ne reagált volna az elvárásoknak megfelelően. -
samujózsi
senior tag
válasz
Frawly
#29258
üzenetére
Ez ennél sokkal bonyolultabb. Sajnos.
Van kb. 100-150 olyan fájlom, aminek a nevében van spec. karakter, többségük olyan, hogy zárójelek közt egy szám. Például a CD gyűjteményem mp3-ba konvertálva, a könyvtárakban az albumborító is ott van JPEG-ben. Ezek közt is van néhány, ami zárójelet tartalmaz. Ezeken mégsem akad fenn a másolás.
Ugyanakkor kimásoltam az egyik DCIM/Camera könyvtárból a *(0).jpg fájlokat egy külön könyvtárba (ezeket egyébként az androidos képszerkesztőm hozza létre). Ettől kezdve az eredeti könyvtár használhatóvá vált, viszont az új könyvtár, amiben mindössze 15-20 ilyen fájl volt, már nem igazán volt másolható, listázható.
Szóval nem értem.
Majd még kísérletezek vele. Annyi biztos, hogy nálam segített, hogy a DCIM alól kiirtottam a zárójeleket. -
samujózsi
senior tag
válasz
Frawly
#29254
üzenetére
A poén, hogy androidból hozzáférek.
adb shell alól már csak a kártyához, a belső tárhelyen tárolt képekhez nem.
Valami miatt ahol nagyon sok fájl van, ott az mtp kapcsolat döglődni kezd.
Persze ez lehet akár linuxos mtp driver bug is, mindenesetre elég rendesen teleszemetelte az androidos logot, amikor másolni próbáltam, épp csak semmi érdemi üzenetet (olyat, amit értelmezni is tudnék) nem rakott közéjük.
A virtuális gép meg szép és jó, épp csak kvm-ben fogalmam sincs, hogy tudnám átadni az USB portot, virtualbox meg nem tűnik járhatónak, mert securebootos a gépem és ahhoz aláírt kernel modulok kellenek, legutóbb emiatt nem ment virtualbox-ból sem az USB átadása.
Szóval nem egyszerű.
Most fut egy adb backup, majd meglátom, mire megyek vele.
Arra nem jó, amire nekem kell, márcsak azért sem, mert nem tud inkrementális backupot, ha jól látom. -
samujózsi
senior tag
válasz
Frawly
#29251
üzenetére
Miután látom a tartalmát... igen, biztos, hogy ide van mountolva.
Nem rá, hanem róla szeretnék másolni (backup, de az adb nem jó)
Nem egy DCIM mappáról van szó, hanem többről.
Az egyik a mobil belső tárolóján van, a másik ugyanott, csak más néven, a régi mobilról, meg egy harmadik is az SD kártyán. Ami különlegességük van ezeknek a könyvtáraknak, hogy sokkal több fájl van bennük, mint a többiben.És legutóbb (ma még nem próbáltam) a gnome fájlkezelőjével simán tudtam másolni a mobil tartalmát...
-
samujózsi
senior tag
válasz
Frawly
#29230
üzenetére
A /proc/cmdline ebben az esetben nem ér semmit, hiszen pont az lenne a lényeg, hogy az efi mit lát abból, amit én odaadtam neki.
Többé-kevésbé a /sys/firmware/efi/efivars (emlékezetből írom, de remélem, pontosan) alól ki lehet bányászni, de ez nem igazán korrekt, csak a normális megoldást nem találom.
Az efibootmgr -v nem ír ki minden paramétert, épp ezért kérdeztem. -
-
inf3rno
nagyúr
válasz
Frawly
#29222
üzenetére
Nem hiszem. Mármint nekem úgy tűnt, hogy a GRUB csak annyit tesz, hogy átadja a paramétereket a kernelnek. A lényegi munkát a kernel végzi ezzel kapcsolatban. Legalábbis ez jött le abból a pár sorból, amit elolvastam a témában, meg ha belegondolsz a soros portos driverek vagy mi a szösz is a kernelben van, nem a GRUB-ban... Nem is vagyok benne biztos, hogy beleférne a GRUB-ba, de mióta bejött a GPT meg az EFI már nehezen követem, hogy mi hány MB lehet. Valami olyasmi rémlik, hogy MBR-el és BIOS-al elég kötött volt a bootloader mérete és valahol a lemez elején kapott helyet valami olyan helyen, amit elvileg nem is erre találtak ki. Mióta bejött a GPT talán már nincs ilyen megkötés, passz.
-
Frawly
veterán
válasz
Frawly
#29216
üzenetére
Még annyit, hogy úgy tűnhet, hogy az Ubuntut, Mintet, Manjaro-t ekézem, de nem állt szándékomban. Teljesen megértem, hogy miért használnak ezek a disztrók bloatabb, de általánosabb megoldásokat. Pl. GRUB, initramfs, systemd, full extrás DE. Ezek sokfélébb használathoz passzolnak, és sokkal problémamentesebben lehet belőlük hülyebiztosabb megoldásokat gyártani. Hiszen ezen disztrók célközönsége sokkal szélesebb, a mainstreamebb, laikusabb emberkéket szolgálják ki, inkább a kezdőket, és nekik jobb egy olyan általános megoldás, ami teljes körű szolgáltatást nyújt, lefedve mindenféle felhasználási kört, kevesebbféle szituban mond csődöt, cserébe bloat lesz. Ezen disztróknál ez kényszerpálya, nem hibáztatom a disztrókészítőket ezen döntéseikért, teljesen logikus lépés tőlük. Sokkal hülyebiztosabbnak kell lenniük, sokkal univerzálisabbnak. Ha ezt nem teszik, akkor a laikus azonnal úgy érzékeli, hogy xaralinux, meg esse-asse-megyen rajta, és pattintják is vissza a Nyílászárókat. Tehát ezen kezdőbarát disztrók felelőssége sokkal nagyobb, hogy ne taszítsák el a kezdőt, ne szolgáltassanak kudarcélményt, hanem hatékonyan népszerűsítsék a Linuxot.
De van egy olyan pont, amikor ez a túlzott univerzalitás, meg bloatság már egy tudásszint felett felesleges, mint a segédkerekek a biciklire, ergó el kell őket hagyni. Így ha az ember tudja konkrétan, hogy mire van szüksége, akkor csak kizárólag azokból jobb egy egyéni személyre szabott sovány, minimalista rendszert csinálni, sokkal pattogósabb, erőforrás-kímélőbb, sallangmentesebb lesz. Meg szakmailag is nagyobb sikerélmény, és tanulási lehetőség. Mert mennyivel jobb az a rendszer, aminek minden elemében az ember saját maga dönt, nem döntik el helyette, a rendszer minden eleméről pontosan tudja, hogy micsoda, mihez kell, és azt is, hogy tényleg kell, nem váltható ki.
-
samujózsi
senior tag
válasz
Frawly
#29221
üzenetére
Ennek kevés köze van a szanaszét patch-elt kernelekhez. Annyira ősi dolog, hogy elvben minden kernelben benne kellene lennie, még a routerekre és más hasonló eszközökre készültekben is benne van amennyire tudom.
Mindenesetre ha nincs secure boot¹ bekapcsolva a gépeden vagy a fizikai vason (alias host) futó rendszered képes úgymond meghágni azt, akkor talán érdemes lenne felraknod egy virtualboxot, alá betolni a gentoo-d image-ének egy másolatát és azon kipróbálni. Egyre gyanúsabb a kvm efi ugyanis.
¹ A secure boot úgy jön ide, hogy a virtualbox aláíratlan kernel modult hoz magával. Lehet, hogy a disztro saját repojából települő aláírt válrozattal jön, én a virtualbox.org-ról hoztam el a telepítőt, az meg például ubuntun nem működött.
Ellentétben valamelyik ubi klónnal, ami valahogy engedélyezte mégis. -
-
-
samujózsi
senior tag
válasz
Frawly
#29209
üzenetére
Mindkét console= parametert beleraktad a kernel parancssorába? A /dev/ttySn esetében n helyett biztosan jó sorszám áll? Ha egy Serial port van, akkor ttyS0, ha a meglévő mellé veszel fel újat, akkor inkább ttyS1 kell. A biztos módszer, hogy törlöd virt-managerben a meglévő Serial portot és felveszel helyette egy újat, textbe irányítva, úgy 0-s lesz biztosan.
Akkor a grub menübe kb ezt kell beletenni:
linux console=/dev/ttyS0 console=tty
Ha van más paraméter azt tartsd meg (esetleg a quiet törölhető) -
samujózsi
senior tag
válasz
Frawly
#29197
üzenetére
Hol? Az előbb átfutottam a hozzászólásokat, de nem találtam meg...
Egyébként ha megvan még a history-ban, hogy a hogyan fordítottad és telepítetted, esetleg ránéznék én is.
A make clean-től kellene asszem (ha jól rémlik, valahogy úgy megy, hogy make clean ; make defconfig ....) -
-
Frawly
veterán
válasz
Frawly
#29159
üzenetére
Beigazolódott, hogy az 5.5-RC2 kernel.org vanilla kernel bootképtelensége egy kernelbug, nem csesztem el semmit, nincs baj sem az ext4-gyel, sem az init-tel, és nem is a Gentoo hibája. A kernel.org-os 5.5-RC1 simán bootol defconfig-os fordítás után, szintén mindenféle initramfs nélkül. Majd vasárnap vagy hétfő hajnalban megnézem az RC3-mal.
Szerintem a kernelbe bekerült egy regresszió, ami miatt megfekszik QEMU alatt. Natív telepítésben ez a bug lehet elő sem jön, nem is jelentette még senki.
-
Papooo
senior tag
-
inf3rno
nagyúr
válasz
Frawly
#29167
üzenetére
Vagy aprón összeütni valamit használt alkatrészekből harmad áron is mehetne, felesleges amúgy is az új gép egy gyereknek, mert úgyis túlhúzza, teleszórja vírussal, leönti gyümölcslével, meg még Isten tudja milyen módon teszi tönkre. Nekem annak idején lent volt a gép oldala, aztán bedugtam a lábujjam a CPU ventilátorba, és úgy égett le. Erre tök felesleges százezreket költeni...
-
Papooo
senior tag
válasz
Frawly
#29167
üzenetére
Az ismerősöm kérése az volt, hogy 35-be beleférjen, és elviselhetően (sd kliens, minimum fölötti grafika, 50 fölötti fps) fusson rajta a WoT.
Egy p4-es asztalit váltott volna ki.Holnap elviszi más akinek netezős gép kell, arra szuper a linux is.
A kiscsávónak "be kell érnie Lenovo T530-asal.
Háát, nem egy kategóríát képviselnek. -
Papooo
senior tag
válasz
Frawly
#29161
üzenetére
Kompletten feltelepített Windowsos vinyóval (és ssd-vel is) próbáltam, ugyanúgy a Win logó alatt újraindult.
Egy kissrácnak kellett volna a gép, azaz elsődlegesen hiperoccó "gémör" (nem röhögni! amd e1 procis laptopot is láttam már gamernek hirdetve) lett volna használva, de úgy tűnik feladom a harcot, és marad a gép linuxos.
-
Papooo
senior tag
válasz
Frawly
#29158
üzenetére
Ott hasal el a dolog, hogy a telepített vagy live winek esetén a boot logo megjelenése után indul újra a gép, a telepítő szintén akkor hal meg, amikor a Win logó megjelenik, azaz a telepítés legelején.
Egyenlőre még agyalok a problémán, bár a gép azóta is napi használatban van opensuse linuxal.
-
válasz
Frawly
#29139
üzenetére
Célszerű lenne valamilyen initramfs-t használni, ez az adjuk meg a root partíciót módszer meglepő, hogy még támogatott. Az Attempted to kill init itt valószínűleg annyit takar, hogy nem sikerült elindítani az initet. Ha ilyet csinálsz akkor mindent be kell fordítani az md raidet is.
Ami az md RAID betöltése után következne az a root filesystem Ha jól értelmezem egy md raidről akarsz bootolni initramfs nélkül? Miért
(#29143) samujózsi Nem statikus, meg dinamikus. In-built és loadable. A kernelben nincsen dinamikus lib.
(#29148) inf3rno Ezek korrekt hibaüzenetek. Csak önmagában a "panic line" az csak egy adott sort mutat a kernelben. De ott a backtrace is. Meg normálisan konfigurált rendszeren van kernel coredump is.
-
samujózsi
senior tag
válasz
Frawly
#29146
üzenetére
Több tippem most nincs a hiba okára, ellenben a hibakereséshez egy kis segítség (talán)
A virt-manager-ben megnyitod a kikapcsolt guest adatlapját (Kék, I feliratú gomb)
Ott Add Hardware, Serial -> Device Type: Output to a file, alatta megadsz egy fájlt -> Finish
Vissza a konzolra. (monitor ikon)
Bekapcsolod a guestet, a bootnál valahogy megállítod és még a boot előtt beállítasz két kernel paramétert (gentoot nem tudom, nekem ubuntu van, egy jókor nyomott ESC után megáll a grub menüben. Nyomok rajta egy e-t, mint Edit)
Nálam több soros, de a lényeg a linux kezdetű sor.
Ennek a végéhez hozzáfűzöm (idézőjelek nélkül), hogy " console=ttyS1,115200n8 console=tty0", majd F10 és bebootol.A ttyS1 onnan jön, hogy alapból van már egy serial device, ő a ttyS0. Ha törlöd és újat veszel fel, akkor természetesen a ttyS0 kell első konzolnak.
Így biztosan vissza tudsz lapozni a legelejére és végignézni, van-e más hibaüzeneted is.Hülye egy vicc, de ha tcp kapcsolatra állítod a soros portot, nem fájlba küldöd, akkor például egy netcat localhost 4555 paranccsal nézni is tudod, de akár be is tudsz rá jelentkezni, mintha a soros portra lógatott konzolnál ülnél. Csak a vezérlőkarakterek kezelése lesz kicsit furcsa, meg az, hogy a jelszó is megjelenik, mikor beírod.
-
samujózsi
senior tag
válasz
Frawly
#29144
üzenetére
Hát... make menuconfig és a filesystem konfigurációban a modulos beállítást statikusra tenni.
Kulturált megoldás, megnézni, hogy működiknaz initramfs használat. (jó tíz éve csináltam ilyet utoljára, az emlékeim igencsak haloványak, nem tudok részleteket... nomeg túlságosan windows-os a szemléletem 
) -
samujózsi
senior tag
válasz
Frawly
#29142
üzenetére
És a kernelben benne van statikusan az ext4??
Nekem úgy rémlik, max. modulként, de olyankor initrd-vel használják, onnan tudja berántani az ext4 modulját.Shift-PgUp nem lapoz felfelé?
Végső esetben lehet valami soros port emulációt a kvm guesthez adni, soros kozolról bootolni és akkor a használt terminálprogram bufferével tudsz játszani. Vagy akár logba is lehet küldeni.
Vagy használj virtualboxot e célra, akkor maga a vbox ír logfájlt. -
Frawly
veterán
válasz
Frawly
#29139
üzenetére
A net szerint az az oka, hogy nem találja az init-et. A root partíció meg van neki adva, a szokásos módon, root=/dev/sda2, ez működött is az 5.5-RC1 kernelnél, ami viszont Gentoo tárolóban volt. Az persze logikus lenne, hogy az initet nem találja, mert alapból az init=/sbin/init fájlt keresné, de Gentoo-n olyan nincs, /sbin/openrc-init van helyette. De az sem segít, ha megadom bootkor kernelparaméterben, hogy init=/sbin/openrc-init, épp ugyanezt a hibát dobja.
-
Papooo
senior tag
válasz
Frawly
#29126
üzenetére
Mindent is próbáltam, ami a 25 évnyi számtech tapasztalatom alapján eszembe jutott.
Persze az összes (nem túl fogyatékos) "megoldást" (vedd ki az optikát és megjavul, vagy épp a töröld le a ramot zsíros izzadt kézzzel) is, amit a neten találtam.InsydeH2O® UEFI BIOS van a gépben, ezt kellene valahogy linux alól frissítenem.
Pár nap után rájöttem és is , hogy a virtuális gépből frissítés ötlete halva született.
Ez valami Lenovo átok, mert tele van a net ilyen módon lehalt gépekkel.
A masinát alkatrésznek vettem meg ezzel a hibával, de ez egy olyan gumicsont, amin vétek nem rágódni.
Csak az vigasztal, hogy Linux alatt stabilan működik a masina. Végső esetben "Linux only" laptop lesz.samujózsi A jövő héten a Freedost is ki fogom próbálni, addig csak az ötleteket gyűjtöm, mert előbb sajnos nem lesz rá időm.
Még ezzt találtam mint lehetséges megoldást, de sajna angolom és a linuxos tudásom együtt nem elég a megértéséhez.
-
samujózsi
senior tag
válasz
Frawly
#29126
üzenetére
Ez egy régi, "entry level" gép.
Eleve vannak kétségeim, hogy egy BIOS frissítés bármit megold a problémái közül.
Sajnos sem a BIOS nem támogatja a pendrive-os update-et, sem itt: [link] nem lesz támogatása, mivel ez csak a Thinkpad-eknek szól, ha jól értem.
Egy tipp viszont izgalmas lehet, talán működik is: FreeDOS alól futtatni azt az update-et.
Ha jól emlékszem, az update-et tartalmazó .exe ugyan windows-os (önkicsomagoló zip-féleség), de megfelelő programmal (ha zip, akkor unzip-pel) ki lehet csomagolni linuxon, kirakni egy FreeDOS-os pendrive-ra a kicsomagolt fájlokat és a DOS-t bootolva futtatni a benne lévő .bat fájlt. De mondom, szerintem a srác minden tiltakozása ellenére hw hibás az a gép. -
inf3rno
nagyúr
válasz
Frawly
#29087
üzenetére
Minden rendszernél előfordulhat, ami egyszerre fájlrendszert és adatbázist is használ adat tárolásra. Ha csak adatbázis van, akkor esetleg a tranzakciók használata védhet ellene.
Én is úgy értettem a sérültet, hogy inkonzisztens lesz a snapshot időben.
Ha folyamatos rendelkezésre állás kell, akkor az írás leállítása nem feltétlen jöhet szóba.
-
samujózsi
senior tag
válasz
Frawly
#29087
üzenetére
Mi köze a backup szoftvernek a snapshothoz?
Egyébként nem annyira a kötetet kell lecsatolni a konzisztens, nulla adatvesztéssel járó backuphoz, hanem az adatok írását végző szoftvert kell lelőni, ha nincs olyan adatbázisod, ami lehetővé teszi az online mentést.
Mondjuk azt nem tudom, btrfs/zfs tudnak-e ilyet, szerintem nem. -
inf3rno
nagyúr
válasz
Frawly
#29084
üzenetére
A sok tera lehet, hogy ritka, de egy normál HDD olvasási sebessége 120MB/s körül van. Lehet, hogy a RAID valamit dob rajta, de ha többszáz MB adat van, már annak a másolása is több másodpercig tart, és több másodperc alatt történhetnek írások egy átlagos alkalmazás esetében is. Állítólag a snapshot sem csodaszer erre: [link], szóval könnyen lehet, hogy sok backup-ról, amit manapság mentenek el, éles helyzetben kiderül, hogy használhatatlan vagy minimum sérült.
-
inf3rno
nagyúr
válasz
Frawly
#29078
üzenetére
Nem állítottam, hogy bármelyik is kiváltaná a másikat.
Ha már így szóba került, akkor inkább azzal lenne értelme foglalkozni, hogyha rendelkezésre állás és backup is kell, akkor mégis hogyan írunk föl több terabyte állandóan változó adatot valamire? Elkezdjük a másolást, aztán mire a végére érünk már tök más adat van fent a lemezen...
-
-
samujózsi
senior tag
válasz
Frawly
#29056
üzenetére
Köszi, úgy egy órája fedeztem fel, hogy az ovmf picit több a sima efi-nél, csak nem volt időm foglalkozni vele (mindig így járok: kérdezek, aztán amíg várom, hogy valaki válaszoljon, unalmamban megtalálom a választ
)
Sajnos a secure bootot nem tudom mellőzni, mert hülye lesz tőle az alaplapom. Valami BIOS bug lehet, de pl több napos uptime után se reboot, se poweroff nem működik, bios/efi szinten lefagy, és ha nincs secure boot... már nem emlékszem, de akkor valamiért egyáltalán nem tudtam bebootolni rajta pendrive-ról. Régi Asus alaplap.
Eddig legfeljebb annyi problémám volt a secure bootból, hogy bsd-t nem sikerült telepíteni. Szerencsére az ubuntu megy vele.
De ha kicserélem az ssd-t, majd megnézem újra, hátha csak én rontottam el valamit amikor ki akartam kapcsolni. -
samujózsi
senior tag
válasz
Frawly
#28999
üzenetére
Abban van igazam, hogy nagy mellénnyel... hogy is szokták mondani? "Leugatsz" valakit, nem egyszer, istentelenül magas lóról beszélve, gyakorlatilag lehülyézel, miközben olyan dolgokba szólsz így bele, amikről halvány fogalmad sincs.
Igen, például az rkhunter hülyeséget jelzett, de ezt csak azért vehetem többé-kevésbé biztosra, mert a live rendszeren is ezt csinálja. Különböző linuxos fórumokon keresgélve is csak találgatásokat láttam ezzel kapcsolatban, érdemi magyarázatot nem.
Mivel a gyári telepítést követően az update sem megy vele, bele kell nyúlni a konfigba, ott most bármi lehet. (Értsd: bug, hibásan csomagolt default config, de akár az is megtörténhetett, hogy valahol illetéktelenek fértek hozzá valamelyik szerverhez - ez utóbbinak az esélye elhanyagolható, de nem nulla)Hogy van egy állandósult, lassú oldalbetöltés és van egy olyan jelenség, hogy esetenkén pár másodpercre minden megáll, azok közt lehet ugyan összefüggés, de semmi biztosíték rá, hogy van is. Elképzelhető hardver hiba, az adott ubuntu verziót érintő bug, konfigurációs probléma, akár a kernelben is stb. De az is lehet, sőt, valószínű, hogy ezek függetlenek.
Annyira mélyen nem ismerem a rendszert, meg nem is okoz olyan mértékű gondokat, hogy nekiálljak forrásból újrahúzni mindent. -
samujózsi
senior tag
válasz
Frawly
#28997
üzenetére
Tudod az egészben az a vicces, hogy a jelek szerint sok esetben nem is érted, hogy mit kérdezek, csak belefáradtam, hogy újra és újra megmutassam, mekkora marhaságokat hangoztatsz, mint egyedi igazságot.
Vagy nem te voltál, aki itt megszakértette pl a LUKS jelszó kezelését?Láttál valaha rkhuntert, tudod egyáltalán, hogy mi az??? ("Shared szegmens hogy lehet gyanús" - talán futtass ubuntu 18.04-n firefox mellett egy rkhunter -c --rwo parancsot és nézd meg, mit ír ki! Aztán nézd meg ugyanezt 16.04 alatt és csodálkozz)
Tudod, általában azért kérdezek itt, mert bízom benne, hogy olyan is olvassa, aki segíteni próbál és tud, nem csak megmagyarázni, hogy miért vagyok hülye hozzá.
Ugyanezen a gépen, 16.04 ubuntuval, ugyanilyen hálózati konfiggal nem volt lassulás. Frissen telepített, up to date 18.04-nél valahol, valami lassít. Részben a böngészést, részben néha az egész GUI lefagy úgy, ahogy van. Logokban semmi nyoma, hogy hiba lenne.
-
samujózsi
senior tag
válasz
Frawly
#28958
üzenetére
No, akkor lássuk, mi az amit érdemes lehet megőrizni (nem feltétlenül továbbvinni az új rendszerre) egy ilyen költözés során:
/home - egyértelmű
/root - ha olyasmit csinálok, amihez root jog kell és egynél több parancs kell hozzá, akkor nem szórakozom sudo-val egyenként, hanemsudo -iés csinálom rootként.
/etc - konfigokból később ki lehet bányászni, ha valamit elfelejtek és hónapokkal, netán évekkel később újra be kell állítani
/var/log - számomra fontos infókat tartalmazhat, beleértve például az audit logját, a journal fájlokat (systemd)
/var/spool - itt lehetnek olvasatlan e-mailek, crontabok stb.
/var/lib/dpkg - debian alapú rendszernél a telepített csomagokról tartalmaz infót/usr/local, /opt, /usr/share - ezekkel nem vagyok teljesen képben, mert úgy vettem észre, nem feltétlenül szabványkövető a használatuk(vagy én nem ismerem eléggé a "szabványokat"). A share alatt lehetnek utólag módosított konfig fájlok (talán).
/usr/src - fontos lehet, ha saját fordítású kernelt kellett használni valamiért, mást nem sűrűn látok itt. (valójában csak a kernel forrásban módosított fájlok kellenek belőle)
/boot - itt leginkább a grub konfiggal kapcsolatos dolgok lehetnek izgalmasak./var/lib - itt is lehetnek fontos dolgok, például a kvm virtuális gépekhez tartozó image fájlok a libvirt/images könyvtárban. Ezen kívül vajon még mi?
-
-
Frawly
veterán
válasz
Frawly
#28958
üzenetére
De ez még Windowson is így van. Ott is lehet úgy üzemeltetni a rendszert, hogy a rendszerpartíción lehetőleg semmi olyan pótolhatatlan ne legyen, amit reinstall előtt mentegetni kéne külön. Tehát érdemes a Dokumentumok mappát áthelyezni, a Thunderbird, Firefox, stb. profilmappákat is adatpartícióra helyezni, Steam játékmappáit is, meg minden hasonlót. Egy kis előrelátással sok időt spórol magának az ember, hogy esetleges reinstallkor kevesebb teendője legyen, és simábban, fájdalommentesebben újrahúzza a rendszert.
-
-
samujózsi
senior tag
válasz
Frawly
#28950
üzenetére
Linuxon. Azt csak két és fél éve használom windows nélkül (előtte csak virtualizálva). Windows-t picit hosszabb időn keresztül.
Nem akarok én senkit meggyőzni, hogy mentse át a logokat és őrizgesse.
Én mentem, mert volt már, hogy segített. És ha egyszer segített, akkor máskor ne segíthetne ugyanígy?Linuxon sem csak feltörés okozhat furcsa, esetleg hibás működést (de azt is fel lehet törni, meg lehet fertőzni, csak másféle tudás kell hozzá, mint a windows fertőzéshez/töréshez)
Lehet hardveres probléma, lehet egy elcseszett, bugos update késleltetett hatása, lehet sok minden. -
samujózsi
senior tag
válasz
Frawly
#28948
üzenetére
Nem, a log nekem arra kell, hogy lássam, ha már korábban is ott volt az a gyanúsnak tűnő dolog, illetve ha nem, akkor kb mióta látható.
Linuxon csak egyszer volt ilyenre szükségem, de amíg windows-t használtam, addig sokszor segített a régi event log kiszűrni a viszonylag új hibákat. Például, mikor úgy tűnt, feltörték a gépem vagy vírusos lett. -
samujózsi
senior tag
válasz
Frawly
#28945
üzenetére
Log? Elég sokmindenre. Egyetlen példa: ha valami furán/hibásan kezd működni, akkor a logokat szoktam előszedni elsőre. Sokszor volt már, hogy azt hittem, találtam valamit, majd kiderült, hogy egy éve is ott volt ugyanaz, csak nem emlékeztem rá, viszont így már nyugodtan kihagyhattam a nyomozásból.
-
samujózsi
senior tag
válasz
Frawly
#28908
üzenetére
Hát az biztos, hogy a notebookom felajánlja ezt az opciót. Hogy egy ilyen változtatást követően megmarad-e a diszk tartalma, annak nem néztem utána. Bekéri a régi jelszót egyszer, az újat meg kétszer.
Ami a változtatás lehetőségét illeti: ez ugye elsősorban arra van, hogy fontos adatokat védjen vele az ember. Képzeld el, hogy egy céges laptopot valaki használ egy ideig, majd kilép a cégtől. Szerinted mennyire jó ötlet a helyére belépő munkatársnak úgy átadni azt a gépet, hogy a benne lévő háttértár jelszavát egy immár külsős ember is ismeri?
-
samujózsi
senior tag
válasz
Frawly
#28904
üzenetére
Ez sem igaz teljesen: változtatni lehet (azt a jelszót, amivel a diszk nyílik), resetelni nem lehet az elfelejtett jelszót.
Linket nem tudok, tegnap néztem a BIOS-ban (dell e5570 vagy 80), hogy le is lehet venni a jelszóvédelmet.Amennyire utánajártam, az sem feltétlenül igaz, hogy a hardveres jelszót elfelejtés esetén ne lehetne kiütni, de ez eszközfüggő. Úgy tippelem, firmware hibák kihasználásával lehet megcsinálni, de alaposabban nem néztem utána, csak a google dobott fel pár utalást, de nem tűntek megbízhatónak, kihagytam őket.
főleg ekkora HDD-knél. Sebességben pedig kicsivel a gyakorlati 150Mb/s szekvenciális harmada körül-felett és 1M blokkmérettel dolgoztam már, kevesebb overhead-hez. (bs=1M)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Plusz egyéb rendszeradminsztrációs cuccok.
Új hozzászólás Aktív témák
- Honda topik
- Xbox Series X|S
- Kertészet, mezőgazdaság topik
- Milyen HASZNÁLT notebookot vegyek?
- Hitelkártyák használata, hitelkártya visszatérítés
- A fociról könnyedén, egy baráti társaságban
- CASIO órák kedvelők topicja!
- Parkside szerszám kibeszélő
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Spórolós topik
- További aktív témák...
- Antivírus szoftverek, VPN
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Assassin's Creed Shadows Collector's Edition PC
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- LG 77G3 - 77" OLED evo - 4K 120Hz 0.1ms - MLA - 2000 Nits - NVIDIA G-Sync - AMD FreeSync - HDMI 2.1
- iKing.Hu - Honor Magic 7 Pro - Black - Használt, karcmentes
- Bomba ár! HP 255 G7 - AMD A4 I 4GB I 128SSD I HDMI I 15,6" FHD I Radeon I HDMI I W11 I Cam I Gari!
- Bomba ár! Lenovo ThinkPad P43s - i7-8G I 8GB I 256GB SSD I Nvidia I 14" FHD I Cam I W10 I Garancia!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged