Új hozzászólás Aktív témák

  • Frawly

    veterán

    válasz Nagytoll #6800 üzenetére

    WinPE és MacOS nem releváns, azok külön a saját drivereikkel hajtják az egeret. Azzal Linuxnál nem mész semmire, hogy Windows alatt megy. Az alatt persze, hogy megy, mert a driverek 99%-a arra készül, és a gépek 98%-án az fut. Még jó hogy azon nem akad.

    Ubuntuval nem azért kéne megnézni, mert az is Live, mint a WinPE, hanem az Ubuntu-kernelben esélyesen többféle szutykot beleforgatnak, meg többféle firmware-t mellékelnek a Live-ban is. Archon lehet minimalizmus miatt a kernelcsomag fenntartója nem fordított bele valami olyan kernelmodult, ami kéne a Logitech egerednek, vagy beleforgatott, de valami firmware-t vagy hasonlót is fel kéne tenni. Ezért kéne előbb Ubuntuval tesztelni, de lehet akár Mint is, az is jó rá. Ami tetszik, csak kezdőknek való, mainstream Ubuntu-alapú disztró legyen, ami támogat Live módot, hogy ne kelljen egy egyszerű hardver kipróbálásához feltelepíteni az egészet, ami külön munka lenne. Nem biztos, hogy segít, de egy Live bebootolást egy pendrive-ról megér, hátha okosabbak leszünk. Mert ha mégis megy azzal, akkor tudjuk, hogy az Archon hiányzik hozzá valami. Az Arch ugyanis alapból egy KISS (Keep it simple stupid) disztró, sok mindent neked kell benne feltenni, külön, magától nem települ, meg nem detektálódik.

    Még az sem biztos, hogy egérprobléma, GPU driver is tud pl. akadásokat okozni, mikor az egeret mozgatod.

  • Nagytoll

    senior tag

    válasz Frawly #6801 üzenetére

    A nagy részével tisztában voltam köszi :)

    Elsőre meg akartam bizonyosodni hogy nem hardveres probléma. Akkor ugye előjönne minden platformon.

    A GPU driveres dolog érdekesen hangzik. Ez eszembe sem jutott.

    A legújabb amdgpu/mesa driver van fent. A napokban frissítettem 19.xx valami driverről, de ott is akadt.

    Mindjárt megnézem hogy Bluetoothon keresztül mit produkál az egér. Eddig a gyári unifying vevővel használtam.

  • Archttila

    veterán

    LOGOUT blog

    válasz Frawly #5595 üzenetére

    Már majdnem elindítottam élesbe (is) a telepítést amikor rátaláltam erre a hasznos hozzászólásodra, szóval:

    Egy 512GB-os 3D TLC-nél a cfdisk -z formában javasolt? (EFI mód) Ha igen akkor mennyit érdemes adni az EFI-nek és mennyit a Swap-nak? (16GB DDR4)

    Én így terveztem:
    EFI/500MB
    Swap/16GB
    System/...

    :R

    [ Szerkesztve ]

    Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

  • Siriusb

    veterán

    válasz Archttila #6803 üzenetére

    Szerintem 16 GB RAM-nál nem kell swap. Ha mégis olyan dolgaid vannak (virtualizálsz stb), ami megenné, bármikor létrehozhatsz egy swap fájlt.

    EFI partícióra min 260MB-t javasol a wiki, gondolom nem tervezel semmi rendkívülit, szóval az 500-nak elégnek kell lennie.

  • Siriusb

    veterán

    válasz Siriusb #6804 üzenetére

    Nálam:
    Filesystem Type Size Used Avail Use% Mounted on
    /dev/sda3 vfat 778M 268K 778M 1% /boot/efi
    Szóval nem nagyon kell aggódni. :D

  • Frawly

    veterán

    válasz Archttila #6803 üzenetére

    A cfdisk után nem feltétlen kell a -z kapcsoló. Az csak arra való, hogy ha lenne már a meghajtón valamilyen partíciós tábla, akkor nem abba particionál, hanem teljesen új, üres partíciós táblát kezd, ír fel, olyat, amilyet kérsz, gpt vagy dos/mbr. Nyilván ha EFI boot van, akkor gpt kell.

    Az SSD partícióeltolása miatt nem kell aggódni, a cfdisk modern tool, eleve 1024K-val tolja el a partíciókat, ami mindenfajta SSD-hez és modern HDD-hez megfelelő.

    Hacsak nem akarsz hibernálni, 16 GB RAM mellett szerintem semmilyen swap nem kell, nem hogy swap partíció. Ha esetleg később mégis szükséges lenne swapra, azt lehet fájlként is létrehozni, pl. 8 gigás swap fájlt így tudsz akármikor, telepítés után is létrehozni:
    dd if=/dev/zero of=/elérési/út/swapfile bs=1M count=8192
    mkswap /elérési/út/swapfile
    swapon /elérési/út/swapfile
    Illetve be kell tenni a /etc/fstab-ba is ezt a sort:
    /eléséri/út/swapfile none swap defaults 0 0

    Az Arch-nak nem kell nagy EFI partíció, jelenleg nekem 100 megás van, és abból is 51 MB szabad. Ha egyedüli rendszered az Arch azon a lemezen, akkor neked se kell nagyobb. Csak egyes disztróknál kell nagyobb, mint az Ubuntu, Debian alapúak, meg Void, amelyek otthagyják a régi kerneleket szaporodni. De adhatsz végül is 500 megát is neki, 400 mega ide vagy oda ma már nem tétel. De csak Archhoz overkill az 500 MB. Az EFI partíció típusának EFI system-et kell megadni, és az Arch Wiki alapján mkfs.vfat-tal FAT32-re kell formázni.

    EFI bootoláshoz nem kell GRUB sem, az Arch Wiki systemd-boot cikke alapján csináld.

    Root partíciónak annyit adj, amennyire szükséged szokott lenni, nálam 50 giga van, de az overkill, nagyját nem használom, 11 GB-ból megáll a teljesen belakott Arch telepítésem, de aki nagyon fullos, GUI-s, DE-s kiszerelésben használja, annál sem hinném, hogy 20-30 gigánál többre szükség lenne, én is csak biztos, ami biztos alapon szabtam ilyen nagyra. Persze ez mindenkinél felhasználásfüggő, mennyi programot, csomagot telepít, hol van a Steam mappája, stb..

    A maradékot (~461 GB) meg adhatod /home-nak, ahol nem csak az user home mappája lehet, hanem használhatod általános adatpartíciónak is, bármilyen adat tárolósára, torrent, dokumentumok, portable programok, stb..

    Partíciókat, ha csak speciális igény nincs, simán, ext4-re kell formázni.

  • Nagytoll

    senior tag

    válasz Nagytoll #6802 üzenetére

    Megvan a probléma.
    Interferencia...
    Pedig ez volt az első amit kizártam. Nem hittem hogy tényleg be tudnak egymásnak zavarni a dolgok. Eddig sose volt interferencia gondom.

    Bluetoothon keresztül elsőre jónak tűnt ameddig be nem dugtam a dongle mellé egy pendrive-ot és elkezdtem rá írni dolgokat. Egyből megfagyott az egérmutató :D

    Most úgy néz ki jobb a helyzet hogy a Logitech unifying vevő a gép hátuljába az alapba van dugva olyan portba ami körül nincs más. Közben 2 másik eszközhöz is kapcsolódva volt a gép Bluetoothon.

    Az lesz a végső megoldás amit valahol olvastam, hogy egy USB hosszabbító kábellel távolabb lesz a Logitech dongle, így elvileg nem lesz annyi interferencia.

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz Nagytoll #6807 üzenetére

    Ez általában is igaz, ha valami USB csatlakozást használó eszköz (mint ez a USB BT adaptert használó egér) problémás, akkor az első, hogy átdugdosod másik USB portba, lehetőleg a gép hátuljába is, mert a gép előlapján vagy tetején lévő USB kivezetések nem minden háznál valami megbízhatóak.

    Bár azt nem értem, hogy ha interferencia volt a gond, akkor az Windowson miért nem jött elő? Erről az interferenciáról hülye szóviccként mindig az jut eszembe, ahogy Vágási Feri szállt be Win95-tel az internetbe :DDD

    [ Szerkesztve ]

  • Archttila

    veterán

    LOGOUT blog

    válasz Frawly #6806 üzenetére

    Huh, ez aztán a részletes válasz! :R

    Az SSD partícióeltolása miatt nem kell aggódni, a cfdisk modern tool, eleve 1024K-val tolja el a partíciókat, ami mindenfajta SSD-hez és modern HDD-hez megfelelő.

    Erre voltam kíváncsi, köszönöm!
    A többi már megy*, hiszen Vboxban van egy félig belakott Arch rendszerem, illetve korábban évekig Debian (netinst) volt a gépen Xfce DE-vel. :)
    Swap-al kapcsolatban régen azt olvastam, hogy mindegy mennyi RAM van a vasban, a rendszer normális (hibamentes) működéséhez akkor is ajánlott a Swap használata. (lehet bullshit)

    Egyébként szívem szerint egy Openbox/Tint párost konfigolnék a végtelenségig :D de sajnos család/munka mellett erre (már) nem nagyon van idő :) így marad az Xfce.

    *ez a Grub nélküli EFI boot új volt, köszönöm! :)

    [ Szerkesztve ]

    Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

  • Archttila

    veterán

    LOGOUT blog

    Ha mar szoba hoztam az Openbox-ot: mondanatok par (szerintetek) jobb WM alternativat?

    Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

  • Shyciii

    veterán

    válasz Archttila #6810 üzenetére

    Szerintem WM-ek között az Openbox a legjobb, csak én nem tint2-vel használtam (keveset tud), hanem polybar-al. A config fileokat én pl meg is tartottam, ha a Bspwm tiling manager nem jönne be.

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz Archttila #6809 üzenetére

    Igazából már bármelyik linuxos particionálóprogram 1024K-n alignál, már a windwososak is. A rossz eltolás csak akkor szokott fenyegetni, ha a kedves user XP-vel meg hasonló retró régiséggel particionál, vagy valami elavult, régi verziós particonálóprogrammal, esetleg klónozásnál szúrja el az eltolást, ha HDD-s rendszerről klónoz SSD-re.

    A swap kötelező használata bullshit. 0,5-4 GB RAM-nál még talán elment a biztonság kedvéért pár giga swap, biztos, ami biztos, hátha egyszer mégis kell alapon, de 16 és 16+ GB RAM mellett, átlag felhasználásnál a rendszer nem fog hozzányúlni, hiába van, már 8 GB RAM-nál sem nagyon szokott beleírogatni, csak jelképesen pár KB-okat. Egy kivétel, ha valami nagyon speciális alkalmazást használsz, ami rendellenesen sok memóriát eszik, pl. nagy fejlesztőkörnyezetekben több gigás projekteket nyitogatsz meg, meg 3D renderelés, SQL szerver, meg képszerkesztőben sok gigapixeles poszterek, térképek szerkesztése, videóvágó progikban hatalmas felbontású és sávszélű nyers videók szerkesztése és effektezése, nagyobb virtuális gépek vagy egyszerre több virtuális gép futtatása, hasonlók, de ez ugye nem átlagos, normál felhasználás többé. De normál felhasználásnál ilyen Arch + Xfce és Arch + Openbox rendszer alá már a 16 GB RAM is overkill.

    Az Xfce-vel nincs semmi baj, de az Openbox érdemesebb lenne, azt egyszer konfigolod be, és évekig szolgál. Jelenleg én is Openbox-on vagyok Polybar-ral. Értelmes felhasználással még sose használtam ki a 16 GB RAM-ot, talán 1-2× ment el a memóriahasználat 8-12 gigáig, mikor annyira sok minden meg volt nyitva (meg még KDE futott), meg 2× fogyott el a memória, de az nem értelmes felhasználásnál, hanem bug miatt a Chrome/Chromium kapott memory leaket. De igazából minimális swap mellett, minimalistább rendszernél (minimalista WM, terminálos alkalmazások, Firefox) még 4 GB RAM-mal is el lehet lenni, de azért a 8GB ma már ajánlott átlag usernek, aki bloatabb, full DE-ket használ, meg nagyobb GUI-s programokat, GIMP, LibreOffice, KDEnlive, Atom vagy Visual Code, Chrome/Chromium, stb..

    Persze annyiból meg a 16 GB RAM is megéri, hogy nem sokkal drágább, mint a 8, és a Linux kernel akkor is befogja valamire a kihasználatlan részt, ha nincs kihasználva. Befogja eszközök, fájlrendszerek cache-elésére, így használva van valamire, nem csak az van, hogy ott áll üresen a memória kihasználatlanul. Át lehet bele tenni a böngészőcache-t, stb., lehet bele tmpfs ramdrive-ot csinálni benne, stb., így mindig kihasználható a parlagon maradt üres RAM. Olyan nincs, hogy valakit azért vitt el a mentő, mert túl sok RAM-ja volt. Talán utoljára Win9x-en emlékszek olyanra, hogy default beállíton gond volt, ha 1 GB-nál több RAM-ot tettél alá, de erre is volt hack, hogy menjen, meg többet lásson.

    Igazából EFI partíciónál is mindegy mekkora, amíg a szükséges EFI fájlok, kernelek ráférnek. Akár még egy FAT12-es floppy is lehet EFI meghajtó, nyilván így senki nem használja. Meg lehetne akár egy 20 megás FAT16 partíció is. Ez a legtöbb oldal által emlegetett 250-500 gigás FAT32 EFI partíció is csak azért van ajánlva, hogy ha utóbb mégis több OS-t teszel fel rá, és gyűlnek rajta az EFI fájlok, akkor ne fussál ki a helyből, meg a Windowsnak is ugyebár kellhet rajta a hely. De Windowsnál sem gond ez, vagy másik dual/multiboot OS-nél, ha azokat másik meghajtóra telepíted, amiknek saját EFI partíciója van.

    Legutóbb egy brit csávón röhögtem, saját YouTube-csatornája van, és a 20.04-es Deepin Ubunturól csinált review-t. Miután végzett a rendszer bemutatásával, a videó végén benyögte, hogy a bemutatott rendszer csak tesztrendszer volt, ha magának telepítené fel tartós használatra, lenne swap. A háttérben látszott, hogy megy neki a htop, benne mutatja a 32 GB RAM-ot, amiből talán 2-3 giga volt kihasználva (ebben már cache/buffer is benne volt). Ja, arra tényleg létfeltétel úgy a swap, már így is ~29 gigabájt állt csak benne üresen. De ugyanez volt a DistroTube csatornás fazonnál, aki eleve 32 giga RAM-mal vette a gépet, ami eleve nem volt kihasználva, 20+ giga rendszeresen ott volt neki kihasználatlanul (minimalista WM, terminálos alkamazások futnak csak nála, legfeljebb 1-2 kisebb VirtualBox gép meg OBS, amivel FullHD-ben streamel, és utóbbi sem eszik pár giga RAM-nál többet, meg néhány opensource játék, amik megint nem esznek 4 gigánál több RAM-ot), de felbővítette 64 gigára, mert az kell. Nála enyhítő körülmény, hogy legalább a swapot nem erőlteti, az lenne még csak szép. Holott a felhasználása beleférne simán 16 GB-ba úgy, hogy szintén nem lenne szüksége swapra.

    Az ilyen 16 GB RAM Windowson is csak akkor szűk, ha spéci felhasználás van, vagy valaki olyan gamer, hogy a legújabb játékokat is 4K-ben erőlteti, és még mellette streameli is a játékot. Ilyenkor már valóban néhol nem lehet elég 16 GB RAM, de ilyenkor is csak minimálisan kéne neki több, és ez sem azért van, mert az adott cucc nem férne bele a memóriába, de a Windows memóriakezelése, memóriahasználata eleve nem olyan hatékony, mint a Linuxszé. De aki csak sima gamer, FullHD-ban játszik, átlag felhasználás, annak még Win10 alatt is bőven elég a 16 GB RAM, a legeslegújabb játékokhoz is.

  • Archttila

    veterán

    LOGOUT blog

    válasz Shyciii #6811 üzenetére

    Koszonom!

    Tiling nem kell, szoval akkor marad az Open es a polybar mert arra gondoltam, hogy ha mar ugy is valtok Debian/Xfce vonalrol akkor legyen ez egy nagy ugras, igy elengedem a DE-et es Arch/openbox/polybar vonalon elek tovabb. :) (mindig is akartam egy minimal rendszert)

    Elkezdtem visszaolvasni 1000 hszt es azt kell mondjam rengeteg hasznos okossagot leirtatok mar :K persze nyilvan lesz meg par kerdesem, de majd ugy is meglatjatok... :D

    [ Szerkesztve ]

    Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

  • Frawly

    veterán

    válasz Archttila #6810 üzenetére

    A WM attól függ, hogy hogy használod a gépet. Mennyire használsz csak GUI-s programokat, vagy mennyire csak terminálosokat, milyen programokat és azokból hányat futtatsz egymás mellett, pl. vannak-e ilyen nagyobb szerkesztőprogramok, amik sokféle eszköztárral, dokkal, ablakkal, alablakkal dolgoznak (pl. GIMP). Mennyire akarsz 3D effekteket és egyéb csicsát, mekkora képernyőt, felbontást használsz, hány darab monitorhoz milyen multimonitor kezelést igényelsz.

    WM-nél a „jobb” nem nagyon értelmezhető, legfeljebb adott felhasználásra lehetnek minimalistább, egyszerűbb, kevesebb erőforrást lekötő WM-ek, de ezek sem mindenkinek jobbak, és általában ezek terminálos/TUI felhasználást feltételeznek, meg azt, hogy mindent billentyűzetről vezérelsz, és nem akarsz egerezni.

    Az Openbox elég népszerű, mert kellően minimalista, mégse olyan fapados, hogy egerezős, GUI-s usernek használhatatlan legyen. Egy elég reális köztes alternatíva bárkinek, bloat rendszert és minimalista terminálos workflow-t használó usernek is elmehet.

    Persze annyiból már az Openbox is fapados, hogy se háttérképkezelés, se dokk/panelkezelés nincs benne, se mindenféle vágólap/rendszerértesítő, billkiosztás-váltó service, nem tartalmaz GPU kompozitálást, ezekről mind magadnak kell gondoskodni 3rd party csomag telepítésével és konfigurálásával, saját DE-t kell építeni belőle, mert default csak egy szürke háttérrel meg egy magától nem frissülő jobb egérklikkes „Start”-szerű menüvel jön és kifújt. Így pl. neked érdemes lehet Openboxhoz picom kompozitort, Tint2-panelt, xfce4-clipman-t feltenni hozzá, a menüje frissítéséhez mmaker-t, esetleg valami másik alkalmazásindító menüt kínáló alkalmazást, rendszerértesítőt (pl. Dunst), háttérképkezelésre feh vagy nitrogen, témázáshoz Obconf, asztali ikonok kezelésre PCmanFM, és még lehetne hosszan sorolni.

    Meg annyiból limitált az Openbox, hogy pl. csak monokróm képi elemekkel (xpm-képformátum) témázható. Meg egyesek a virtuális desktop, multimonitor kezelését, tiling képességeit fapadosnak tartják.

    Mondom, mindenkinek a saját igényei, felhasználása, gépe szabad felhasználható erőforrásai szabják meg, hogy mi a jobb WM neki, és azokhoz mit tegyen fel. Ez idővel is változhat, mert még Linux alatt is változhatnak idővel az ember felhasználási szokásai.

  • Shyciii

    veterán

    válasz Archttila #6813 üzenetére

    Ha akarsz egy löketet a konfiguráláshoz, hogy ne menjen el több időd, mint szeretnéd, akkor szólj. Én több, mint 1 évig használtam (polybar-t még most is), és még a konfig fileok is megvannak. Abból tudsz ihletet meríteni magadnak, ha gondolod.

  • Frawly

    veterán

    válasz Shyciii #6815 üzenetére

    Redditen unixporn topik, meg YouTube videók, alattuk mindig meg van adva a git tároló a konfigfájlokkal, onnan sokat lehet meríteni. Nem csak Openboxhoz, hanem bármihez, sőt, új CLI-s terminálos programok felfedezéséhez is jó, amiket még nem ismert az ember. Na, meg a nagyobb YouTube-erektől is sokat lehet tanulni, videón mutogatják, hogy mi hogy működik, mit hogyan lehet konfigolni, mire kell figyelni, mire milyen alternatívák vannak. Ilyen csatornák, mint Luke Smith, DistroTube/Derek Taylor, Brodie Robertson, ne meg teljesen kezdőknek rettenet hasznos lehet Chris Titus Tech, gotbletu, és van még ilyen pár, ott volt valami amerikai orvostanhallgató csóka a vim/markdown témájával, az is nagyon hardcore-ban tolja, annak már nem is emlékszem a nevére. Egyedül ilyen politikus megmondólúzereket nem érdemes nézni, mint Bryan Lunduke, meg ilyen n+1. teszteljük a Gnome vagy XY disztró legújabb kiadását, mert most fedezték fel maguknak a Linuxot emberek, mint Switched to Linux, Linux bloke, stb., ezeket szerintem szimplán időpocsékolás nézni, annyira amatőrök.

  • Shyciii

    veterán

    válasz Frawly #6816 üzenetére

    Anno néztem a rediten, hogy ki milyen polybart csinált magának, de a legtöbbje nagyon egyenkinézet, úgyhogy egyiket sem használtam fel, hanem alkottam magamnak egy sajátot, aztán időnkéjt belemódosítottam, ahogy folyamatosan jöttek az igényeim.

  • Archttila

    veterán

    LOGOUT blog

    válasz Frawly #6816 üzenetére

    Githubhon rengeteg hasznos guide és script halmazt találtam, így azt hiszem egyelőre nincs többre szükségem, ezen felul elmentettem pár hasznos YT csatornát is, de köszönöm a sok hasznos okosságot és felajánlást! :R

    Közben történt a desktop körül pár változás, (konkréten most nincs de soon status-ba van) :D így a TV alatt lapulo PI-re kell hagyatkoznom, illetve arra sem ;) mert eladtam, :DD de jövő hét szerdán érkezik egy 4 gigás modell szóval (ha lassan is) de indul az az Openbox project. :) (egész nap ezen kattogok a munkahelyen :D ) Szóval (egyelőre) nem Arch alapokon startolok lévén nekem már van itthon egy felkonfigolt Raspbian Lite server. Semmi extra csak ami feltétlen szükséges: iptables, ssh, samba, transmission, dlna, sftp... ezeket csak azért írom, hogy mert bár messze állok az általatok bírtokolt tudástol :P de ilyesmit álmomból felkeltve is összedobok terminalba :) service-ket lelövök, source-bol forgatok, illetve olyan 8-10 éve kernelt is forgattam egy régi Inteles Prescott vasra :) (azt hiszem default nem volt HT) :D elvagyok mc-be maximum egy Double Commander-t tennék fel, nem kell Login manager tökéletes az xinit startx megoldás és sorolhatnám... :) szóval ˜hálisten nem teljesen az alapoktol kell kezdenem. :)

    Lényegében amiben majd segítségre szorulok azok inkább a korábban DE-vel jövő bloat programok, a WM rendszer jellegéhez igazított alternatívái, mert ugye ezekkel eddig nem kellett foglalkoznom mivel (többnyire) hozta magával puttonyba a dagadt Meta package. :) szóval gondolok itt ilyenekre, hogy XFCE4 terminal helyett ti melyiket javasolnátok, vagy pl hogyan (inkább melyik) progival automatizáljam a telefonom felcsatolását (mert gondolom erre sem lesz fent alapbol semmi), Pulseaudio vagy Alsa....? szóval ezeknek a kisérletezésvel nem töltenék el heteket ha nem muszaj, mert azért csak könnyebb megnézni 1-3 alternatívát és dönteni, nemde? :)

    szerk.: az Openbox alatt szokásos editorok, témázók, compiz és ezek automatikus indítása eléméletben :D már megy, meg guide-ok alapján annyira nem tűnik nehéznek, inkább időigényes pepecselős szerkesztgetés (amit élvezni fogok)

    [ Szerkesztve ]

    Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

  • Shyciii

    veterán

    válasz Archttila #6818 üzenetére

    Én openbox alatt a következőket használtam:
    Terminál - Termite
    Telefon felcsatolása - gvfs-mtp
    Hangkeltő - Pulseaudio

    Egyébként az Openbox konfigurálása rém egyszerű (pláne aki ismeri az XML nyelvet). Igazából gyorsan meg vagy vele, ha pontosan tudod, hogy mit szeretnél. Inkább a polybar testreszabása lesz hosszadalmasabb, mert ott több próbát fogsz tenni, me rájössz, hogy inkább mgis más sorrendbe akarod kirakni, vagy inkább ezt középre, vagy inkbb mégse kell, mást jelenítenél meg :D
    Openbox alatt a témázás, automatikus elindulások, billentyű konfigok, ablakok viselkedése stb gyorsan megvan.

  • Shyciii

    veterán

    Frawly

    Találkoztál már olyannal, hogy a vifm-ben ha egy parancsot akartál futtatni, akkor kiírta, hogy Tmp file too large. Egyszerűen egy tömörítést hajtanék végre tar-al, ami konzolban megy, vifm alatt meg kiírja ezt a hibát. /tmp mappában .8GB szabad hely van, szal az nem lehet gond.

  • Frawly

    veterán

    válasz Shyciii #6820 üzenetére

    Ilyet még nem pipáltam, igaz én nem nagyon dolgozok nagy fájlokkal. Utánagugliznék, de azt te is tudnád.

    Ezt a tar tömörítést pontosan melyik paranccsal csinálnád, milyen paraméterekkel van meghívva?

  • Shyciii

    veterán

    válasz Frawly #6821 üzenetére

    Semmilyen nagy file-ról nincsen szó. Terminál alatt simán le is fut, csak gondoltam bekötöm vifm alá. Egy 8,5MB-os tömörített file-ról van szó, ami kitmöröítve se sokkal nagyobb, mert régi mp3-ak (tesztre jók voltak). Ezt használja a script kitömörítésre: tar xzf $1
    Egyébként jó kis script ismerteket kitömöríti (terminalban használom):
    bashrc-be kell berakni:

    ex ()
    {
    if [ -f $1 ] ; then
    case $1 in
    *.tar.bz2) tar xjf $1 ;;
    *.tar.gz) tar xzf $1 ;;
    *.bz2) bunzip2 $1 ;;
    *.rar) unrar x $1 ;;
    *.gz) gunzip $1 ;;
    *.tar) tar xf $1 ;;
    *.tbz2) tar xjf $1 ;;
    *.tgz) tar xzf $1 ;;
    *.zip) unzip $1 ;;
    *.Z) uncompress $1;;
    *.7z) 7z x $1 ;;
    *) echo "'$1' cannot be extracted via ex()" ;;
    esac
    else
    echo "'$1' is not a valid file"
    fi
    }

  • Frawly

    veterán

    válasz Shyciii #6822 üzenetére

    Fura. Ez szerintem valami script-lefutási hiba, nem a /tmp méretével függ össze.

    Már eleve azt nem értem, hogy minek mp3-akat összetömöríteni, mikor azok már elve tovább nem tömöríthetők. Mivel eleve átmennek egy pszichoakusztikus adatcsökkentésen, majd egy Huffman-tömörítésen, tovább már semmi nem tud rajtuk tömöríteni.

  • Shyciii

    veterán

    válasz Frawly #6823 üzenetére

    AZért mp3-at tömörítettem, mert az volt kapásból kéznél abban a mappában ahol épp voltam. Ez csak tesztre kellett, hogy vifm alatt is működik-e.
    Script hiba biztos nem lehet, mert mint mondottam terminálból gyönyörűen működik. Csak a vifm írja ki ezt a hibaüzenetet, de akkor majd írok egy ezzel foglalkozó fórumba, mert ilyen hibát csak vi-sek írnak ahogy kerestem.

  • májkimiki

    őstag

    Sziasztok!
    Van egy Arch rendszerem SSD-n, UEFI módban Grubbal telepítve. A haldokló notimat (AMD A6 proci és APU) cserélem egy (i5 APU) SFX konfigra. Átrakom az SSD-t. Számíthatok nagyobb galibára vagy intel spec csomagok fel és nagyjából kész?

  • Frawly

    veterán

    válasz májkimiki #6825 üzenetére

    Semmilyen galiba nem lesz. Átklónozod a telepítést és bootolni fog. Az Intel-AMD váltás nem probléma, mert mind a procihoz, mind a GPU-hoz a kernel szolgáltatja a nyílt drivereket, és a linux-firmware csomag a fw részét, meg a mesa csomag is közös, de ezek mind alapból ott kellene, hogy legyenek.

    Arra figyelhetsz, hogy ha fent lenne a xf86-video-ati vagy xf86-video-amdgpu csomag, akkor azt szedd le pacmannak, mielőtt klónozol. De még ez sem létszükséglet, mert ha fent is hagyod valamelyiket, a Xorg-nak detektálnia kéne, hogy már nem használhatók. Esetleg még az amdgpu pro zárt driver ne legyen fent, ha telepítettél volna olyat.

    Az ilyen váltás csak akkor cinkes, ha valaki zárt NV driverrel használ NV GPU-t, és arról vált valami másra, Intel, vagy AMD GPU-ra. Bár akkor sem egy olyan nagy tragédia, mert akkor is bootolni fog az átklónozott telepítés, annyi, hogy a grafikus felület nem fog menni, hanem konzolban kell az NV-s cumókat leszedegetni, és utána újraindítás után jó lesz Arch esetén.

    Amire még figyelj: ha Intel GPU-t használva kell a hardveres videódekódolás, akkor ahhoz telepíteni kell vagy az intel-media-driver vagy libva-intel-driver csomagot, attól függően, hogy konkrétan milyen Intel GPU-ról van szó. Akár mindkettő felmehet. Ha nem telepítesz ilyet, az nem okozza a rendszer működésképtelenségét, csak videólejátszás közben a procit fogják pörgetni a médialejátszó programok, ha videót nézel.

    [ Szerkesztve ]

  • májkimiki

    őstag

    válasz Frawly #6826 üzenetére

    Jelenleg mindkét csomag fenn van: xf86-video-ati és xf86-video-amdgpu, amdgpu pro-t nem telepítettem.
    Nem fogok klónozni csak simán átszerelem az SSD-t a másik konfigba. Egy i5-4570/Haswell/IHD 4600 lessz az új CPU.
    Jövő hét vége felé lessz a művelet.
    Köszi szépen.

  • Frawly

    veterán

    válasz májkimiki #6827 üzenetére

    Akkor csak leszeded ezt a két csomagot: sudo pacman -R xf86-video-ati xf86-video-amdgpu. Az is jó, ha csak simán átszereled az SSD-t.

    Haswell-hez nem jó az intel-media-driver. Ahhoz libva-intel-driver csomag kell. Esetleg még az Arch Wiki a VP8-9 dekódoláshoz Haswll-nél ajánlja az intel-hybrid-codec-driver AUR csomagot is.

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz májkimiki #6829 üzenetére

    Az ilyen hardverdekódolásos témánál lehet fent többféle csomag is, nem vesznek össze, legfeljebb nem használja azokat, amiket nem tud használni, mert nem relevánsak az adott GPU-hoz. Ez nem olyan, mint a GPU driver, hogy ha elcseszed, akkor nincs grafikus felületed vagy ilyesmi. Nyugodtan lehet vele kísérletezni, el nem tudod rontani. Célszerű a csomagokat egyenként feltenni, és után tesztelni, hogy tudjad melyik működik a te GPU-dhoz.

    mpv alatt a hwdec kapcsolót tedd be az mpv.conf-ba, és lejátszás közben a terminálban tudod nézni a kimenetet (vagy i vagy I-t nyomva lejátszás közben), hogy használ-e VAAPI-t.

    Egyébként meg ez a hardveres inteles VAAPI dekódolás túl van lihegve. Én most kapcsoltam be Arch Testing + Sway WM Wayland alatt Firefox betában, és menni megy, de alig alacsonyabb a CPU terhelés lejátszás közben, a htop 50-100% (a 4 mag = 400%-ból)-os terhelés helyett kb. 20-25%-kal mutat csak alacsonyabbat, ezt így egy kicsit soványnak érzem. Én i5-2520M-et használok (Sandy Bridge mobil), amiben Intel HD3000 GPU van, ez már ősréginek számít.

  • májkimiki

    őstag

    válasz Frawly #6830 üzenetére

    Remélem érezhető javulást hoz az új konfig. Ettől a mobil A6 APU-tól már a hideg ráz. A CPU része nagyon renyhe, állandóan a maxon pörög a kihasználtság. Pedig csak jobbára böngészek, igaz 10 fölötti nyitott lapok vannak általában/böngésző. Kín kivárni mire ráfrissítek vagy visszaképek egy oldalon. Nem beszélve, ha még YT is van közben.
    Hajlamos olyanra is, ha ott hagyom pár órára nyitott munkamenettel, restartolni kell mert a plafont veri a cpu indikátor és semmit nem lehet csinálni. Memória minimális a 6GB-ból és nem is swapol. A CPU viszont be van akadva. Szóval nem mindig érzem az SSD feelinget. Öreg fos Satellite, megérett a cserére.

  • _Dumber_

    őstag

    Sziasztok

    A tegnapi frisstés hazavágta a rendszerem.. illetve él, de így kicsit macera dolgozni vele.

    KDE:
    Bejelentkezni enged, az automatikusan induló programok mind működnek, shortcut-ról bármit tudok indítani, miután a teminal fut onnan is bármi elindul.
    Ami nem megy: nincs háttérkép, nincsenek ikonok, nincs tálca, nincs egérművelet a kmunkaterületen. Bámilyen munkaterület configgal kapcsolatos tevékegység alatt elszáll a systemconfig. Magyarán a munkaterület nem megy.
    Melyik program felelős ezért? MIt probáljak downgradelni? A plasma-framwork már megvolt, de nem lett jobb.

    Tegnapi frissítési lista:
    [2020-05-15T21:41:28+0200] [ALPM] upgraded linux-api-headers (5.4.17-1 -> 5.6.11-1)
    [2020-05-15T21:41:29+0200] [ALPM] upgraded glibc (2.31-2 -> 2.31-3)
    [2020-05-15T21:41:31+0200] [ALPM] upgraded gcc-libs (9.3.0-1 -> 10.1.0-1)
    [2020-05-15T21:41:31+0200] [ALPM] upgraded libtool (2.4.6+42+gb88cebd5-12 -> 2.4.6+42+gb88cebd5-13)
    [2020-05-15T21:41:31+0200] [ALPM] upgraded imagemagick (7.0.10.11-1 -> 7.0.10.11-3)
    [2020-05-15T21:41:31+0200] [ALPM] upgraded libsasl (2.1.27-2 -> 2.1.27-3)
    [2020-05-15T21:41:31+0200] [ALPM] upgraded a2ps (4.14-9 -> 4.14-10)
    [2020-05-15T21:41:31+0200] [ALPM] upgraded a52dec (0.7.4-10 -> 0.7.4-11)
    [2020-05-15T21:41:31+0200] [ALPM] upgraded aalib (1.4rc5-13 -> 1.4rc5-14)
    [2020-05-15T21:41:32+0200] [ALPM] upgraded linux (5.6.11.arch1-1 -> 5.6.12.arch1-1)
    [2020-05-15T21:41:32+0200] [ALPM] upgraded acpi_call (1.1.0-316 -> 1.1.0-319)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded linux-lts (5.4.39-1 -> 5.4.40-1)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded acpi_call-lts (1.1.0-144 -> 1.1.0-147)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded mesa (20.0.6-2 -> 20.0.7-1)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded signon-kwallet-extension (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded btrfs-progs (5.6-1 -> 5.6.1-1)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded kio (5.70.0-1 -> 5.70.0-3)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded kaccounts-integration (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:33+0200] [ALPM] upgraded libakonadi (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded mariadb-libs (10.4.12-1 -> 10.4.13-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded mariadb-clients (10.4.12-1 -> 10.4.13-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded mariadb (10.4.12-1 -> 10.4.13-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kmime (20.04.0-2 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-mime (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded ksmtp (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded libkgapi (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kmailtransport (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kpimtextedit (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kidentitymanagement (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kcalutils (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-contacts (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-calendar (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded libkleo (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded plasma-framework (5.70.0-1 -> 5.70.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-search (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kldap (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded libkdepim (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kimap (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded pimcommon (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded grantleetheme (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded kdepim-apps-libs (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:34+0200] [ALPM] upgraded calendarsupport (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded akonadi-calendar-tools (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded mailimporter (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded libgravatar (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded kmbox (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded messagelib (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded mailcommon (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded akonadi-import-wizard (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded akonadi-notes (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded akonadiconsole (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded kontactinterface (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded ktexteditor (5.70.0-1 -> 5.70.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded akregator (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded alsa-plugins (1.2.2-1 -> 1:1.2.2-2)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded analitza (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded appstream (0.12.10-2 -> 0.12.11-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded appstream-qt (0.12.10-2 -> 0.12.11-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded ark (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded artikulate (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded baloo-widgets (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded binutils (2.34-2 -> 2.34-3)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded blinken (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded cantor (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded openexr (2.4.1-2 -> 2.5.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded kio-extras (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded dolphin (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded dolphin-plugins (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:35+0200] [ALPM] upgraded eventviews (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:36+0200] [ALPM] upgraded fftw (3.3.8-2 -> 3.3.8-3)
    [2020-05-15T21:41:36+0200] [ALPM] upgraded filelight (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:36+0200] [ALPM] upgraded freerdp (1:2.0.0_rc4-8 -> 2:2.1.0-1)
    [2020-05-15T21:41:36+0200] [ALPM] upgraded gcc (9.3.0-1 -> 10.1.0-1)
    [2020-05-15T21:41:36+0200] [ALPM] upgraded gdb-common (9.1-2 -> 9.1-3)
    [2020-05-15T21:41:36+0200] [ALPM] upgraded gdb (9.1-2 -> 9.1-3)
    [2020-05-15T21:41:36+0200] [ALPM] upgraded gegl (0.4.22-1 -> 0.4.22-3)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded gimp (2.10.18-6 -> 2.10.18-8)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded grantlee-editor (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded grub (2:2.04-6 -> 2:2.04-7)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded gst-plugins-bad-libs (1.16.2-9 -> 1.16.2-11)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded zvbi (0.2.35-3 -> 0.2.35-4)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded gst-plugins-bad (1.16.2-9 -> 1.16.2-11)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded gtkspell (2.0.16-7 -> 2.0.16-8)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded libkipi (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded libkdcraw (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded gwenview (20.04.0-2 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded incidenceeditor (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded libkcddb (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded k3b (1:20.04.0-1 -> 1:20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded kaccounts-providers (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded kdav (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded kalarmcal (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded kdepim-runtime (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded kaddressbook (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded kalarm (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:37+0200] [ALPM] upgraded kalgebra (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kalzium (20.04.0-2 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kdeedu-data (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded libkeduvocdocument (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kanagram (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kate (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kbruch (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kcalc (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kdeconnect (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kdegraphics-mobipocket (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded ktnef (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded libksieve (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kpkpass (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kitinerary (20.04.0-2 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kdepim-addons (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kdialog (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kgeography (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded khangman (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kig (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kiten (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:38+0200] [ALPM] upgraded kleopatra (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded klettres (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kmail-account-wizard (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded mbox-importer (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded pim-data-exporter (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded pim-sieve-editor (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kmail (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kmplot (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded knotes (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded konsole (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kontact (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded korganizer (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kqtquickcharts (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded krdc (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded ktouch (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kturtle (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kwalletmanager (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded kwordquiz (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:39+0200] [ALPM] upgraded lib32-glibc (2.31-2 -> 2.31-3)
    [2020-05-15T21:41:40+0200] [ALPM] upgraded lib32-gcc-libs (9.3.0-1 -> 10.1.0-1)
    [2020-05-15T21:41:40+0200] [ALPM] upgraded libkexiv2 (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:40+0200] [ALPM] upgraded marble-common (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:40+0200] [ALPM] upgraded libkgeomap (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:40+0200] [ALPM] upgraded libksane (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:40+0200] [ALPM] upgraded libmagick6 (6.9.11.10-1 -> 6.9.11.11-2)
    [2020-05-15T21:41:44+0200] [ALPM] upgraded linux-headers (5.6.11.arch1-1 -> 5.6.12.arch1-1)
    [2020-05-15T21:41:47+0200] [ALPM] upgraded linux-lts-headers (5.4.39-1 -> 5.4.40-1)
    [2020-05-15T21:41:47+0200] [ALPM] upgraded marble (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:47+0200] [ALPM] upgraded minuet (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:47+0200] [ALPM] upgraded okular (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:47+0200] [ALPM] upgraded opencv (4.3.0-5 -> 4.3.0-7)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded parley (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded pipewire (0.3.4-1 -> 0.3.5-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded print-manager (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded pulseaudio-alsa (2-5 -> 1:1.2.2-2)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded python-appdirs (1.4.3-5 -> 1.4.4-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded python-beaker (1.11.0-3 -> 1.11.0-4)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded python-setuptools (1:46.2.0-1 -> 1:46.3.0-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded python2-appdirs (1.4.3-5 -> 1.4.4-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded rocs (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded spectacle (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded step (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded telepathy-kde-accounts-kcm (20.04.0-1 -> 20.04.1-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded vigra (1.11.1-22 -> 1.11.1-24)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded w3m (0.5.3.git20190105-1 -> 0.5.3.git20200507-1)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded xorg-xvinfo (1.1.4-1 -> 1.1.4-2)
    [2020-05-15T21:41:48+0200] [ALPM] upgraded xorg-xwininfo (1.1.5-1 -> 1.1.5-2)
    [2020-05-15T21:44:32+0200] [ALPM] upgraded package-query (1.10-1 -> 1.11-1)

    [ Szerkesztve ]

  • _Dumber_

    őstag

    válasz _Dumber_ #6832 üzenetére

    Egy info még:

    Ha terminálból indítom a plasma-session-t, akkor ez a kimenet:

    [link]

    [ Szerkesztve ]

  • Siriusb

    veterán

    válasz _Dumber_ #6833 üzenetére

    Nekem is ez volt, lefuttattam egy frissítést, de nem jött új kde csomag tegnap óta. Újraindítottam az X-et, azután legalább a krunner működött, hát parancsoltam:
    kquitapp5 plasmashell
    és
    kstart5 plasmashell
    Így most megy, de újraindítás nem volt.

    Szerk.:
    Hopp, mesa volt a ludas: https://bbs.archlinux.org/viewtopic.php?id=255761

    [ Szerkesztve ]

  • _Dumber_

    őstag

    válasz Siriusb #6834 üzenetére

    Ott a pont.
    mesa 20.0.6-2 -ig visszamentem, és most jó

    Nagyon köszönöm.

    szerk.: a mesa 20.0.7 -2 is jó .. a -1-et érdemes kihagyni.

    Érdekes hogy ezt a pacman -Syu nem dobja fel. Csak a downgrade találja meg....

    [ Szerkesztve ]

  • Shyciii

    veterán

    válasz _Dumber_ #6835 üzenetére

    Érdemesebb a pacman -Syyu -t használni. Legalábbis itt régebben ezt mondták.

  • Frawly

    veterán

    válasz májkimiki #6831 üzenetére

    Az biztos, hogy nagy előrelépés lesz az az újabb asztali konfig egy mobil AMD-s laptophoz képest. Az A6 asztali változatban sem túl erős proci, az A-s sorozatból szerintem az asztali A10, ami minimálisan elmegy szódával.

    Asztali gép további előnye, hogy könnyebben bővíthető. Ha most a 4. gen i5 alatt már DDR4-et használsz, akkor később nem nagy befektetéssel váltasz Ryzen platformra, amihez csak procit és lapot kell venned, ami nem olyan rettenet nagy pénz, ha nem a legfelső kategóriából veszed. De ezzel a 4. gen i5-tel is el lehet lenni még hosszú évekig. Főleg olyan lájtos felhasználással, ha csak 10 fülön böngészel, meg linuxozol (ami eleve erőforrástakarékosabb, mint a Windows), arra még overkill is.

    (#6836) Shyciii: elvileg a -Syu is elég. Az Syyu csak annyival több, hogy az mindenképp kierőszakolja a csomaglisták letöltését a tárolókból, akkor is, ha a legutóbbi listák óta nem történt benne módosulás. Ezt akkor érdemes csak megcsinálni, ha új tárolót vettél fel, de elvileg akkor sem muszáj.

    Egyébként most engem is nyakon öntött egy nagy frissítés, így hogy beszélünk róla, nyomtam neki én is. 1 hete frissítettem, és mégis 401 csomag frissül 1276 MiB terjedelemben, és 5220 MiB-ot módosít a rendszeren :Y Előtte 2 hónapig nem frissítettem, és annyi idő alatt jött össze ugyanennyi frissítés, most meg 1 hét alatt, ez nem semmi. Az én update-em még nem futott le, de én nem számítok problémára, a pálcika WM meg a terminálos cuccok nem nagyon tudnak eltörni, annyi egyszerűek, hogy nincs rajtuk semmi bonyolítás.

    [ Szerkesztve ]

  • Shyciii

    veterán

    válasz Frawly #6837 üzenetére

    Valamelyikőtök régen azt mondta, hogy ezzel a kapcsolóval kierőszakoljuk ugye a csomaglisták frissítését, így biztos azonnal láthatóak az új csomagok, míg ennélkül lehet, hogy csak pár óra múlva "kapcsol észbe" a rendszer.

    Mostmár jó ideje a vifm-et használom, és azt kell mondjam, hogy szeretem használni. Egy nagy hátránya van a Double Commanderrel szemben: a csoportos átnevezés lehetősége. Ez ugyanaz, mint ami a Windows-os TOtal Commanderben is van, hogy változókatm szabályokat lehet beállítani, hogy hogyan nevezzen át sok file-t. Időnként kell ilyet használnom, úgyhogy arra a kis időszakra lehet hogy visszarakom a Double Commander-t, majd mikor kész, akkor uninstall.

  • BoB

    Topikgazda

    válasz Shyciii #6838 üzenetére

    Ehez bőven elég a perl-rename.

    Csak ezért ilyen bloat commander-eket felesleges feltenni.

    You may corrupt the souls of men, but I am steel. I am doom.

  • Frawly

    veterán

    válasz Shyciii #6838 üzenetére

    Vifm-nek nincs saját csoportos átnevezés-lehetősége. Vagyis van, de az nem saját, hanem más programot hív meg. Alapból úgy van a konfigja megírva, hogy a vim-et hívja meg, abban van a fájllista, amit kijelöltél, ott lenyomatod regexp mintákkal meg tételesen, hogy mit mire akarsz átnevezni, mentesz és kilépsz, és maguktól átneveződnek a fájlok, mappák.

    Tehát alapból kijelölöd a fájlokat, majd cw, és előjön a vim, ha fent van nálad. De elvileg bármilyen szövegszerkesztőből csinálhatod, akár nano, akár más, akár még grafikus GUI editor is lehet, csak akkor a vifmrc-ben a vicmd-t át kell írni. A lényeg, hogy tudjon regexp mintákkal dolgozni a text editor.

    Az Arch frissítés most nálam is problémás volt. Nem tört el semmit, jól működik a rendszer, de a frissítés nem akart lemenni, nss és lib32-nss lowfax miatt, /usr/lib/p11-kit-trust.so és /usr/lib32/p11-kit-trust.so fájlok már léteztek a rendszeren. Az --overwrite kapcsolót használva viszont már rendben lement a frissítés, és reboot után bugmentesen működik tovább a rendszer. Persze Archon is ritkán van ennyire durva frissítési hullám, évente max. 1-2×. Legtöbbször egy hét alatt max. csak ilyen 10-20 csomag jön össze 100-200 MiB terjedelemben (nálam), és azoknak a frissítése sem szokott problémás lenni.

    [ Szerkesztve ]

  • Shyciii

    veterán

    válasz BoB #6839 üzenetére

    Ezt jó, de az a bajom vele, hogy a szintaxisa számomra totál elbonyolított (hasonlóan mint az awk, vagy sed parancsé). Míg totál érthető a Double Commander és Total Commander megoldása (még a hülyéknek is), addig ez azért eléggé el van bonyolítva.
    Pl ahogy most nézek egy példát:
    image_10.jpg -> image_010.jpg (lényeg hogy minden image_szám file esetén 3 jegyű legyen a számozás).
    megoldás: perl-rename -n 's{^(.*/)?(.*_)(\d+)([.][^.]+)$}{sprintf "%s%s%03d%s", $1, $2, $3, $4}e' * (ezt találtam rá egy fórumban)
    Ugyanez Double Commander alatt be kell állíítani, hogy a számláló 3 karakter legyen, majd ennyi a szintaxis: [N1:6][C].[E]
    Kész. Totál egyszerű, míg a perl-rename egy halandónak totál katyvasz :(

  • májkimiki

    őstag

    válasz Frawly #6837 üzenetére

    Na ettől kapok agyf.........t!
    [link]
    Nagyjából 3 és fél órája volt rendszerindítás. FF-ban megnyitva 4 lap: PH Fórum, LM.hu, Ubi.hu, HUP.hu, Distrowatch, Tutanota és a Google kezdőlapja. Az idő előrehaladtával egyre jobban lassúl, proci az egekben.
    FF addon-ok: Ublock Origin, PrivacyBadger, Disconnect, CookieAutoDelete, NoScript, FB Container.
    Chromium addon-ok: NoScript és FB Container kivételével uazok.
    Brave-t próbáltam másik rendszeren hasonló setup-al, szintén lassul. Talán a legkedvezőbb mértékben.
    Azzal meg itt bajban vagyok, mert AUR-ból jönne. De a build vége felé elszáll checksum hibával.
    Legszívesebben kivágnám az ablakon a notit A6-ostúl, -stúl, -stúl, -stúl. :O

  • Frawly

    veterán

    válasz Shyciii #6841 üzenetére

    Vifm-ből hívott csoportos átnevezés vim-ben grep/sed-szintaxissal:
    :%s/[0-9]{2}/0\0/g

    Nem teszteltem, de azt kéne csinálnia, amit írsz, a kétjegyű számokat (de csak azokat) átcseréli háromjegyűre. Ha látod a listán, hogy helyesen cserélt le mindent, a végén ZZ billentyűkkel kilépsz vim-ből, és visszakapod a Vifm-et, az átnevezett fájlokkal.

    A „:” parancsmódba teszi le a vim-et, az „s” a substition rövidítése/parancsa (általános alakja s/keresett/cserestring/ formában szokásos), előtte a % jel azt jelenti, hogy az összes sorban hajtsa végre, ne csak az első sorban, a „g” a végén meg a global rövidítése, ami miatt egy soron belüli többször előfordulásokat is lecserél, ez az esetünkben nem szükséges, mert egy sorban egy egyezés lesz, de én megszokásból mindig gyűröm a végére a g-t. A [0-9] számjegyet jelent, a {2} pontosan két előfordulást egymás után (lehetne [0-9][0-9] formában is írni), a \0 a keresett kifejezést teszi oda az extra 0 után pluszban.

    Nem árt megtanulni regexp-pül, mert nem csak csoportos átnevezéshez jön jól, de scriptekben, meg úgy általában linuxoknál, Unix-származékoknál, programozásnál, nem csak vim-ben, de bármilyen regexp képes editorban, prognyelvben, terminálban grep/sed-hez, még a Total Commander, Double Commander is támogatja alternatívaként a saját regexp formátumán felül. Előnye, hogy a Commader-ek [bla][bla] regexpjénél többet tud, rugalmasabb, igaz bonyolultabb is, és nehezebben olvasható.

    Az awk-t én sem szeretem, túl bonyolult a szintaxisa, de ha oszlopszerű adathalmazból akarsz kinyerni oszlopokat, akkor arra viszont könnyebben használható, mint egy posix/grep/perl regexp.

    (#6842) májkimiki: ez ilyen. Főleg, ha ilyen 2 magos, 2 szálas példányod van (vannak erősebb, 4 magos, 4 szálas modellek is), nuku L3 cache, alacsony órajel, alacsony IPC. Ahogy nézem, még hardveres virtualizációt sem támogat. Ha ez vigasztal, Windows alatt még sokkal rosszabb lenne.

    [ Szerkesztve ]

  • BoB

    Topikgazda

    válasz Shyciii #6841 üzenetére

    Ezt azért egy kicsit túlbonyolították...

    perl-rename s/_/_0/ ./*_[0-9][0-9].jpg

    You may corrupt the souls of men, but I am steel. I am doom.

  • Frawly

    veterán

    válasz Frawly #6840 üzenetére

    Frissítésnél opció lett volna a pacman --overwrite kapcsoló helyett a vonatkozó fájlok eltávolítása rm paranccsal, de azt kockázatosnak ítéltem, féltem, hogy letörölve őket működésképtelen lesz a rendszer. Főleg az ilyen polkites cumók veszélyesek, pont hasonló polkit-mókával küldtem már halálba Arch telepítést, ilyeneket nem szívesen törölgetek.

  • májkimiki

    őstag

    válasz Frawly #6844 üzenetére

    Utoljára 4 éve ment Win10-el, akkor is már használhatatlan volt vele. Akkor vettem a szárnyaim alá, egész eddig jól linuxoztam vele.

  • Frawly

    veterán

    válasz májkimiki #6847 üzenetére

    Önmagában még a Win10 elfutogat ilyenen, főleg, ha SSD van alatta, ami nagyon kell is a 10 alá. De ahogy böngészel rajta, meg még fut más is a háttérben, az erőforrások jobban fogynak, mint Linuxon. Az AMD szinte mindig felejtős volt mobil CPU-k terén, most jöttek fel a Ryzen 2xxxU-4xxxU sorozattal az Intel mobil CPU-k szintjére. Prociba integrált GPU-ban mindig is verték az Intelt, ami továbbra is mellettük szól, mert olyan laptopokban, amelyekben nincs dedikált GPU, az IGP sokat számít azonos procierő mellett.

  • májkimiki

    őstag

    válasz Frawly #6848 üzenetére

    HP ProDesk 600 G1 TWR formában érkezik majd az új (csak nekem) konfig. :)

  • Frawly

    veterán

    válasz májkimiki #6849 üzenetére

    Az végül is a teljesítmény szempontjából nem annyira releváns, hogy milyen formában érkezik. Ezek a brand céges gépek annyiból hátrányosak csak, hogy nem fogadnak sztenderd tápot, hanem csak spéci jó bele, ami miatt nehéz bővíteni, meg dedikált GPU-ból is általában csak alacsony profilú jó beléjük. Meg a brand BIOS miatt nem lehet tuningolni őket.

    A Haswell jó tartja magát CPU erőben, 4 magnál főleg, kellően magas órajel, IPC, cache. Főleg, ha később lemegy az ára, akár felbővíthetsz i7-4770-4790(k)-re is, egyelőre az még nem éri meg, túl van árazva a használt piacon, de majd a Ryezenek miatt le fog menni az ára. Nem is értem miért van fent az ára ennyire a 4. gen-es használt inteleknek. Ahogy nézem, ezek még nem is DDR4-esek, csak 3-asok. Egy használt i7-4790(k) árában kb. egy új Ryzen 1600(AF)-et kapni valami B450-es lappal, egyedül annyi veszteség van, hogy ahhoz már DDR4-es memória kell.

    Egyedül a Haswellbe beleintegrált HD4600 GPU nem valami fényességes, az előző generációkhoz képest +60%-kal gyorsabb, de az újabbaktól elmarad, meg nincs benne Vulkan, DX12, OpengGL 4.5, Iris driver támogatás, ennyiből nem öregedett jól. Meg hardveres dekódolásnál sem tud VP8-9-et, HEVC-t, és 60 fps-es 4K-val sem tudom hogy áll, arról nincs infó a neten.

    Úgyhogy hosszú távon szerezz be egy olcsó, használt RX560-570, RX470 kártyát, azoknak a linuxos támogatása is nagyon jó (nem kell zárt driverrel szívni, mint NV-nál), meg mindent támogatnak, teljesítményben is jók.

Új hozzászólás Aktív témák