- One mobilszolgáltatások
- Amazfit Active 2 NFC - jó kör
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Sony Xperia 1 V - kizárólag igényeseknek
- Magisk
- iOS alkalmazások
- Samsung Galaxy A56 - megbízható középszerűség
- Nem növel telepméretet a Galaxy S26 Ultra
- iPhone topik
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
Igazad van, valószínű felesleges windowsos berögződés még régről, de talán így jobban látja mindenki, hogy ezek plain text fájlok, amikben nem kód van, aminek színeződni kéne. A kiterjesztés nélküli (igazából Linux alatt nincs kiterjesztés, az is a név része) fájlokról hiheti az ember azt, hogy binárisok (jó, azok más mappákban vannak, /bin /usr/bin /opt, stb.) vagy scriptfájlok vagy ilyesmi, még ha a scriptfájlok +x attribútummal és fájlkezelőkben eltérő színezéssel jelölve is vannak. Így én megszokásból magamnak is jelölöm, mert pár év távlatából visszanézve ezeket a fájlokat jobban látszik mi van benne, mi lehet a tartalma. Annyiból viszont valóban célszerű lenne dobni a .txt végződést, mert az meg sugallhatja azt, hogy Windowson (tipikusan Notepad-del) készült \r\n sorvéges fájlról van szó. Annak ellenére, hogy a .txt kiterjesztés még a DOS-ból származik, vagy talán CP/M-ből.
A .doc megint megtévesztő lenne, a .list és .text hosszabb. Végül is ez ízlés kérdése. A többiek is írhatnának erre véleményt, érdekes lenne. Akkor lehet még ez érdekes, ha valaki GUI text editort használ, mondjuk GUI fájlkezelőből, ami „kiterjesztés” alapján nyitogatja meg a fájlokat ezzel vagy azzal a programmal, bár ilyenkor meg a kiterjesztés nélküli fájlok is plain text editorban nyílnak meg úgyis.
Nálam szintén régi beidegződés, hogy rövidnév.kiterjesztés nevet adok a fájloknak (és mappáknak is), mikor egy kiterjesztés nélküli „Hosszabb beszédesebb név vagy cím” jobb lenne. Ez még abból az időkből van, mikor DOS alatt a 8.3 névkonvencióra voltunk korlátozva. De ez él valamennyire unix-like rendszereken is, lásd a 2-3 betűs parancsnevek, meg 2-3 betűs kiterjesztések javában.
-
Frawly
veterán
válasz
Archttila
#6925
üzenetére
Itt van a lista, de szerintem sokra nem mész vele. Nem ugyanarra használjuk a gépet, nem ugyanazokra a programokra van szükségünk. Plusz már majdnem másfél éves telepítés, fent van egy csomó szemét, ami egyszer kellett valamihez (egy Window Manager kipróbálásához vagy valami játékhoz), de nem volt leszedve, vagy AUR csomag make dependency-je volt, stb..
Ha ilyen minimalista lehetőségek érdekelnek, akkor ezeket nézd
1) YouTube-on Luke Smith videói, és weboldala, valamint LARBS tárolója a git-en.
2) ugyanitt DistroTube (más néven Derek Taylor) videói és dwt1 néven elérhető gitlab tárolója
3) szintén YT-ról Brodie Robertson videói
4) reddit-en r/linux topik és r/commandline
5) reddit-en unixporn topikban screenshotokról is sokat el lehet lesni a minimalista megoldások közül. Szokták is írni a kép alá leírásba, hogy milyen programok futnak.(#6923) ztsoft: erre nem emlékeztem, hogy a Q-nak vannak ilyen alkapcsolói is. Ez a fenti lista már -Qqn és -Qqm segítségével készült, így külön vannak választva a pacmanos és yay AUR-os csomagok.
-
Frawly
veterán
válasz
Archttila
#6920
üzenetére
Menteni így tudod:
pacman -Qq > csomag_lista.txt
yay -Qq > aur_lista.txtLegközelebb meg ezeket feltelepíted:
pacman -Syu - < csomag_lista.txt
yay -S - < aur_lista.txtAz AUR csomagoknál reklamálni fog a pacman, hogy nem elérhető csomag, de figyelmen kívül kell hagyni, a második yay parancs megoldja.
Bár én nem húzom vissza automatán, inkább kézzel szoktam, mert a cosmaglistában ki szoktam hagyni ezt-azt, amit az új rendszeren más csomaggal helyettesítek.
-
Frawly
veterán
válasz
Shyciii
#6918
üzenetére
Ahogy ubyegon szokta mondani, ez a látóasszonyok topikba való. Innen ezt mi a látatlanban nem fogjuk tudni megfejteni. Neked kell tudni, hogy miket tettél fel, meg htop-ban vagy egyébben megnézni, hogy mi eszi a memóriát. Tippre gvfs vagy cups, vagy valami hasonló kiegészítő, addon.
-
Frawly
veterán
válasz
#63718632
#6915
üzenetére
Igen, ezért kell UUID-ket használni, abból is lehetőleg PARTUUID-t. Mert az jó eséllyel nem változik, akkor se, ha újraformázod a partíciókat. És nincs az, hogy a /dev/sdxX jelölés elmászik. A jó hír, hogy ezt egyszer kell megcsinálni normálisan, utána Arch újrahúzásánál nem kell csinálnod semmit, csak a régi fstab-ot visszahúzni. Ha nincs GRUB, akkor még azt se kell újratelepíteni. Így van az, hogy nálam egy Arch reinstall is baromi rövid, mert se a partíciók, se a bootolás, se semmi nem változik, régi /etc, régi /home/felhasználóm-ból is újrahasznosítok konfigokat. Így az Arch telepítési lépéseiből kimarad egy nagy csomó, ugorhatom is át. Még a csomaglistát is elmentem, amit visszateszek az új rendszer alá. Így lényegében alig-alig hosszabb, mint egy Ubuntu vagy egy Mint telepítése, ha tudja az ember, hogy mit csinál.
-
Frawly
veterán
válasz
#63718632
#6903
üzenetére
Ez a gond nélkül felment mit jelent? Az AUR csomag telepítette, frissítette a dkms kernelmodulokat, initramfs-t, újrabootoltál, és még mindig nem megy?
lsmod parancs mit mutat, használja hardver a modult?
ip link parancs kimenetében látszik a hálózati eszköz?Egyébként meg nem értem mi a káosz oka, a link világosan írja, hogy nem ezt a 8814au-t, hanem a 88xxau-t kell feltenni az AUR-ból helyette. Leszeded a régit pacman -R segítségével, és aur_helpered_neve -S rtl88xxau-aircrack-dkms-git kiadásával telepíted a másikat.
Egyébként meg ezek az AU, és EU-ra végződő Realtek-ek mindig gázak, ezt vásárlás előtt kellett volna megnézni. Mindig az OS-hez veszünk hardvert, és nem fordítva. Én pont most vettem Fiio K3 külső DAC-ot, előre megnéztem menni fog-e, és nem is ért meglepetés, USB-n rácuppantva a rendszerre azonnal használható volt, semmilyen dkms-modul vergődés, forráskódból pörgetés, meg firmware-telepítés meg semmi nem kellett hozzá Arch alatt, pöccre ment az egész, fagyások és bugok nélkül. Ez kétségtelenül előnye a nagy bináris disztróknak, Void és Gentoo alatt dolgozhattam volna vele elég rendesen, mire ment volna.
-
Frawly
veterán
válasz
jimmy399
#6895
üzenetére
Ja, értem. Azt nem tudom milyen Win10 telepítő ez, a hivatalos 1903, 1909-es verziójú, hivatalos Win10 telepítőkön az install.wim lemezkép pont azért 3,99451 GiB-os (maximum 4 289 073 755 bájt), hogy EFI partícióként viselkedő FAT32-partícióról is telepíteni lehessen, ami csak 3,999999999 GiB-os (4 294 967 295 bájtos, azaz 2^32-1 bájtos) fájlokat támogat.
Mindjárt mondanám is, hogy hiba volt FAT-ot szabványosítani EFI partíciónak, de nem arra tervezték, hogy sok gigás wim lemezképeket innen telepíts, hanem rendesen feltelepített OS-t töltsenek be pár megás EFI fájlok, vagy maximum 30-50 megás initramfs, meg Linux kernel induljon el róla. Ez abszolút a Windows Telepítő és MS hibája, hogy a telepítőjükben nem lehet betallózni más partíciókról és meghajtókról az install/wim fájlokat.
-
Frawly
veterán
válasz
jimmy399
#6892
üzenetére
UEFI módban fel lehet venni bármilyen EFI fájl indulását. Ki kéne deríteni, hogy az illető partíción lévő Windows mivel indul, biztos vagy ebben az efibootmgr.efi-ben? De én nem javaslom Windows Telepítő partíció futtatását. A gyártók telepakolják reklámmal, demóval, szeméttel, malware-rel, meg nem is a legfrissebb verzió, ha feltelepíted, napokig frissítgeti magát, 100× újraindulva. Ha Win10 telepítő kell, a MS oldaláról letöltöd a legfrissebb iso-t, és elve a Media Creation Tool-lal kiírja magát USB-re, vagy ha Linxux alatt látogatod meg az oldalt, akkor kimásolod az iso tartalmát egy FAT32-re formázott USB drive-ra, és telepíted azzal, rendes alaprendszert, tisztán, gyártói szemét nélkül, csak a MS Candy Crush és egyéb szemete és live/reklám csempéi lesznek benne default telepítéssel.
-
Frawly
veterán
válasz
Archttila
#6890
üzenetére
RPi-re talán elmegy az Xfce, de a sima Openbox, vagy IceWM vagy hasonló jobb lenne. Meg pdf-nézőnek mindenképp Zathura akkor, ha Single Board Computerről van szó.
A picom bekonfigolható, hogy vsync legyen csak benne (meg hardveres OpenGL gyorsítás, hogy ne szaggasson a grafikus felület, ha görgetsz meg ablakot mozgatsz):
picom --backend glx --vsyncPersze mellette az Xfce saját kompozitorát teljesen tiltsd le.
A Chromium picom-os tiltólistázásával pontosan mit akarsz elérni? SBC-re egyébként Chromium helyett Firefox vagy Pale Moon, erőforrás-takarékosabb. A Chrome, Chromium, és a rajtuk alapuló böngészők, Vivaldi, Opera jobban eszik az erőforrást, ami nagyon korlátozott ilyen RPi-szintű gépeken. A B550-es Ryzenen mindegy, annak nem kottyan meg semmi, de egy ilyen kompakt kis gépnél minden csepp erőforrás-megtakarítás fontos, a sok kicsi sokra megy.
-
Frawly
veterán
válasz
Archttila
#6886
üzenetére
A proc bejegyzés nem szükséges bele, legalábbis én nem tudok olyan felállást elképzelni, ahol kellhet. Vedd ki, legfeljebb mentsd el a mostani fstab-ot biztonsági másolatként, és ha nem bootolna mégse (kötve hiszem, de tegyük fel a legrosszabbat), akkor bebootsz egy Arch-iso-t vagy akármilyen Live Linuxot és visszamásolod a régi változatot.
Pdf-olvasóra Zathura, bár lehet nem fog tetszeni, hogy főleg billentyűzetes irányításra tervezték, ezért nincs menürendszere (de egérrel is irányítható, csak kattitantani nem tudsz mire), de cserébe villámgyors, extra lightweight, pluginekkel kezel Djvu, ps, Comicbook formátumokat is. Esetleg xpdf, mupdf, qpdfview.
Bár attól is függ, hogy milyen formátumok támogatását akarod tőle, milyen grafikus környezetet használsz most. Mert pl. ha KDE, akkor egy Okular is pehelysúlyúbb, mint egy Acrobat Reader vagy egy Foxit Reader. Ha Gnome vagy más Gtk-s felület, Mate, Cinnamon, Xfce, akkor az Evince sem annyira bloat, mert azok a libek, amiket használna, már eleve be vannak töltve a rendszeren.
-
Frawly
veterán
válasz
Archttila
#6882
üzenetére
Tegyük tisztába: UUID-ből háromféle is van egy lemezen, függetlenül attól, hogy GPT vagy MBR/dos. Van a
1) lemez-UUID, ez a partíciós táblához tartozik, akkor generálódik újra, ha újrainicializálod a lemezt, új partíciós táblával
2) PARTUUID, ez a partíciók UUID-je, minden partícióhoz, partíció újra létrehozásával új generálódik
3) fájlrendszer-UUID, ez nem a partícióhoz, hanem a rajta lévő fájlrendszerhez tartozik. Ez formázáskor generálódik újra (pl. mkfs.akármi). fstab-ban az UUID=akár-mi-csoda érték erre az UUID-re utal, ezt szokták UUID-n érteni, amikor ilyen néven emlegetik.Na, már most a te kimenetedben világosan látszik, hogy a blkid-vel a PARTUUID-t kérdezted le, de az fstab-ba a fájlrendszer-UUID-t írtad be, ezért nem egyezik. Bármelyiket megadhatod, de akkor használd következetesen, ne keverd őket.
Ez a jó az Archban, egyszer megszenvedsz vele, megtanulod mi hogy működik, onnantól megtanultad magadnak megoldani, supportálni, semmilyen Calamares, meg Canoical-fasz-ez Installerre, meg Red Hótt supportjára nem leszel rászorulva soha többé, hogy mindenféle csilivili installereken, és 200 megás Gtk-hegyeken keresztül védjenek meg öltönyös-nyakkendős, céges-trenddiktátor idióták.
-
Frawly
veterán
-
Frawly
veterán
válasz
#63718632
#6870
üzenetére
Ha a Secure Boot be van kapcsolva, akkor szopás az UEFI boot, olyan bootmanager kell akkor, ami kezeli a shim-et. Azt nem tudom, hogy a systemd-boot kezeli-e. Sose használtam Secure Bootot, az első, amit kikapcsolok, mert
1) mint védelem nem sokat ér ténylegesen
2) csak megkeseríti az ember életét OS-ek telepítésekor
3) akármilyen OS-en driverek telepítésekorAz ujjlenyomat-olvasónak nem kéne elvileg megkívánnia a Secure Bootot, de ki tudja, lehet azon a gépen fogja. Mondjuk ezekben én nem tudok neked segíteni, mert semmi ilyen flancos dolgot nem használok, se Secure Boot, se ujjlenyomat-olvasó, se Windows Live arcfelismerés, se VR-szemüveg, se multimonitor setup, se 100 gombos 3000000 DPI-s Gaming Pro RGB Ultra egér, se BT-os eszközök, se USB-s vibrátor, se semmi ilyen szarokat nem használok, nem kötözgetek a gépre. Így ilyen spéci dolgokról nem tudok nyilatkozni, hogy mi mit igényel, hogy menjen. Régi vágású vagyok, bekapcsolom a gépet, beépített eszközöket, beépített kijelzőjét használom, egy kijelző, 1 virtual desktop, tapipad, stb..
-
Frawly
veterán
válasz
#63718632
#6868
üzenetére
Tudtommal EFI partícióból nem lehet kettő azonos meghajtón. De pont az az EFI partíció lényege, hogy több OS-nek is elfér rajta az .EFI fájlja, nem írogatják át egymás dolgait, megférnek egymás mellett. A MBR bootnak pont ez a baja, hogy az egyes OS-ek kicserélgetik egymás alatt az MBR indítókódot. Ez UEFI bootnál nincs.
Simán telepítheted az Archot systemd-boottal a Win10 mellé, amennyiben nem használsz Secure Bootot. A Windowst nem a systemd-boot teszi bele a menübe, hanem a Windows alakítja ki hozzá a szükséges dolgokat az EFI partíción, amit az UEFI talál meg. Te csak a meglévő EFI partíción létrehozol 1 mappát meg 2 konfig fájlt, és a végén kiadsz egy bootctl --path=/boot install parancsot. Ez egy teljesen új systemd-bootx64.EFI fájlt fog létrehozni a /boot/EFI/systemd mappában. A Windowst indító /boot/EFI/BOOT/BOOTX64.EFI fájlhoz nem nyúl hozzá egyáltalán, a Windows nem is fog róla tudni, hogy rajta kívül új OS lett telepítve.
-
Frawly
veterán
Ez igaz, az is az, de annyira egyszerű, hogy lényegében egyetlen kicsi .EFI fájl, meg 1-2 hozzá tartozó .conf fájl, nem kell újratelepíteni soha, még Arch újratelepítésekor sem. Elég a .conf fájlban az UUID-ket egyeztetni, és ez elég ahhoz, hogy bármilyen Arch telepítés bootoljon. Nekem már több mint 3 éves az EFI partícióm a rendszer alatt, pedig számtalanszor volt Arch újratelepítve.
Lehetne magát a Linux kernelt is EFI stub fájlként bootoltatni, akkor tényleg nincs semmilyen bootmanager az UEFI-n kívül, de ez Arch alatt tudtommal ez nem megy az initramfs miatt.
GRUB akkor kell, ha valami bonyolultabb bootfelállás van, mondjuk valaki RAID-ről vagy ZFS-ről vagy hasonlóról bootol, vagy UEFI Secure Boot miatt shim kell, vagy MBR Legacy BIOS boot van.
-
Frawly
veterán
Ha az Arch Wiki systemd-boot cikke alapján csinálod, akkor nem kell GRUB-ot sem telepíteni. Az UEFI/EFI bootnak pont az a lényege, hogy az UEFI már önmagában is egy bootmanager, nem igényli további bootmanager feltételét.
Az egyébként önmagában nem baj, ha 9,3 MiB maradt csak az EFI partíción. Ráfért, aminek rá kell. Úgyse történik rá sok írás, sok olvasás, mindegy mennyi szabad hely van rajta.
A HDD kivétele szerintem azt okozta, hogy 1-2 UEFI boot opció mögött a meghajtó elérhetetlenné vált, és ilyenkor sok UEFI BIOS automatikusan törli a bootbejegyzést az UEFI-ből.
-
Frawly
veterán
Nem kell még egy EFI partíció. Nem is lehet belőle egy lemezen egynél több. Használd a Windows EFI partícióját. A Wikire nem kell hallgatni, nekem 100 MB-on elfér nem csak az Arch, hanem régebben mellé fért a Windows EFI is. Ezt a 250-500 megát azért ajánlgatják ilyen linuxos wikikben, mert nem tudják hogy milyen disztróhoz lesz, Debian/Ubuntu-vonalon pl. be tudnak rá halmozódni a régi kernelek, meg azt se tudják, hogy hány OS-t használsz multibootban, és biztos, ami biztos alapon overkill EFI partícióméretet ajánlanak.
-
Frawly
veterán
válasz
Shyciii
#6857
üzenetére
Az Openbox nem dinamikus, hanem stacking WM, ami azt jelenti, hogy az ablakokat floating módban kezeli és azok részben vagy egészben átfedhetik egymást. Az Awesome dinamikus tiling WM, de azok között a legfelhasználóbarátabb.
Az xmonad nekem is magas a Haskell miatt. Akkor már inkább dwm, mert C-ül legalább tudok, az annyira nem átláthatatlan. Amit a dwm-ben nem szeretek, hogy mindenhez patchelni kell, és a patchek nem kompatibilsek automatán, hanem kézzel kell őket beszúrogatni, ami több patchnél egyre nagyobb munka, egyre kényesebb művelet. Igazából a legtöbb dinamikus tiler dwm-klón, az xmonad is, csak C helyett Haskell-ben írva, a Qtile Pythonban, a Spectrewm C-ben (de támogat külön konfigfájlt), stb.. Igazából az awesome is dwm-klónként indult, csak a nyelv változott, amiben írták (C, de konfigjában már Lua-ra épít), de eltávolodott tőle, ahogy adták hozzá a feature-öket.
vim-nél én is abszolút sorszámot használok, sortöréssel, és görgetésnél mindig a sor végére görgetődik le a képernyő, nem csúszik át sor a következő képernyőre (lastline opció). A wildmenu parancskiegészítés csak parancsmódban működik, kettőspont karakter után. Tényleg csak az abszolút minimumot használom a konfigomban. Pont amiatt, amit már írtam. Nem értek egyet azzal, hogy sokan szénné konfigolják, meg hozzáadnak 100 addont minden apró-cseprő dologhoz, és ha véletlenül vanilla vim-hez vagy vi-hoz kell leülniük, jól arcra esnek, mert nem bírják használni, hirtelen a spéci beállításaik és addontengerjük nélkül élhetetlen lesz nekik.
-
Frawly
veterán
válasz
Shyciii
#6854
üzenetére
Itt van a vimrc konfigom, de neked csak az első néhány sor kell (sorszámozás, sortörés, tört sor görgetése, automatikus parancskiegészítés, 24 bites színmélység, színtéma), a többi map, meg let részt még nem ajánlom, nagy részüket én se használom, a let rész meg csak azért van, ha oldalsáv nézetben fájltallózást nyitok meg vim-ben, annak a vizuális megjelenítését olvashatóbbá tegye, de ezt a feature-t is rettenet ritkán használom.
Elindulásnak a vimtutor parancsot ajánlom, meg ezt a netes játékot. Amíg megszokod a módokat, meg a szövegben mozgást.
Mikor én próbálkoztam először vim-mel, akkor elkövettem azt a hibát, hogy próbáltam annyira szénné konfigolni, hogy lényegében úgy működött, mintha csak egy normál szövegszerkesztő lett volna, működött az egér, kurzormozgató billentyűkkel navigáltam, nem kellett módot váltani, stb.. Na, ezt nem szabad, mert egyrészt így soha nem tanulja meg az ember, meg így pont az értelme, legjobb oldala veszik el.
-
Frawly
veterán
válasz
Shyciii
#6852
üzenetére
Az Xmonad nem Haswell-ben, hanem Haskell-ben van írva, de az nekem is meredek, ha ez megnyugtat. Pont a Linux OFF topikban hoztam elő ezt a funkcionális programozás témát, hogy mennyire elvont, erre le lettem oltva, hogy én vagyok hülye, mert ott a szakik a topikban már az 1930-as évek óta használják, meg möhőő, meg jóaz, nekik tökéletesen érthető. Értem, akkor májerkedjenek csak.
vim/neovim mindegy, de idő megtanulni. Nem is a billentyűk jelentését, hanem amikor vim-ben szerkesztesz, sok szövegszerkesztési problémát át kell fogalmazni, nem úgy kell csinálni, ahogy hagyományos editorokban. A vim ugyanis nem arra a filozófiára épül, mint egy hagyományos text editor, hanem egyfajta interaktív sed-nek lehet tekinteni, és inkább text processornak lehet nevezni. Külön meg kell szokni a módokat, az egésznek a logikáját, elsőre idegen lesz. Nekem is nagyon sokszor neki kellett futnom, mire sikerült megszoknom. A lényeg, hogy mikor tanulod, akkor nem a billentyűk memorizálása a legfontosabb, hanem egy újfajta gondolkodás elsajátítása. Eleinte idegen érzés lesz nagyon, mintha az orroddal vagy a lábujjaiddal kéne szövegszerkeszteni, nehezen boldogul vele, aki még csak most kezdte tanulni, türelmet igényel. Érnie kell a folyamatnak, ahogy formálja a gondolkodásod, nem lehet sürgetni, meg siettetni.
Meg igazából a vim-nek akkor van értelme igazán, ha tudsz gépírni. Az egész úgy van tervezve, hogy gépírástartásból legyen vezérelve, és nem nyúlsz ki onnan egérhez, kurzormozgató billentyűkhöz, stb.. A vim egyfajta speciális gondolkodásról, filozófiáról szól, amit ha megtanulsz, nem csak szövegszerkesztésre tudsz használni, hanem mindenfajta szoftver vezérlésére, vim billentyűkiosztást és logikát fogsz használni mindenhol, shell, terminál, fájlkezelő, böngésző, ablakkezelő, médialejátszók, stb.. Lényegében a gépet fogod teljesen máshogy használni, azt fogja eredményezni.
Egy jótanács: mindegy, hogy vim vagy neovim, ha tanulod, akkor próbáld alapállapotában használni, ne konfigold szét őket a saját jelenlegi berögződéseidhez. Ha változtatsz is a konfigon, csak egyszerű dolgokat, sorszámozás, sortörés, magyar nyelvi helyesírás-ellenőrző használata, stb., azaz csak pár sornyi alap dolgot tegyél bele a vimrc-be, de billentyűket ne nagyon szabj át, meg addonokat se telepíts, mert úgy nem a vim-et fogod megtanulni, hanem a saját konfigod használatát.
-
Frawly
veterán
válasz
#63718632
#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.
-
Frawly
veterán
válasz
#63718632
#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.
-
Frawly
veterán
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.
-
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/gNem 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.
-
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.
-
Frawly
veterán
válasz
#63718632
#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
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. -
Frawly
veterán
válasz
#63718632
#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.
-
Frawly
veterán
válasz
#63718632
#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.
-
Frawly
veterán
válasz
#63718632
#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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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 0Az 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.
-
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.
-
Frawly
veterán
válasz
Nagytoll
#6798
üzenetére
Én bebootolnék egy Live Ubuntut első körben. Lehet csak az Arch kernelbe nincs beleforgatva valami speciális Logitech driver, ami kéne neki. Elvileg spéci programot ehhez nem kell felrakni, már önmagában sem kéne akadnia, a Logid csak arra kell, ha az egér speciális funkcióit tudd használni.
-
Frawly
veterán
Így van, ez nincs egy éve, hogy változott. Nagyon vigyázni kell, mert nem csak kernelt, linux-firmware-t kell telepíteni, amik már nem részei a base csoportnak, hanem text editort, man pages-t, meg egy csomó olyan alap dolgot, ami korábban jött a base metacsomaggal lefelé.
Ezért Arch-telepítéskor mindig fel kell csapni az aktuális Wiki-t, nem szabad régi cikkekből, blogokból, régi fórum postokból, régi YouTube-videókból telepíteni, az azokban ismertetett módszereknek már a fele nem él!
-
Frawly
veterán
válasz
Shyciii
#6790
üzenetére
Végül is pastebin.com-ra beteheted idelinkelve. Bár én saját színkonfigot akarok, .Xresources fájlban beállítva, ahogy Luke Smith csinálja, nem is nehéz, de nem volt még időm kísérletezni, hogy milyen színeket adjak meg, hogy kell definiálni őket. Hosszú távon pywal-t fogok használni, ami a színsémát generálja.
-
Frawly
veterán
válasz
Shyciii
#6788
üzenetére
Hosszú távon én is az st-nél fogok maradni. Annyi, hogy annál a színeket akarom először belőni, hogy jó legyen, és utána állok át arra. Természetesen ez a Termite ideiglenes lesz csak. Közben a fura karakterek vim-ben is megoldva, Void bug miatt volt, lecseréltem a Termite-ot az Arch binárisra, az egyelőre nem bugzik. Meg Archra is visszaváltok. Újra se kell telepíteni, mert még megvan a régi telepítés, csak konfigfájlokat, új scripteket kell átmásolnom, meg befrissíteni, 2 hónapja nem volt használva.
-
Frawly
veterán
2 hónapos alapos tesztelés után dobtam az Alacritty-t. Több bosszantó bugja volt:
1) elcseszte terminálos programokban a truecolor színkezelést, pl. vim, amiben hiába van beállítva a :set termguicolors. Ha ezt megkerültem TERM="xterm-truecolor" megadásával, akkor vim-ben jó lett, de a többi alkalmazásban cseszte szét a színkezelést, pl. mc, Vifm. A COLORTERM="truecolor" is be van állítva természetesen, mégse jó, hiába tudja az Alacritty hivatalosan a truecolort
2) nem tud dinamikus ablakcímzést, így nem látszik az ablaklistában, hogy milyen program fut benne
3) nem tud Vi visual módot. Ez a feauture a dev verzióban már benne van, de a stabilba nem fog egyhamar megérkezni.Így visszatértem Termite-ra. Ez sem hibátlan, mert csak nagyon darabos fokozatokban állítja a betűméretet, pl. a 13-16 pixel ugyanakkora betűknek néz ki, és csak 17-től emeli, de akkor meg nagyobbat ugrik vele. Meg vim help-ben vannak ilyen billentyűhivatkozások, amiknél ilyen furcsa ⇔ karaktert jelenít meg, ami összecsúszik a billentyű kacsacsőrök között írt nevével.
-
Frawly
veterán
válasz
Shyciii
#6784
üzenetére
Ja, ez a másik, amit írni akartam. Ha nagyon minimalista valaki, loginmanager sem kell. Csak annyi a kényelmetlensége anélkül élni, hogy bejelentkezéskor be kell írnod a felhasználói nevet is, ami ugyan kényelmetlen, de biztonságilag meg plusz. Még többféle grafikus felület is indítható login manager nélkül, vagy startx után megadva mit futtasson az xinit, vagy a .bashrc-ben bekódolni, hogy ha tty1-ről jelentkezel be X felhasználóval, akkor milyen felület induljon el, ha tty1-ről Y felhaszálóval, akkor mi induljon, ha tty2-ről X felhasználóval, akkor amaz, stb.. Mindig az adott felhasználó .bashrc-jébe kell beleszerkeszteni.
Amire még jók a login managerek, az a képernyőzárolás, de azt meg lehet oldani egyéb lock screen progikkal is, akár GUI-sal, akár CLI lock-olós megoldásokkal konzolban.
Csomagfenntartó szerintem nem hülye, de mivel ő kizárólagosan használja szerintem a LightDM-et, így sose távolította el, és nem tűnt fel neki, hogy maga után hagy dolgokat.
-
Frawly
veterán
válasz
attilav2
#6780
üzenetére
Ennél kicsit több konkrétum kéne, hogy fagyott állapotba kerül. Melyik fázisban fagy meg? Még mielőtt lehúzná az AUR script a binárist, vagy azután, mikor tar.zst csomaggá tömöríti, vagy mikor pacmannal rakja fel? Sőt, még jobb lenne, ha komplett kimenetet tennél be, hogy lássul hol akad meg.
A Chromecast-hez nem értek, de a Chromiumban egy csomó minden nincs benne, ami Chrome-ban benne van. Akármi hiányozhat neki.
(#6779) Shyciii: a szöveges böngészőre jól emlékszel, az a Lynx, de forkjai futnak links, elinks, stb. néven is. Abban találták ki, hogy a linkek között navigálsz kurzorbillentyűkkel, de nem csak fel-le, hanem domainek és előzmények között is. Ezt a navigálási módszert viszont átvették egy csomó más programban, közöttük az mc is támogatja, csak alapból nincs bekapcsolva. Gondolom az egyszeri userek miatt nincs engedélyezve alapból, mert ész nélkül nyomkodnak mindent, nincs önfegyelmük, és nehogy az legyen, hogy valami adatot azért vesztettek, mert rosszat nyomtak.
Ebben különbözik a vi/vim, hogy annak pont az a filozófiája, hogy
1) modális, azaz módok között váltasz, a különböző módokat lehet beragadó Ctrl-nek vagy Alt-nak is felfogni, amit nem kell nyomva tartani, de mégis átértelmeződnek különböző módban ugyanazok a billentyűk
2) mindent gépírástartásban végzel az alfanumerikus részen, nem nyúlsz ki más billentyűkhöz, se kurzormozgató nyilakhoz, se Home, End, Pg Up/Dn, stb., mert akkor ki kéne lépni gépírástartásból, meg egérért sem nyúlsz ki, se funkcióbillentyűkért, se semmiért.Az, hogy eltávolításkor a pacman meghagyja a Lightdm maradványait, az nem a Linux, és nem a Lightdm hibája, hanem az Arch csomagfentartójáé, aki a Lightdm-et csomagolja és frissíti. Ő felejti el a post install/uninstall scriptbe beletenni a szutykok eltávolítását. Ha annyira zavar, akkor az Arch oldalán a Packages részben rákeresel a Lightdm csomagra, ott ha belemész, a linken írni fogja, hogy ki a csomagfenntartó, és lesz hozzá e-mail elérhetőség. Vagy az Arch oldalán a Bugs szekcióban jelented, vagy az Arch fórumán.
-
Frawly
veterán
válasz
Shyciii
#6777
üzenetére
De, tudja alapból az mc. Options → Panel Options → Navigation → Lynx-like motion.
A Lightdm-et rég nem használtam, de az tényleg gáz, hogy maga után hagy szemetet. A felhasználóját távolítsd el az userdel paranccsal. Nekem anno az volt a bajom a Lightdm-mel, hogy instabil volt, igaz azt az akkori Intel GPU driver problémám is okozhatta.
-
Frawly
veterán
válasz
Shyciii
#6774
üzenetére
Kurzorbillentyűkkel a mappák között mozogni az mc is tud, ezt Lynx-módnak hívják. A hjkl gombokkal mozgást pedig vi/vim-módnak.
Eltávolításnál a pacman -Rns kapcsolókkal szedd le a csomagot, mert az minden vonatkozót töröl elvileg, nem csak a függőségeit, hanem konfigfájlokat, meg mindent. Ennek ellenére igazad van, 1-2 rosszul megírt progi, meg csomag hagy maga után szemetet, hiába távolítod el. Igaz ez csak fájlszemét, nem fut, nem foglal memóriát, csak felemészt egy apró tárhelyet, használatban nem lévő fájlokat hagyva maga után.
Meg az is következetlen, hogy a szabvány az lenne, hogy a progik a ~/.config/programnév/ mappába tartják a beállításaikat, erre számos különc progi a ~/.programnév_fájl és ~/.programnév_mappa/ helyen tárolják, ebből meg zagyvaság lesz a home mappában. Szóval a Linux sem tökéletes, valóban.
-
Frawly
veterán
válasz
Shyciii
#6772
üzenetére
A ' jel, egyfajta aposztróf karakter, Shift-et nyomva tartod, és magyar billentyűzetkiosztáson megnyomod hozzá az 1-es billentyűt, ezzel kapsz a Vifm parancssorában (alsó sor) egy ' karaktert.
Olyan, mint a nem nyomdai, hanem írógépes idézőjel ("), de ez csak egyszeres írógépes idézőjel, amit aposztrófnak is használnak.
Az 'a - 'z-vel csak azt akartam írni, hogy a ' jel után begépelek egy tetszőleges, de előre beállított betűt. Minden betű másik mappára van nálam drótozva. Ha a 'c parancsot írom be, akkor az a ~/.config mappába visz. Ha a 'm parancsot, akkor az a mountolásra használt mappámba. Ha a 't parancsot, akkor az a Torrent mappába. A 's a script-es mappámba. Ezeket a vifmrc-ben konfigoltam be kézzel, pl.
mark d ~/Downloads/Ezt a fenti sort 'd segítéségével érem el. De te megadhatsz akármilyen betűt (lehet kisbetű, nagybetű, de szerintem még szám is), sőt, stringet is:
mark blaBla /hozzá/rendelt/mappa
Ezt meg a 'blaBla néven éred el. Nyilván ez már nem lenne praktikus, mert sokat kéne hozzá gépelni. A mark-oknak pont az lenne a lényege, hogy max. 2 billentyűleütésből eléred a rendszeresen használd mappáidat. Ezek a markok olyanok, mint böngészőben a bookmarkok.Az a baj, hogy a Vifm neked kényelmetlen lesz, ha pl. nem tudod használni folyékonyan a vim-et, de szerintem gépírni sem árt hozzá (ahogy vim-hez sem). Sok Vifm-es parancsot akkor fogsz megérteni, ha tudsz vim-ül. Pl. a cw, amire a fájl átnevezése jön elő, azt nem a térdükből szopták a Vifm-esek, meg nem a Burdából vették az ihletet, hanem a vim-nek is van egy cw parancsa, ami ott a change word (egész szó lecserélése). Csak mivel a Vifm nem szövegszerkesztő, hanem fájlkezelő, így ebben nem szavakat, hanem fájlnevet cserélsz le. De pl. ezeknek a mark-oknak a kezelését is egy az egyben a vi/vim-ből vették át. Meg a kijelölés módot is (v vagy V), a G-vel az utolsó sorra ugrást szintén, és még lehetne sorolni sokáig.
Ennek ellenére átszabható minden Vifm-es billentyű, ilyen mc-s, meg Total Commanderes stílusúra, csak sokat kell hozzá konfigolni, meg a Vifm egyik előnye veszne el vele. A vim-mel is ott szokták elrontani a kezdők, hogy minden billentyűparancsot átszabnak, engedélyezik az egeret, kurzorbillentyűket, hogy a Sublime, Atom, Visual Code, stb.-t utánozzák, de ezzel meg a vim lényege veszik oda, a modális-gépírásos filozófia.
-
Frawly
veterán
válasz
Shyciii
#6770
üzenetére
A legutóbb használt két mappa között ' ' (Shift+ 1 1 a magyar billentyűzeten) gombokkal tudsz váltani. Én a :media parancsot nem is használom, az összes fontos mappának adtam könyvjelzőt, amik között 'a - 'z mark-okkal váltok. 'm nálam a külső meghajtók felcsatolására szánt mappa, míg pl. a 'd a ~/Downloads és tudok közöttük váltani.
A .jpg fájlok szűrése: =.jpg Nem kell csillag vagy ilyesmi, csak simán ezeket a billentyűket kell nyomni. Így csak a jpg-ket filterezi be, és VG billentyűkkel az összeset ki tudod jelölni. Lehet elvileg egyszerűbben a :highlight paranccsal, de azzal most nem jön össze. A = jeles filtert zr billentyűkkel, vagy másik mappába átváltással tudod nullázni, mert csak ideiglenes szűrő.
Csak permanens törlésnél megerősítés: vifmrc-be set confirm=permdelete
A megadott kiterjesztésekre tudsz programot megadni a vifmrc-ben. Van benne már pár sor, hogy hogyan kell csinálni, azok alapján készíthetsz saját mintákat, hogy milyen fájltípust mivel nyisson meg megnyitásra, szerkesztésre, konzolban, vagy GUI alatt.
-
Frawly
veterán
válasz
Shyciii
#6768
üzenetére
Lehet valahogy meg is lenne oldható, csak a vifmrc-be kéne hegeszteni hozzá saját makrót, vagy saját scriptet hívni.
Zipet egyébként a Vifm is megnyit, a fuse-zip csomagot kell neki feltenni. Ezt fejlesztik is. Aminek viszont abbamaradt a fejlesztése: rar2fs, fuse-7zip, ne ezekkel van probléma.
-
Frawly
veterán
válasz
Blasius
#6766
üzenetére
Igen, vannak ilyen weboldalak, amik nem töltenek be megfelelően, csak ha kézzel ráfrissítesz, vagy újraírod nekik a címet. Ez viszont mindig az oldal hibája ám. A legtöbb böngésző, szövegszerkesztő, irodai programcsomag (pl. LibreOffice és társai) kezel session-t. Általában minden olyan program, ami fülekkel, vagy al-ablakokkal dolgozik, kezel ilyet.
A legtöbb asztali környezet is kezel session-t, csak be kell kapcsolni, mert default a legtöbbön ki van kapcsolva ez a funkció.
-
Frawly
veterán
válasz
Shyciii
#6764
üzenetére
Bele tudna, ha a fuse-hoz fejlesztett rar2fs és fuse-7zip modult nem lennének lusták a fejlesztők karban tartani. De mivel lusta genyók, ezért nem fordulnak a kódok, egyre több disztró tárolójában nem találhatók meg ezek a csomagok, és így igen, ennek híján a Vifm nem tud ilyen tömörítvényekbe belenézni. A Double Commander saját plugineket használ erre, így annak nem gond.
Bár még így sem lehetetlen ezeket a tömörítvényeket Vifm-ben kezelni, hogy ha ilyen tömörítvényre bekonfigolsz egy RAM drive-ba vagy tmpfs-be történő automata kibontást, vagy valami spéci automata felcsatolást, és akkor kvázi bele tudsz nézni ezekbe. mc-nél is járható út ez.
Egyébként az mc-nek azért van sok kötöttsége, mert nagyon konzervatív, meg sok mindenben az nc-t akarja utánozni. A Vifm meg modern fájlkezelő, és az nem akar semmit imitálni, a vi/vimes irányításon kívül, így az szabadabban konfigolható, könnyebben, rugalmasabban témázható.
-
Frawly
veterán
válasz
Blasius
#6762
üzenetére
Ezt, amit akarsz, többféleképpen el lehet érni.
Lehet suspend-del és hibernációval is. A kettő között az a különbség, hogy suspend-nél a RAM-ban marad a RAM tartalma, áram alatt. Hibernációnál meg kiíródik a háttértárra, és a RAM áramtalanítódik.
De meg lehet ugyanezt valósítani olyan asztali környezet, ablakkezelő használatával is, amelyek tudnak munkamenetet (session) kezelni. Pl. KDE, Gnome, Openbox, Xfce tuti tud ilyet, de még mások is, amit így nem fújok fejből, utána kell olvasni. Ez a session azt jelenti, hogy nem kell suspendelni, vagy hibernálni a gépet, hanem le lehet állítani, normál módon újra lehet bootoltatni, és mikor belépsz grafikus környezetben, újranyitja a leállításkor futó programokat, igaz azokban ilyen fájlok lehet nem úgy lesznek megnyitva, így ez csak akkor működik jól, ha olyan progikat használsz, amik saját maguk is tudnak session-t kezelni, pl. komolyabb szövegszerkesztők, böngészők (Chromium is) tudnak ilyet.
A negyedik megoldási módozat, amit minden grafikus felület tud, hogy automatikus indításba beteszed az általad használt porgramokat, így azok mindig elindulnak boot után, ahogy belépsz grafikus felületre. Igaz ez is csak akkor működik hibernációszerűen, ha ezek a szoftverek tudnak saját maguk sessionkezelést, különben a legutóbb használt füleket, fájlokat meg kell nyitogatni bennük.
Első körben azt kéne tisztázni, hogy pontosan milyen géped van, milyen disztró fut rajta, milyen grafikus felülettel, és milyen programok állandó futtatását szeretnéd konkrétan.
Ha a rendszered lefagy, akkor azt meg nem hibernációval meg munkamenettel kell tompítani, hanem a fagyás okát megszüntetni, tipikusan hardver vagy driverhiba tud fagyást okozni. Derítsd ki az okát, szüntesd meg. Első körben a géped konfigja kéne részletesen, különösképp alaplap, GPU típusa, meg egy inxi -Fxxx kimenet terminálban, hogy lássuk milyen driverek hajtják a hardvereket.
-
Frawly
veterán
válasz
Shyciii
#6760
üzenetére
Legutóbb MS-féle cab meg wim fájlokban kellett belenéznem, hogy windowsos fontokat szedjek ki belőlük. Vagy pl. a Vifm régen ki bele tudott nézni .rar-ba, de már nem fejlesztik a rar2fs modult hozzá, amit használna, már AUR-ból sem fordítható le, eltört. De pl. most legutóbb tar.zst-be se tudott nekem belenézni a Vifm, bár azt Double Commanderrel sem próbáltam még.
Az rTorrent teljesen jó, egy nagy hátránya van, nem tud torreteneket sorba állítani prioritás és letöltési sor szerint, hogy egyszerre csak x db. torrent töltődjön, és az is prioritás szerint. Én emiatt fogom most nemsokára feltenni a Transmission CLI-t. Ha ilyen prioritásos, sorbaállítós igényed nincs, akkor viszont az rTorrent tud minden mást.
Korábban qBittorrentet használtam, az egy korrekt progi, nagyon sokat tud, de Qt-s, és baromira eszi az erőforrásokat. Ugyanaz, mint a Double Commander, de pepitában.
Pythonnal az a bajom, hogy bloat. Bár egyre többet használom matekszoftverekben, meg pl. Curse Radio, PyWal is abban íródott. De ha egy mód van rá, kerülöm, mert bloat nyelv, bloat alkalmazásokat írnak benne.
A modarin256 mc-téma nekem is tetszik, azt használom, de csak mc-ben. Vannak egyébként nála jobb témák, a vimcolors oldalon lehet ihletet meríteni. Vifm-ben jelenleg klasszik kék Norton Commander színsémát használok, egyfajta retrós hatás miatt, mc-ben azért van modarin 256, hogy jobban elkülönüljön.
Bár nekem a színséma mindegy, csak legyen sötétebb, ne legyen túl nagy kontrasztos, ne égesse ki a szemem, és ne legyen ízléstelen, ne legyenek benne rikító színek. A kedvencem a Mozilla Bespin színtéma, de nem rossz a Dracula, Nord, Gruvbox, Solarized Dark, stb. sem. PyWal is szép témákat tud random összehozni a háttérkép alapján, lásd Luke Smith videóját. De nem rossz a Code Dark színséma sem, ami a Visual Code(ium) témája, ezt most legutóbb egy ausztrál gyereknél láttam, egész pofásan néz ki neki neovim-ben Fire Code Mono betűtípussal, az lf is egész jól néz ki neki.
Nálam a színséma már csak azért sem számít annyira, mert átlátszó a terminál, és mikor átlátszó részben valami, akkor fakóbbak, kevésbé kivehetőek a színek, csak valami sötét háttér látszik, meg olvashatók, színesek legyenek benne a karakterek és kész.
-
Frawly
veterán
válasz
Shyciii
#6757
üzenetére
A Vifm sem tud futni önmagában, kell neki a terminál. De ez kifizetődik, amikor már sok terminálos alkalmazás van nyitva, akkor egy csomó libet közösen használnak, nem tölti be mindegyik példány a sajátját. Így 10-15 terminál alig foglal többet memóriában, mint 2-3.
A Tux Commandert rég néztem, akkoriban évekkel ezelőtt nem találtam rossznak. De aztán mikor fő rendszerként váltottam Linuxra, akkor a Double Commandert tettem fel. De mióta áttértem csak terminálos alkalmazásra (mpv, firefox, játékok kivételével), így terminálos fájlkezelésnél maradok. Megmondom őszintén, a Double Commander hiányzik, mert elég zseniális, sokat tud. De hát nagy bloat progi egy terminálos megoldáshoz képest. Néha napján mégis előveszem, ha valami olyan különleges tömörítvénybe kell belenézni, amit a Vifm nem kezel.
A trash-kezelését sose bántottam Vifm-nek. mc-ben nem tetszik, hogy a nézeteit és a billentyűit nem lehet normálisan testre szabni. Vifm-et teljesen testre lehet szabni és saját scriptekkel, makrókkal bővíteni. Na, meg a hatékonyabb vim-es irányítás is mellette szól. Az mc csak a fájlstruktúrában tud vimes billentyűkkel mozogni, de ezzel kifújt.
Nézegettem még Rangert, de a Python miatt kiesik, kerülöm az abban írt alkalmazásokat, és még ott van az „lf” (LF kisbetűkkel), amit még nem próbáltam. Az nnn fájlkezelő sem jött be, nekem túl kevés, amit nyújt.
-
Frawly
veterán
Mondjuk én most szívtam vim-mel. A polybar konfigját szerkesztettem. Valamit félrenyomhattam, mert levágódott a fájl eleje. Nem vettem észre, felülmentettem, és szétcsesződött az egész konfig. Vagy 45 percet konfigolhattam újra. Tudom, az én hibám, kellett volna lennie biztonsági mentésnek, de nem volt friss.
-
Frawly
veterán
válasz
Shyciii
#6753
üzenetére
A konfigfájl maga a dokuemtáció Vifm-nél, abba nézz bele, lehet a /usr/share/doc/vifm vagy hasonló mappában lesz egy példaconfig, amit a ~/.config/vifm/vifmrc formában elmentesz, tudsz is használni, meg át tudod szerkeszteni.
A Vifm-nek pont az a lényege, hogy alapból vi-os billentyűkkel működik, cselesen azért is kezdődik vi-jal a neve. Kifejezetten azoknak készült, akik már jók vi/vim használatában, teljesen elsajátították, és szeretnék a fájlokat is ilyen módon kezelni. De átdrótozhatsz bármilyen billentyűre bármilyen funkciót, illetve törölhetsz is róla. A billentyűdefiníciókat ugyanúgy kell írni, ahogy vim-ben.
Pl. tegyük fel, hogy F2-re be akarsz drótozni átnevezést. A ~/.config/vifm/vifmrc konfigfálj végére beteszed ezt:
nnoremap <F2> cwLehet elegánsabban is, de nem tudom mit hív meg a cw billentyűs átnevezés, valami ilyesmit:
nnoremap <F2> :renameVan egyébként a Vifm-nek doksija, ezen az oldalon.
-
Frawly
veterán
válasz
#63718632
#6749
üzenetére
Ez valóban szívás akkor. Nekem sem elérhető a webcíme a PPA-nak. Vagy áramszünet, vagy földbe állt a szerver, vagy az a régió, ahol a neten lóg, túlterhelt, mert mindenki otthonról nyomatja a netet koronakaranténban.
Marad az, amit írtam, átviszed az Ubuntu-rendszerre a pkg.tar.zst csomagot, és kibontod tar segítségével.
Egyébként gáz, hogy még a Deepin kiadású Ubuntu sem tartalmazza ezt a csomagot.
-
Frawly
veterán
válasz
#63718632
#6747
üzenetére
Ubuntunak meg Debiannak ez az előnye. Bináris csomag mindig mindenből van hozzá, sose kell forráskódot fordítgatnod. Lehet PPA-t kell hozzá feltenni, lehet nem a legfrissebb a csomag, de bináris csomag MINDIG van. A legelterjedtebb disztróág, csak a hivatalos tárolóikban van vagy 80 ezer csomag (összeadva a Debian és Ubuntu/Mint tárolókat), és még egyszer ennyi különböző PPA-kban. Tehát olyan sosincs, hogy nem találsz valamihez .deb csomagot, legfeljebb valami nagyon frissen indult git-es hobbiprojektnél tudom ezt elképzelni, de egy Deepin kiegészítő nem ilyen. Tehát ha nem találsz csomagot, az nem azt jelenti, hogy nincs, hanem hogy nem nézted elég alaposan.
-
Frawly
veterán
válasz
#63718632
#6743
üzenetére
Igen, lehet ilyet. Először kibontod a pkg.tar.zst csomagot egy mappába. A dpkg Arch csomagot kell feltenni, és az ebben lévő dpkg-buildpackage segítségével tudsz .deb csomagot csinálni. De nagyon nem ajánlom. El fogja cseszni a függőségeket!!!
Inkább a pkg.tar.zst csomagot vidd át egy az egyben az Ubuntu rendszerre és ott a tar -I zstd -xvf pkg.tar.zst segítségével kibontod egy mappába, ahol portable módban használod, vagy a szükséges fájlokat bemásolod a megfelelő mappákba /usr, stb..
De még inkább javasolt, hogy az illető csomagból keress egy Ubuntu PPA-t, és tedd fel azt az Ubuntu-rendszerre.
-
Frawly
veterán
válasz
Shyciii
#6740
üzenetére
A kijelzőméret relatív, mert az is számít, hogy milyen közelről nézed. 4K felbontásnak meg valóban nagyobb képátlón van értelme, kicsin sem mutat rosszul, csak a kicsi kijelző nem profitál belőle.
Abban igazad van, hogy néhány tiling WM-ben alapból van ablakdísz, de nagyon minimalista, skin nélküli, egyszínű valami. Általában ezeket is eltünteti az, aki ilyen WM-et használ. Skinezni sem lehet ezeket az ablakdekorációkst, csak ki-be kapcsolni, meg bekapcsolt állapotban a színét megadni (ami lehet transzparens is általában, de kivétel biztos ebben is van, ha támogatott is, akkor is kell kompozitor is hozzá). Háttérképnek valóban nem sok értelme van tiling WM-en, hacsak nem használsz az ablakok között rést. Én nem használok, de én szeretem, ha valami szép háttér fogad, és arra nyitom az alkalmazásokat.
A Konsole-ról pont azt írom én is, hogy bloat. Csak példának hoztam fel. st-ből jó a Derek Taylor-féle változat is. A lényeg, hogy ne gyári default st-ből indulj ki, mert azt elég nehéz normálisra bekonfigurálni meg patchelni.
Képmegjelenítés azért kell terminálba, mert néhány terminálos fájlkezelő tud képekről előnézeti képet mutatni, ami hasznos, illetve w3m böngésző is tud ilyet, szintén terminálos. Na most már, ebben az st régen elvérzett. Persze csináltak hozzá patch-t, amit egyébként ráhegeszteni se nehéz, kivéve, ha több másik patch-csel használod együtt, mert akkor rémálom. De azt hiszem, hogy a Luke Smith-féle st patchelve van erre is, talán a Derek Taylor-féle is.
-
Frawly
veterán
válasz
Shyciii
#6736
üzenetére
Ami a terminálokat illeti: nekem a Termite jött be legjobban. Azon terminálemulátorok közül, amik még nem olyan bloatak, mint a Konsole, Gnome-Terminal, xterm, LX Terminal, stb.. A legnépszerűbb most linuxos körökben az Alacritty, de nekem nem annyira jön be, annak ellenére, hogy most én is ezt tesztelem. Kevesebbet tud, nehezebben konfigurálható, kicsit szerintem lassabb is. Valahogy most nagy hype van az Alacritty körül, mert új, meg GPU gyorsított, de ez utóbbi sem számít, mert ha fut hardveres GPU gyorsítást (OpenGL-t vagy Vulkan-t) használó kompozitor a WM felett, akkor úgyis minden alkalmazás kirajzolása GPU gyorsított lesz, az is, ami eredetileg nem volt az.
Az st nem lenne rossz, ha nem kéne minden egyes fontos funkcióhoz patchelni, raádásul a patch-ek is össze tudnak veszi. Alapból nagyon fapados az st, se átlátszó hátteret nem kezel, se görgetést, se truecolor megjelenítést (24-32 bites színmélység), se semmit, problémás a Unicode-emoticonok és néhány betűtípus megjelenítése, képek megjelenítése benne. Ezekre mind van st-patch, de mivel azok meg összevesznek, nehezen szabható testre, egy kínlódás normálisra megcsinálni. Megoldható persze, csak nagyon nem kezdőknek való. Aki mégis megpróbálná, az a Luke Smith-féle st-verziót használja az AUR-ból (megnézve hozzá Luke Smith legutóbbi st-s videóját a YouTube-on), az patchelve van mindenre, full extrássá, igazából viszont ilyenkor az st-nek a minimalizmusos előnye veszik el lényegében.
Igaz a Termite a legjobb, de annak is vannak hibái. Állítólag valami nem rendezett licencű vagy problémás frissítési modellű komponenst használ (már nem emlékszem pontosan), ami miatt nincs benne a disztrók 90%-ánál a hivatalos tárolókban, ráadásul nagyon sok függősége van a fordításának, nem magának a proginak, csak a fordításának. Ezt Gentoo-n tapasztaltam, hogy milyen nagy kínlódás forráskódból pörgetni, Void-on még nehezebb volt. Archon mázli, hogy benne van a hivatalos tárolóban, csak ezt a hajára kenheti az, aki mégse Archot használ, meg nem Arch-vonalat, mert pl. kiadás alapúságot vagy LTS-t akar, vagy systemd-mentes disztrót akar, így meg a Termite nekik egyből nem tűnik a legfrankóbb választásnak. Így most nincs egyértelműen mindenki számára legjobb terminálemulátor. A minmalistábbak st-vel és Termite-tal nyomják, illetve az egyre népszerűbb Alacritty-vel, a full extra bloat DE-s felhasználók meg a DE-jük terminálját használják, ami legtöbbször Gnome-Terminal, KDE-n a Konsole. Ez megint attól függ, hogy ki mire használja a gépet, milyen stílusban, milyen disztrót, WM/DE-t futtat. Vannak emberek, akik annyira GUI only-k, hogy szinte sose szednek elő terminált, amikor csak lehet, elkerülik, nekik meg mindegy. Aki viszont 90-99%-ban terminálos alkalmazásokat használ, annak meg baromi fontos, hogy milyen terminált használ, hiszen a böngésző mellett a legtöbbet használt program a gépükön.
-
Frawly
veterán
válasz
Shyciii
#6734
üzenetére
Tiling WM-ből kettőféle van: automata vagy más néven dinamikus tiler az egyik, ilyen a dwm, spectrwm, Qtile, xmonad (ez a négy ráadásul mind dwm-klón, csak más prognyelveken írva, a dwm és spectrwm C-ben, a Qtile ugyanaz, csak Python-ban, az xmonad meg megint ugyanaz csak Haskell-ben írva, és ezek közül mindegyiket azon a nyelven kell konfigurálni, amelyben írták), bspwm, Awesome WM, meg úgy általában a tiling WM-ek 90%-a dinamikus, amelyeknél egy előre eldöntött szisztéma szerint nyílnak és méreteződnek, illetve rendeződnek a megnyitott progik ablakai.
A másik fajta a tiling WM-eken belül a manuális tiler, i3wm, SwayWM (i3wm-klón csak Waylandre), StumpWM, Musca, Ratpoison. Ezeknél nem megadott szisztéma szerint nyílnak az ablakok, hanem neked kell kézileg nyomni gyorsbillentyűkkel, hogy hova nyíljon, ez pedig egyben meg fogja szabni, hogy mekkora mérete lesz.
A másik nagy csoport a tiling WM-ek mellett a stacking WM-ek, ezek a hagyományos ablakkezelők, amelyeknél nem csempékként rendeződnek a programok, hanem egymást átfedni tudó ablakokban, ilyen a WM-ek 90%-a, meg az összes Desktop Environment-ben lévő WM. Stacking WM-nél másik különbség, hogy az ablakoknak vannak fejlécei és diszitései is, míg tiling WM-eknél nincsenek, legfeljebb csak ablakkeret, vagy opcionálisan rés az ablakkeretek között, igazából ezek nem is ablakok, meg ablakkeretek, hanem csempék és csempekeretek (opcionális), és csempék közötti rések (opcionális).
Egyébként ezek a memóriafoglalási számok, amiket írtál, nekem soknak tűnnek. Nálam az Openbox foglal kb. 170 MB memória körül Polybarral, és feh háttérképpel. Igaz nálam nem fut semmilyen systemd-s szutyok, se gvfs, se dokk, se semmi. Egy Bspwm még ennél is kevesebbet kéne foglaljon, 130-150 MB körül, dwm 130-hoz közel. Mármint összfogyasztásban, amiben minden benne van, nem csak a WM.
Egyedül az i3wm-es és Qtile-os számaid tűnnek reálisnak, bár azokat is kicsit sokkalom.
Amit írsz, hogy 3 ablak fért egymás mellé tiling WM-ekben és nem láttad bennük rendesen a tartalmat: pont ezért mondtam múltkor, hogy a tiling WM-eknek akkor van értelműk, ha nagy felbontást használsz, és ki is tudod használni, mert nem extrém kicsi képernyőn nyomod (12 col meg alatta), bár a képernyőméret is relatív, mert attól is függ, hogy milyen közelről nézed. De ahogy múltkor beszéltük, még az is eltér, hogy milyen progikat használsz. Aki tiling WM-et használ, az egy olyan célközönség, hogy ők 90-99%-ban terminálos alkalmazásokat használnak fix szélességű fonttal, és 99%-ban billentyűzetről, nem egereznek. Te meg kb. 90%-ban GUI-s alkalmazáskat használsz változó szélességű (proporcionális) betűtípussal, és inkább egérrel dolgozol, ami meg a stacking WM-eknek fekszik inkább.
Én két okból adtam fel a tiling WM-eket: 1) a laptopomon pitscha kis felbontást kell használnom 1366×768, ezeken csempézni esélytelen, mert bélyegkép méretűek lesznek az alkalmazások, 2) az összes tiling WM-nek fogyatékossága, hogy ha fut az előtérben egy full screen vagy stacking módban futni tudó alkalmazás, akkor nem tudnak róla átváltani másik, háttérben futó alkalmazásra, mert nem létezik nekik „háttér”, amiben futna akármi is.
Ahogy én használom a gépet, azt tabbed WM-nek vagy fullscreen WM-nek lehetne hívni, talán inkább az előbbi, de használom az utóbbi módot is, ezek félúton vannak a tiling és a stacking WM között. Tabbednél maximális ablakban futnak a progik, de látszanak a panelek is (vagy alul, vagy felül, ez mindegy), esetleg opcionálisan az ablakkeretek és fejlécek, full screen-nél meg az utóbbiak nem látszanak, csak az alkalmazás maga foglalja el az egész képernyőt. A felhasználásom nekem a tiling WM-hez áll közelebb, mert nincsenek ablakdiszítések, se ablakkeret, se ablakok között rés, billentyűzetről irányítok mindent (sehova nem kattintok, se panelre, se alkalmazásindító menübe), így lényegében maximalizált képernyős tiling WM-ként használom most az Openboxot is, ami pedig stacking.
A Fluxbox és az Openbox elég hasonlóak, ugyanannak a Blackbox nevű WM-nek a leszármazottjai, klónjai. Csak Fluxboxon kapsz egy panelt is, meg egy-két dolgot, ami Openbox-ból hiányzik, meg talán konfigurálni sem XML-ben kell.
-
Frawly
veterán
-
Frawly
veterán
válasz
#63718632
#6725
üzenetére
Igen, ha intenzív lemezművelet van akkor elméletben lehet észrevehetőbb az online TRIM. Meg néhány Linux kernel alatt problémás firmware-ű SSD sem szereti az online TRIM-et. Ezért a disztrók többsége az ütemezettet használja, preferálja. Én használtam mindkettőt, nem vettem észre különbséget.
Van, hogy fájlrendszer is dönt, vannak fájlrendszerek, amik nem támogatják a discard TRIM-et, csak az fstrim-et és fordítva. Igaz kevés ilyen van, ha nem hsaználsz spéci fájlrendszereket, csak a szokásos ext4, FAT32, NTFS, stb., akkor mindegy. Ez csak ilyen f2fs és hasonló spécibb vagy riktább fájlrendszereken döntő.
Azt is vedd figyelembe, hogy NVMe SSD-n nem kell TRIM, mert más mechanizmus automatán gondoskodik az online (nem ütemezett) TRIM-ről.
-
Frawly
veterán
válasz
Shyciii
#6712
üzenetére
Ezt a 120-140%-ot nem tudom értelmezni. Értem, a 100%-hoz képest, de mi a 100%? Kinek a szemére van az mérve? Ez kb. így magában olyan, mint a 50%-kal dúsabb L'Oréal szempillák. Most lehet én vagyok gyépés, de nem tudok ezekkel mit kezdeni.
A Polybart én is használom, de egy alapabb, gyári defaulttól alig eltérő konfiggal, egyszerű fekete sáv, fehér betűszín, minden jobbra igazítva. Azt nem is tudtam, hogy ilyen jól is tud kinézni. Nekem az nem kell, hogy kattintásra mindenféle jöjjön elő, pláne nem ilyen GUI-s programok, mint az lxtask (htop-ot használok helyette). Mondom, ez felhasználásfüggő is, mert te meg én egész máshogy használjuk a gépet. Te többségében GUI-s programokat használsz arányos betűtípussal és egérrel kattintgatsz funkciókért, én terminális TUI programokat monospace betűtípussal és szinte mindent billentyűzetről vezérelek, leginkább vim-stílusban. Ezt nem értette a másik topikban ubyegon, hogy nem lehet mindent egy felhasználó igényei és szemlélete alapján meghatározni, nem mindenkinek a Mentás Cinmanó lesz az etalon. Nekem sem mindig ilyen volt a felhasználásom, fokozatosan alakítottam ezt ki, és még a jövőben is fog folyamatosan még minimalistább, keyboard only irányba tovább változni.
-
Frawly
veterán
válasz
Shyciii
#6707
üzenetére
Azért, mert nem jó a szemed, vagy messziről nézed a kijelzőt. A szemem nekem sem jó, vagyis ahogy nézzük, mert közellátó vagyok, így közelre inkább jobban látok, cserébe távolra meg szarabbul, szemüveg kéne, de nem hordok. Nekem most egy 12 colos ThinkPad X220 van a mellkasomon (ágyban pihenek), eléggé beletolva az arcomba, simán látom leméretezve is. De tény, hogy ezek az apró betűk fárasztóak.
Kétpaneles fájlkezelőket meg nem is nagyon érdemes tilingban futtatni, hacsak nincs 2K/4K felbontásod. Ezek anno pont azért jöttek két panellel egy helyett, hogy egyfajta tiling effektként több infót jelenítsenek meg egymás mellett, több infót tudjanak zsúfolni ugyanakkora területre. Tilingban úgy lenne értelme, hogy 2-3 darab 1 paneles fájlkezelőt futtatsz.
Egyébként meg attól is függ, hogy TUI vagy GUI programokat tilingolsz-e. A GUI-s programokban változó szélességű fontok vannak, pl. az i sokkal kevesebb helyet foglal, mint egy m. A TUI-s programok ugyebár monospace fontokat használnak, amik sor/karakter arányban azonos méretnél jobban pazarolják a helyet, viszont lekicsinyítve jobban is olvashatók (a screenshotodon a terminál a legolvashatóbb). Te ahogy látom, GUI-s progikat használsz inkább, én meg TUI-sakat, Writer helyett vim, Double Commander helyett vifm.
Egyébként mi ez a panel nálad felül? Elég jól néz ki, a neve mellé konfigfájlt is linkelhetnél. Előre is kösz.
-
Frawly
veterán
válasz
Shyciii
#6694
üzenetére
Nézd, nem vitatkozni akarok, meg azt úgyse vitatnám, hogy normális 1-2 monitoros desktop megoldás a legjobb. De akik ilyen 2 monitorral, meg többféle programmal egyszerre dolgozó fejlesztők, azok úgyse laptopon fognak dolgozni, és nem csak a kijelzőméret miatt.
Én csak annyit mondok, hogy de, a laptop képernyője is alkalmas lehet már tilingra. Inkább függ a felbontástól, mint a tényleges képátlótól. Meg attól is, hogy kinek milyen jó a szeme. Nyilván egy értelmes szintig, mert 5-12 colon nyilván nem sok mindent lehet csinálni, még full screenben is pici, komoly, tartós munkára alkalmatlan ez a méret.
Én egyébként a laptopon full screenben nyomatok mindent, kivéve párbeszédablakok meg 1-2 spéci progi (PCem), ami nem hajlandó teljes képernyőre skálázódni. De erre a szükségmegoldásra is inkább az alacsony felbontás visz rá, 1366×768. Néha, ha kell valami, akkor két részre van osztva a képernyő és ennyi. Ez is ritkán, és többet nem tuszkolok egymás mellé, mert nem látnék belőle semmit.
Szerintem Borland Delphit nem nagyon használ már senki. Régen sem volt népszerű, most meg kb. a kutya sem. Max. a meglévő kódokat fordítgatják vele, de még azokat is inkább FreePascal fordítóval (ami Delphi- és Object Pascal kompatibilis is). Mondom ezt úgy, hogy én régen éveket programoztam Borland Pascalban, és anno szerettem, de eljárt felette az idő, bánom, hogy nem C-t tanultam már akkor is helyette.
-
-
Frawly
veterán
válasz
Shyciii
#6688
üzenetére
Az Xfce-t fel lehet témázni szépre, de akkor nem lesz lightweight. Főleg azóta nem, hogy Gtk3-ra álltak át. A Gnome-ról írtakkal maximálisan egyetértek.
Tilingnak lenne értelme laptopon is. Csak akkor nincs értelme tilingozni, ha kicsi felbontást használsz, vagy kevés terminálos alkalmazást, vagy nem tudod jól kezelni a billentyűzetet, állandóan le kell nézni, idegenkedik valaki tőle. Min. FullHD felbontástól van értelme, olyan embereknek, akik majdnem csak kizárólag terminálos alkalmazásokat használnak, és billentyűzetkezelésük is vagy haladó, vagy tudnak gépírni. Annak, aki kis felbontást használ, ilyen 1366×768, 1280×720, 1280×800, vagy ezek alatt, annak nem nagyon ajánlom, hacsak nem szereti a mikroszkopikus méretű fontokat. Az 1400×900 határeset lehet. Meg annak nem jó még a tiling, aki ilyen GIMP, Darktable, Blender, KDEnlive, Davinci, meg ahhoz hasonló, nagyon GUI heavy programokat használ, ahol 8 ablak, 20 toolbar, 100 ikonnal, tele párbeszédablakokkal, ezt a helyzetet nem szokták a tiling WM-ek jól lekezelni.
Ami a kolléga problémáját érinti, hogy bizonyos mappákat ki akart zárni a fájlkezelőből, doksik megnyitásánál: én ezt fzf-t használó Bash scripttel oldom meg, ami vim-ben nyitogatja a doksikat, erőforrásigénye is 0. Ez WM független, megy bármilyen grafikus felületen, nem kell ilyen mime-akármikkel szenvedni, meg 1000 GUI-s szemét között kibogozni, hogy melyik lehet a hunyó.
-
Frawly
veterán
Mégis tud scrollozni az Alacritty rendesen, csak nincs beállítva rá gyárilag a keybind. Sőt, a 0.4.2-es verzió már Vi módot is tud. Persze erre a Void tárolóiban a 0.4.1-es a legújabb. Már sokszor írtam, hogy miért fontos a frissesség, mindig le voltam hurrogva, hogy a frissesség, bleeding edge rolling a mániám, mert bőven jók azok az ezer éves verziók, amik Mintben, Ubuntu LTS-en, Debian stable-ön vannak. Ja, tényleg mind jó. Jó régi
Az is igaz, hogy ez egy szerencsétlen véletlen is, mivel a 0.4.2 két hete lépett RC fázisba, a végleges változat meg egyetlen órája jött ki, még nem is volt kint, mikor az előző hozzászólásom írtam. Ennyire gyorsan se az Arch, se az Arch Testing, se a Fedora nem követi le, pedig bleeding edge mindegyik.
-
Frawly
veterán
válasz
Shyciii
#6674
üzenetére
Memóriafoglalásra nem vettem észre jelentős különbséget. Abban viszont egyetértek, hogy a GPU gyorsítás nem számít, mert ha a WM felett fut kompozitor vagy be van kapcsolva X.org-on a DRI hardveres gyorsítás, akkor úgyis OpenGL gyorsítani fog minden X.org-os alkalmazást, Firefox, xterm, urxvt, Termite, Alacritty.
Termite-ot én is jobban szeretem, a vim-kijelölésmód miatt. Ez az Alacrittyből hiányzik, meg a görgetése is elég primitív az utóbbinak, Ctrl+Shift+PgUp/PgDn-ra görget, és csak sok sornyit, egy soros görgetést nem találtam benne, ami gáz.
Így csábítana a Termite vissza, de Archon kívül egyik disztró tárolójában sincs meg, így fordítani kell jellemzően, és a fordításának rohadt sok függősége van. Én meg gentoo-zni akarok később, és nem akarok emiatt szívni.
Amivel most kísérletezek, az a Luke Smith által módosított st, azaz a suckless-féle Simple Terminal. Egyedül a színek nem stimmelnek, azért nem vettem még használatba.
-
Frawly
veterán
válasz
Siriusb
#6666
üzenetére
A Double Commandernek valóban volt régen a 0.7.x-es verziók vége felé, és a 0.8.x-es verziók eleje feléig, hogy néha lefagyott. Most már ezt nem tapasztalom, nyugodtan megpróbálhatod. Ez is csak a Gtk-s verziókat érintette, Qt-snél sose tapasztaltam.
Váltani én is szoktam a grafikus felületek között, ha megunok egyet. Bár egy idő után elfogy a variáció, nagy csodát egyik se tesz, valami panel, dokk, vagy menü (indítómenü vagy egész képernyős Dash-szerűség), háttérképkezelő, asztali ikonkezelő kombinációival dolgozik mindegyik, még a tilingok is, csak ott alapból nem fedik egymást az alkalmazások, ahogy stackingnél. Meg a tilingok inkább billentyűzetes irányításra gyúrnak, nem egeresre, ennek ellenére az egeret is kezelik természetesen.
Plusz a kompozitor szokott még más lenni, de ott sem tudsz végtelen variációt, áttetszőség, áttetszőség+elmosás (Aero), árnyék, esetleg egy-két 3D-s effekt (nyúlós ablakok, 3D-s virtuális desktopváltás, ablaknyitó, záródó effektek), és kifújt.
Én pl. most váltottam SwayWM-ről vissza Openboxra, de nem a megunás miatt, hanem systemd függőségének elkerülésére. Amúgy már nem várok semmit a WM-től, alkalmazásaimat megjelenítse, elég mindegyiknek full screen, ablakdekorációk nélkül, meg elég egy háttérkép, áttetsző panel, ezen kívül áttetszőség van egyedül még a terminálon. Semmi más nem kell, se dokk, se asztali ikonok, se indítómenü (arra vagy dmenu_run-t vagy rofi-t használok, esetleg fzf-et használó shell script), se 3D effektek, se semmi. Böngészőn, Steamen, meg Wine-s programon kívül grafikus progikat se futtatok, minden terminálban fut CLI/TUI alkalmazásként. Mindenhez gyorsbillentyű van rendelve, nem kattingatos sehová, semmilyen ikonra vagy menüre.
Így ha megunok valamit, akkor inkább háttérképet, színtémát, betűtípust cserélek. Ennyi is elég szokott lenni megunás ellen újabban.
-
Frawly
veterán
Szerintem az összes ilyen Intéző-szerű fájlkezelő fapad. Ha rendes grafikus fájlkezelő kell, akkor Double Commander-t tedd fel, abból is a gtk-s verzió való Xfce-hez és Cinnamonhoz. Szerintem ez a grafikus fájlkezelők non plus ultrája, az egyetlen, ami pariban van a windowsos Total Commanderrel.
Egyébként a KDE5 belőhető, hogy minden ugyanúgy nézzen ki, mint Xfce alatt. Akármilyen UI elem idegesít, le lehet cserélni, ki lehet iktatni. Lassan már erőforrásigényre is ugyanott vannak, a legújabb Xfce hízott, az egyre újabb verziói a KDE5-nek meg soványodnak (igaz butítják is), így egy szintre ér a kettő.
Persze ha elérsz majd egy még haladóbb szintet, akkor majd saját DE-t alakítasz ki WM-ből, meg valami minimalista panelből.
Ha a legcsilivilibb kell, akkor szerintem csakis KDE vagy esetleg Compiz egy jó témával. Ez a maximum, amit grafikai szépségre ki lehet hozni a Linuxból. De én már fapados WM-ekből is láttam elég szépeket, igazából nem is annyira a WM-en vagy DE-n múlik, mint inkább a háttérkép, színösszeállítás, téma és kompozitor együttesén.
Ha XFCE-t akarsz, akkor nem kell Manjaro-t telepíteni, hanem a meglévő Arch Cinnamonra egyszerűen felteszed az XFCE fullos metacsomagját és login managerben kiválasztod az XFCE-t a Cinnamon helyett, ezt is csak egyszer kell, utána megjegyzi. Az XFCE és a Cinnamon jól megfér egymás mellett, nem vesznek össze, mert mindkettő Gtk3-as.
-
Frawly
veterán
válasz
Shyciii
#6658
üzenetére
Poén lenne, de Void-hoz nincs ilyen. Egyébként meg mi használná ezt az issue fájlt? Nekem a Void ASCII logója sem tetszik neofetchben. Béna, az Arché jobb.
De a voidosoknak egyébként is jó lenne lecserélni a mostani logót, ez a két félkörben egy pötty elég béna és semmilyen, valami dizájnantitalentum tervezhette. Mondjuk egy pipa jel ötletesebb lenne: ✓vagy ✔, esetleg kicsit szögletesítve, hogy nehogy valaki Nike márkajelnek nézze. Esetleg ilyen vonalasan 3D-ben eltolt nagy V, azaz kb. \\// vagy hasonló.
-
#6657
Frawly
veterán
Neil Watts
#6656
Frawly
veterán
válasz
Neil Watts
#6656
üzenetére
Nincs mit, örülök, hogy sikerült. Pont ezért is kérdeztem rá az fdisk kimenetére, mert ezek a blockdev --getalignoff megoldások nem megbízhatóak. Bonyásak is, meg nem tudni mit ellenőriz pontosan, meg hogyan. A legbiztosabb, ha az ember fdisk kimenete alapján saját maga meggyőződik, hogy a partíciók kezdő szektora 512 bájtos szektorbeállításnál 2048-cal osztható-e. A linuxos és modern windowsos particionálóprogik eleve úgy csinálják, hogy osztható, de az ördög sose alszik. Persze az is elég, ha 32-vel osztható (16K-s alignálás), régi SSD-knél és modern HDD-knél elég, ha 8-cal osztható (4K-s alignálás).
Egyébként meg az sem baj, ha a particionálás nem stimmel mondjuk egy EFI vagy boot partíción, mert oda nem történik sok írás, olvasás. De mint nálad is, a több gigás rendszerpartíció eltolása volt rossz, arra figyelni kell.
-
Frawly
veterán
válasz
Shyciii
#6651
üzenetére
Úgy értve a kompatiblitist, hogy elkezdesz scriptelni rá, és van pár olyan megoldása, ami normál Bash-on meg sh-n nem fog menni. Hozzászoktat ilyen nagyon baró, de spéci megoldásokhoz, és ha majd egy sima bash-os géphez kell leülnöd, akkor gondok lehetnek belőle, hogy nem mennek a zsh-n megszokott dolgaid.
-
-
#6647
Frawly
veterán
Neil Watts
#6646
Frawly
veterán
válasz
Neil Watts
#6646
üzenetére
A Samsung 830-ason jó a partícióeltolás. Viszont a WD Blue 3D 1 terás SSD-den az utolsó, azaz harmadik partíció eltolása nem jó, az 1808582337 kezdőszektor nem osztható sem 8, sem 16, sem ezek többszörösével. Talán a Gparted tudja javítani az eloltást, de Live rendszer alól kell csinálni, nem futhat róla a rendszer, míg a Gparted dolgozik azon a partíción.
Az normális, hogy a /dev/sdX-ek ugrálnak, minden bootkor másik meghajtó lesz sda, sdb, stb.. Ezért is kell fstab-ban meg bootmanagerekben /dev/eszköznév helyett partíció UUID-t vagy fájlrendszer UUID-t használni, az nem változik.
-
#6644
Frawly
veterán
Neil Watts
#6638
Frawly
veterán
válasz
Neil Watts
#6638
üzenetére
Ezek alapján minden jónak tűnik. De azért azt kéne tudni, hogy pontosan milyen SSD-kről van szó, gyártó, pontos típus.
Az alignálás valószínű rendben van, de én egy sudo fdisk -l kimenetet megnéznék a biztonság kedvéért.
-
Frawly
veterán
Én még mindig nem látom, hogy mi lenne vele a probléma. Bici esetében a laptopban lévő két GPU okozta a gondot, de ez minden disztrón, sőt, Windows alatt is szopás lehet. Tehát nem az AMD GPU-val volt a gond, hanem, hogy mindjárt kettő is van belőle! Sőt, ha Intel IGP és NV dedikált GPU van, azok között még nagyobb szívás váltani, mert zavarja egymást a kettő, meg NV-hez csak a zárt drivert lehet normálisan használni, amihez mindenféle dkms kernelmodullal kell szórakozni, ami miatt meg a kernel nem frissíthető normálisan, így összességében 100× nagyobb rémálom az 1-2 AMD GPU-s felállásnál.
Egyébként nemsokára teljes használatba veszem az asztali gépet, amit eddig csak néha használtam, akkor is csak offline windowsos játékkonzolnak, és az lesz a fő gépem, Linux is rákerül, majd megírom a tapasztalataim. Nekem egy AMD RX570 van (GCN4), ez az egyetlen GPU a gépben, elvileg vaj simán, mindenféle kernelparaméter és fekete mágiás voodoo varázslás nélkül mennie kéne első pöccre friss Arch installal, a kernelben benne lévő amdgpu driverrel, ehhez csak a linux-firmware-t kell feltenni, meg a mesa-t, és hardveres dekódoláshoz meg a libva-mesa-driver csomagot telepítve. Erre a gépre egyébként lehet Archot teszek, a systemd ellenére is, mert ezen linuxos játék is fog menni, amikkel szívás lehet systemd-mentes disztrón. Még nem teljesen döntöttem el, hogy nem mégis Gentoo lesz-e, de az Arch felé hajlok, mivel kevesebb munkával jár.
-
Frawly
veterán
Jó, te tudod. Nyilván azt használsz, amit akarsz, nem mi szabjuk meg. De ha már egyszer Archon megfejtetted a hiba okát, akkor nem sok értelmét látom fedorázni. Egyébként az Arch ilyen, egyszer kell szívni vele, kiismered rajta a dolgokat, utána viszont kézreáll, kezesbárány, gondod nem lesz vele többet, legalábbis nem lényegi, meg semmi olyan, amit ne tanulnál meg egyszerűen megoldani. Emiatt bőven megéri bele időt feccölni, hosszú távon bőven meghálálja magát.
Ezzel szemben kiadás alapú és félrolling disztróknál minden kiadásban mást csesznek el, és mindig teljesen új felállással szívhatsz, sose tudod mire számíts.
Fedorán egyébként azért nem volt gondod ezzel, mert ott beletesznek mindenféle csomagot, meg kernelparamétert, és ugyan ez az esetek nagyobb részében kényelmesnek tűnhet, viszont sokkal bloatabbá is teszi a rendszert. Archon ezzel szemben minimalista vonalon építkezés a cél.
-
Frawly
veterán
válasz
Shyciii
#6628
üzenetére
Voidot nem használom még régóta. Nem rossz, használható, de az Arch szerintem lényegesen jobb disztró. Én csak azért váltottam, hogy a systemd-t elkerüljem. Ha nem zavar a systemd, mindenképp Archon maradj.
(#6629) Siriusb: ez LVM over LUKS vagy fordítva? Ilyen felállásban ez egyszerű módon nem oldható meg. Én úgy csinálnám, hogy a cél SSD-n létrehoznám a boot partíciót, meg a LUKS partíciót, LVM-mel. Létrehoznám rajta a logikai köteteket meg azon a fájlrendszereket is, és fel is csatolnám. Meg felcsatolnám a régi SSD-n is a fájlrendszereket. Majd egyszerű fájlmásolással mindent átvinnék a két SSD között, fájlrendszerenként. A végén meg az új SSD-n az Arch indulásához módosítani kell a fájlrendszer vagy partíció UUID-it. Lehet van ennél egyszerűbb megoldás, amit nem ismerek.
-
Frawly
veterán
válasz
Shyciii
#6626
üzenetére
A 244 MB valóban sok, én is hasonló csomagokkal tolom, és nálam 160-170 MB között ingadozik (free -m). Kicsit az Arch 211 megáját is sokallom, nálam az sem volt SwayWM-mel 170 fölött soha. Az a 747 telepített csomag Archra reális, nálam is ennyi körül van, Void most 685 csomag, de ezen pl. nincs systemd, meg annak az összes szutyka. Debianon az 1362 csomag nagyon sok, azért nincs minden csomag 2-3 felé szedve. Ezt magyaráztam már ubyegonnak is, de jött azzal, hogy szerinte nem bloat. Közben meg de, csak a Mint is ilyen, amit használ és hozzászokott.
Azért nagyon nem mindegy, hogy csak fele annyi csomagot kell frissíteni, meg fele annyi szutykot betölteni, és a memóriafogyasztás is kb. fele annyi tud lenni egy Mint Cinnamonhoz képest. uby nem értette, hogy nem arról van szó, hogy nem fér bele a 16 GB RAM-ba, hanem minek töltsünk be felesleges szutyokokat, ami azért mégis időveszteség, még ha csak néhány ms is, azért a sok apró összeadódik, meg a sok felesleges csomagra frissítéskor netsávszélt és letöltési mennyiséget pazarolni.
Termite nekem hiányzik egy kicsit, szerettem a vim-mód miatt, de egyrészt ki kell próbálni más alternatívákat is, meg én minden rendszerújratelepítéskor kipróbálok új dolgokat, már csak azért is, hogy változatos legyen, ne legyen unalmas, ismerjek meg más megoldásokat is. Így most lett az Alacritty, de lehet Gentoo-n már egy harmadik megoldás lesz.
Picom nekem mindenképp kell, nem csak az átlátszóság és Aero-effekt miatt, hanem anélkül tearingelnének a mozgó grafikus elemek, pl. játék, videólejátszás, böngészőben oldalgörgetés. Kell a vsync meg a hardveres OpenGL videógyorsítás. Régen Comptont használtam, az is ugyanez a kompozitor, csak a szerző leállt a fejlesztésével, ezért forkolták, és lett belőle Picom, ezt rendszeresen fejlesztik.
Archon SwayWM-et használtam, ami az i3wm waylandes változata. Azon nem kellett kompozitor, mert a waylandes WM-ek egyben kompozitálnak is, de X.org-on kell. Nagyon elméleti esetben, ha a GPU drivere támogatja, akkor X.org-on is be lehet kapcsolni a tearfree opciót, meg a DRI gyorsítást, de ezek nem minden GPU-n állnak rendelkezésre.
Debiannal meg továbbra is az a bajom, hogy konzervatív, relatíve régi csomagverziókkal. Bár ebben fejlődtek, régen, pár éve még sokkal jobban el voltak maradva verziókkal, most már nem annyira vészesen, mint a CentOS. Ennek ellenére én soha nem láttam értelmét a Debiant erőltetni. Használható azért, azoknak, akik ebbe az apt/deb ökoszisztémába szoktak bele, és nem fontos nekik a legújabb verziók és legmodernebb technológiák (Proton, DXVK, Wayland, stb.) használata. Én a helyedben nem erőltettem volna fel az Arch mellé, nincs értelme egyszerűen.
-
Frawly
veterán
válasz
Shyciii
#6623
üzenetére
Végül melyik megoldás működött pontosan?
Debiant nem tudom, nagyon rég használtam már minimal netinstall, sok éve. Mennyi az a sok memóriafoglalás?
Én is Polybar-ral tolom, meg Openbox WM és Picom kompozitor, xautolock + i3lock képernyőzárnak. Login Managert nem használok, 1-es konzolról (tty1) jelentkezve be automatikusan indul a X.org, xinit-be fel van véve az openbox-session. A háttérképet a feh jeleníti meg, terminálnak Alacritty van.
Debian-nál az ath10 drivert azért neked kell feltenni, mert non free csomagként igényel egy firmware-t, és a non free alapból tiltva van rajta, alapból le sem tölt ilyeneket, mivel a Debian szigorúan GNU Free disztró, azaz alapból csak olyan csomagokat érsz el a tárolóból, aminek szabad licence van. Egyébként a Void Linux is ilyen. Meg a Parabola, ami egy Arch-klón. Ezekben, ahogy Debianban is, az első, hogy még telepítéskor vagy közvetlenül telepítés után engedélyezni kell a nonfree tárolót.
-
Frawly
veterán
válasz
Shyciii
#6620
üzenetére
Esetleg még azt lehet csinálni, hogy teljesen megkerülöd a Debian GRUB-ját, és közvetlenül veszed fel a Debian kernelt és initramfs-t az Arch systemd-boot menüjébe, ahogy először próbáltad (GRUB-ból kimásolva a kernelparamétereket). De ezzel az a probléma, hogy ha Debian alatt frissül a kernel, akkor nem fogja megtalálni az új verziót. Mert a Debian beteszi ugyan az új kernelt a GRUB-jába is, de mivel ezt te megkerülöd, ezért nem fog látszani, és a régi kernellel indul a rendszer.
Az, hogy mi mennyit foglal, az attól függ, hogy mit mivel telepítesz. Egyforma csomagoknál azért nem kéne nagy különbségnek lennie.
A Termite nekem is érdekes, mert Archon kívül szinte semmilyen disztrónak nincs benne a tárolójában. Nem is értem az okát. Void meg Gentoo alatt is külön tárolóból kell forgatni. Mivel nem akartam én sem ezen tökölni, így most Voidon Alacritty-t használok, ez se rossz, csak speciális vim-módokat nem tud kijelölésnél és görgetésnél.
-
Frawly
veterán
válasz
Shyciii
#6618
üzenetére
Most én is ezzel küzdök, de Void alatt. Az GRUB-ot használ, és működik ugyan az UEFI boot, de csak akkor, ha F12-t nyomva a boot menüből kiválasztom a void_grub bejegyzést. Egyébként mindig az Arch akar indulni. Pedig az UEFI-ben be van állítva a bootsorrendnél, hogy a void_grub legyen az első.
Amit a entriesről írtam, azt visszavonom. Ez csak systemd-bootnál működik, ami közvetlen kernelt bootoltat initramfs-sel. Ha a Debian GRUB-os, akkor nem kellenek ezek a conf fájlok. Helyette Arch alatt efibootmgr-rel vedd fel a grubx64.efi-t indulásra. Még paraméterek sem kellenek neki, mert a GRUB ezt saját hatáskörben elintézi. A lényeg, hogy az UEFI BIOS találja meg a grubx64.efi fájlt:
sudo efibootmgr -c -L "Debian" -l '\EFI\Debian\grubx64.efi'Vigyázat, az UEFI-nek visszafelé perjel kell, mint Windowsnál. Ugyanis egy DOS-ból származtatott implementáció! Nem a normál linuxos-unixos perjel kell neki. A harmadik kapcsoló az efibootmgr-nél egy kis L, nem nagy i, csak rosszul látszik a Prohardver által használt talpatlan betűtípussal. Arch alól csináld természetesen, ne Debian alól.
-
Frawly
veterán
válasz
Shyciii
#6614
üzenetére
A leírásod alapján jól csinálod pedig. A /boot/loader/loader.conf hogy néz ki nálad? Tudni kéne ugyanis, hoyg indításnak mit adtál meg a debian.conf-ban. Ha GRUB jön a képbe, akkor a grubx64.efi fájllal kell indítani, de mivel nálad van shimx64.efi, ezért lehet mégis az kell helyette, a shim a Secure Bootot intézi, de ehhez a részéhez nem értek, mert én mindig letiltom a Secure Bootot.
A Debian, mint ahogy a legtöbb disztró, felteszi a GRUB-ot, ha kéred, ha nem. Nálam a Void is feltette sajnos, majd kigyomlálom belőle.
Bár annyi előnye lehet, hogy ha végképp sehogy nem boldogulsz, akkor nem a Debiant veszed fel a systemd-boot-os menübe, hanem fordítva, az Archot veszed fel a Debian GRUB-jába.
-
Frawly
veterán
Szerintem meg nem az Arch/Manjaro hibája, vagyis olyan értelemben az, hogy ők nem adják hozzá automatice ezeket a kapcsolókat, vagy úgy fordítják le a kernelt, hogy szükséges a kapcsoló. De ez nem azért van, hogy téged szopassanak, hanem hogy vanilla állapotban tartsák a csomagokat, neked ettől még megvan ez a lehetőséged, hogy kernelparaméterekkel meg egyebekkel szórakozz. Ez az Archnak a „hekkeld magad” filozófiájából ered, ők nem foltozgatnak semmi disztróspecifikus dolgot a csomagokba.
Ehhez képest a Debian, Ubuntu és Fedora vonalán a disztrókészítők tengernyi patcht meg disztróspecifikus beállítást eleve odahekkelnek default, azért megy. Ez hihetetlenül kényelmesnek is tűnik, de ennek is megvan legalább annyi hátránya, csak máshogy jön ki, pl. ha egy vanilla csomagot forráskódból forgatsz (mert nincs meg semmilyen tárolóban, nem hivatalos külső tárolóban sem), akkor néha meg az a szopás, hogy nem fut normálisan a kód valami disztróspecifikus patch-csel összeveszve, ami épp ott csücsül a futó binárisokban. Vagy pl. ilyen külön patcheléssel nem tudják olyan gyorsan kihozni az új verziókat, mindig csak fáziskéséssel tudják kiadni.
Ami az Arch/Manjaro hibája, az az, hogy ezeket az esetlegesen szükséges kernelparamétereket, nem kommunikálják le, de ez részben a kernelkészítők igénytelensége is, hogy nem tartják rendesen karban a dokumentációt. A kerneldoksinak tartalmaznia kéne ezeket a GPU specifikus dolgokat, hogy melyik generációs kártyára milyen kapcsolók kellenek, meg az Arch Wikinek is ki kéne térnie erre, külön felhívva a figyelmet, hogy ilyen meg olyan AMD GPU generációknál erre szükség lehet, fokozottan kell rá figyelni.
De én még az AMD-től is elvárnám, hogy a linuxos driveroldalukon összehozzanak egy általános linuxos Wiki cikket, ahol sorra veszik, hogy milyen GPU generációknál milyen beállítások, driverek, stb. kellenek a főbb disztróvonalakon, hogy használható legyen a ×4rjuk.
És itt most nem az Arch-osokat akarom védeni, hanem azt kell érteni, hogy nem vagy nem csak miattuk szenvedsz, hanem több ember és cég érdektelensége miatt kell szívni, meg küzdeni, mire rájössz ilyen hekkelős megoldásokra.
-
Frawly
veterán
Gondolom a frissebb kernelben megváltozott az amdgpu driver, az tette szükségessé, bár nem tudom mit csinál ez a két kapcsoló, magamtól erre rá nem jöttem volna. Egyébként nem is az a gond, hogy ilyen kernelparaméterekre szükség lesz, hanem nincs lekommunikálva rendesen, és sokszor a kerneldokumentáció sem egyértelmű. Ez utóbbit elég sokan kritizálják is, hogy a kernel doksija nincs rendesen karbantartva, a kernelt fejlesztik ezerrel, a dokumentáció meg le van maradva jócskán.
-
Frawly
veterán
Az, hogy te telepíted fel esetleg a szükséges csomagokat, firmware-t, vagy valami, pl. AMD GPU-s gépről váltasz NV GPU-sra (utóbbinál lényegében muszáj zárt drivert használni). Vagy Inteles gépről AMD-sre, és másik microcode csomag kell. Esetleg a Wi-Fi kártya változik meg teljesen, AUR-ból kell forgatott drivert, kernelmodult feltenned, és emiatt nem működnek a korábbi hálózati konfigok. Nem azt mondom, hogy biztosan így lesz, de még ezen a téren is pozitívabb lehet újratelepíteni. Ha telepítettél már Archot, nem nagy munka újratelepíteni, ha már érted mit csinálsz. Bootpartícióhoz pl. nem is kell nyúlni, bootmanager, bootolási mód is maradhat. A korábbi konfigokat is elmentheted a ~/ mappádból, /etc-ből, stb.. Persze, valamennyi munka újratelepíteni, de nem rosszabb, mint egy problémás rendszer frissítésével küzdeni.
Nem kötelező persze hardverváltozáskor újratelepíteni, azok az esetek, amiket példának említettem, megoldhatók újratelepítés nélkül is, de mégis csak jobb új lappal kezdeni.
-
Frawly
veterán
Én nem frissítgetnék egy olyan rendszert, amit nem használok. Szerintem jobban jársz, ha egy év múlva újratelepíted. Legalább:
1) gyakorlod a telepítést
2) friss lappal kezdesz
3) eladtad a géped alóla, az új gépen lehet már másik hardverkiépítés lesz, és egy frissen telepített rendszer jobban tud ahhoz igazodni. -
Frawly
veterán
Igen, kifoghatsz, de a két frissítés között több nap telik el, akkor kisebb eséllyel következik ez be, mivel sok ilyen pontenciális felemás állapotot átugrasz. Ennek ellenére ez ellen nem lehet 100%-ban védekezni, ezt nem is állítottam.
Legjobban ennek a felemás állapotba esésnek azok vannak kitéve, akik naponta többször is frissítenek.
(#6582) ztsoft: elhiszem, csak furcsa. Elvileg a 4.x-es kernelek is tartalmazták a GMA950-hez a drivert, és elég sok ember GMA950 GPU-s gépen használt különféle disztrókat 4.x-es kernnellel. Azért hitetlenkedek csak.
-
Frawly
veterán
Ezt nem is vitattam, azért is írtam, hogy a pikaur ALKALMAS a feladatra, hogy az egész rendszert frissítsd vele, nem csak az AUR-os csomagokat.
De! Sok felhasználó van vele úgy, ahogy én. Hogy alapból csak a nem-AUR-os csomagokat frissítik, mert azok binárisan jönnek és gyors a frissítés. Az AUR-ost meg ritkán, mert azoknak a nagy része forráskódból újrapörgetős, ami már időigényes lehet, attól függően, hogy milyen nagy és hány AUR csomag van fent. Ezért szokás a normál csomagokat inkább pacman-nal frissíteni, az AUR-os csomagokhoz meg használni az AUR helper/pacman wrapper megoldásokat.
Ennek ellenére te csináhatod úgy, ahogy te szoktad, mindent pikaurral, nincs is ezzel semmi baj. Csak arra írtam, hogy ezzel a kevesek közé tartozol. Ennyi.
-
Frawly
veterán
Ez amúgy milyen laptop volt? Meg melyik 4-es kernelág konkrétan? Mert elég hihetetlennek hangzik, hogy akármilyen 4.x-es kernel teljesen inkompatibilis legyen egy komplett géppel. Még ha valami GPU driver vagy hasonló terén nem is stimmel, akkor is szoktak rá lenni kerülőmegoldások. De örülök, hogy megoldódott végül.
(#6577) Lenry: szerintem egyedül vagy, de nem a napi frissítés miatt, mert az normális, hanem pikaurt nem használnak sokan, akik használnak is, azok is főleg csak az AUR-os csomagokhoz. Persze a pikaur is alkalmas a feladatra. Én pacmannal frissítek, az AUR-os csomagokat ritkábban frissítem (a forráskódból pörgetés miatt), ahhoz yay-t használok.
Egyébként nem kötelező Archon a naponta frissítés. Sőt, akár káros is lehet, mert belefuthatsz két frissítés közötti felemás állapotba, meg nagyon friss bugokba, amiket néhány óra alatt javíthatnak. Biztonságosabb néhány naponta frissíteni.
Én is naponta szoktam egyébként, bár mostanában alig van időm a gépre, ezért csak 3-5 naponta. uby mindig csesztet, hogy nem foglalkozok a Gentoo-val, de tényleg nincs rá időm, az Archra is egyre kevesebb. Az a mázli, hogy Archra nem kell sok időt elégetni, mert az mégis bináris disztró, meg azt már ismerem.
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.
Új hozzászólás Aktív témák
Hirdetés
- Autós topik
- Star Trek
- Okos Otthon / Smart Home
- Azonnali fáradt gőzös kérdések órája
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Horgász topik
- AMD Navi Radeon™ RX 9xxx sorozat
- 3D nyomtatás
- További aktív témák...
- Eladó Steam kulcsok kedvező áron!
- Assassin's Creed Shadows Collector's Edition PC
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Vírusirtó, Antivirus, VPN kulcsok
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- BESZÁMÍTÁS! MSI SUPRIM X RTX 4080 16GB videokártya garanciával hibátlan működéssel
- TELJES KÖRŰ IT BESZERZÉS
- Honor Magic5 Lite 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! Gigabyte H610M i5 13400F 16GB DDR4 512GB SSD RX 6700XT 12GB DeepCool MATREXX 40 650W
- KAMATMENTES Részletfizetés Alienware DELL monitor
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest