- Samsung Galaxy A53 5G - kevesebbet többért
- Fotók, videók mobillal
- One mobilszolgáltatások
- 65 órányi zenét ígér az Audio-Technica új TWS fülese
- Yettel topik
- Samsung Galaxy Watch7 - kötelező kör
- iPhone topik
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
- Sony Xperia 1 V - kizárólag igényeseknek
- Milyen okostelefont vegyek?
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
-
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.
-
csixy
addikt
válasz
Shyciii
#6620
üzenetére
Szerintem az fstabban át kell írni, hogy az efi partíció hova mountolódjon ( /boot), és a két rendszer miatt az efi partíción mappákba kell pakolászni a szükséges fájlokat, hogy a két rendszer ne keveredjen egymással, bár valószinüleg nem lesznek benne tök azonos nevű fájlok. Ekkor már az Arch mintájára meg tudod csinálni a debian systemd bootját is. Ki lesz tömve sajnos így az efi partíció. De a debián ezután is a grub szerint fogja kernelfrissítéskor a fájljait pakolászni és neked sk kell majd ezek után az efi mappába bevongálgatni a szükséges dolgokat sajnos. Egy rendszer systemd bootja tehát csodás és nagyszerű tud lenni, ha eleve úgy van telepítve, két rendszer viszont már zavarja egymást. Két rendszer esetén már a grub sokkal elegánsabban és egymástr nem zavarva tud működni.
-
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.
-
jimmy399
senior tag
válasz
Shyciii
#6550
üzenetére
Teljesen véletlenül vettem észre, hogy nem kapcsol le a kijelző. Mivel ilyen gumiperem van körben egész korán eltakarja a kijelzőt. Általában nem leselkedek a bill és a kijelző közzé hogy kikapcsolta-e magát
Amúgy xset dpms force off-al konzolból ki tudtam kapcsolni a kijelzőt, csak a lehajtásnál volt ez a malőr.
-
jimmy399
senior tag
-
jimmy399
senior tag
válasz
Shyciii
#6543
üzenetére
Nem használok lightDM-et display managernek. Én tettem ignore állásra a logind-ben. Azt hittem hogy az xfce4 power manager lekezeli hogy ha lecsukom a kijelzőt akkor kikapcsolja. De nem. Tettem fel mate-t is ott se kapcsolja ki. Bebootoltam egy másik disztrót pendriverol az elementary os frey-at ami szintén systemd-s asszem, és ott se kapcsolja ki a kijelzőt csukáskor.
Szóval fura hogy nem automatán kapcsolja ki a delles laposom a kijelzőt csukáskor...Néztem én is handler scriptet de nem sikerült mert eleve nincs acpi könyvtáram az /etc/-ben. Systemd-acpid van helyette vag- micsoda...
-
-
Frawly
veterán
válasz
Shyciii
#6478
üzenetére
Igen, az Openbox és az IceWM szerintem az a két legsoványabb WM, ami egy klasszik desktophoz szokott felhasználónak is használható, hiszen DE funkciókat nyújtanak. Az ennél minimalistábban csak power userekenek ajánlhatóak. Jelenleg Gentoo-n nekem is Openbox van, igaz csak átmenetileg, amíg nem találok jobbat. Az Archon használt SwayWM-et dobnom kellett systemd-logind függőség miatt.
-
Frawly
veterán
válasz
Shyciii
#6471
üzenetére
A felhasználód ~/.bashrc-jének a végére ez megy:
if [[ "$(tty)" == "/dev/tty1" ]]
then
startx
fiA ~/.xinitrc-nek a végére meg
exec wm_indító_bináris
Így ha a tty1-en jelentkezel be, és azzal a felhasználóval, akkor a WM automatikusan indul. De csak akkor. Ha tty2-7-en jelentkezel be, akkor nem, és a tty1-en akkor sem, ha másik felhasználóval, pl. root.
-
Frawly
veterán
válasz
Shyciii
#6375
üzenetére
Nincs ezzel gond. Az ilyen minimalista WM-eket azoknak csinálták, akik mindent bill-lel irányítanak, sose egereznek, és szinte csak terminális alkalmazásokat használnak (pl. Double Commander helyett Vifm, Ranger, mc, nnn, stb.). Neked azért nem tűnik élhetőnek. Azzal egyetértek, hogy az Openbox már szinte annyira sovány, hogy annál nem sokkal leszel előrébb egy még fapadabb WM-mel.
Egyébként sokszor nem is a WM határozza meg, hanem hogy mit telepítesz mellé, milyen tálca, milyen rendszerértesítések, milyen appok a tálcára, mik futnak a háttérben.
Pl. nálam egy Gentoo alaprendszer konzolos boot után 29 mega memóriát foglal. Egy Arch meg 100-at. Grafikus felületeket betöltve Xorg+dwm Gentoo-n 52 mega memóriát eszik összesen, mindennel együtt ennyi az össz memóriahasználat. Archon meg 145 MB a Wayland + SwayWM. Persze nem fair összehasonlítás, mert Archon fut a systemd, egy rakat systemd-s szolgáltatás (háttérvilágítás, NTP, stb.), Terminus font kezelés konzolban, Pulseaudio, azaz tele van Poettering-bloat-sallanggal. Ezzel szemben a Gentoo alaprendszerem még nem belakott, így se ALSA, se Pulseaudio, a systemd-nek nyoma sincs, helyette openrc van. De azért szépen látszik, hogy milyen szépen növögetnek a memóriafogyasztások +100 megákkal. Mondom, nem is azzal van baj, hogy a memóriát foglalja, mert szűken, de 16 GB RAM-ba beleférek, persze össze kell húzni, mert alapból csak ilyen 8-10 giga áll üresen. Hanem hogy betölt ennyi komplex szart, aminek a 75%-ára nincs szükségem, fölöslegesen növelve a komplexitást, függőségeket, minél több modul tölt be, annál nagyobb az esélye, hogy valami eltörhet egy frissítéskor, stb.. A Linuxnak pont ez a lényege, hogy a UNIX filozófiának megfelelően minden moduláris és szabadon választható benne, olyan kernellel, olyan init rendszer használsz benne, olyan audiórendszerrel, olyan ablakkezelővel, olyan kiegészítőkkel. olyan témákkal, olyan alkalmazásokkal, amilyet épp akarsz, nem kell azt használni, amit egy öltönyös-nyakkendős céges barom kitalált előre. Pont ez a baja a systemd-nek és a Pulseaudiónak, hogy kötelező használni, mert szinte mindeni rádependel, ezzel meg megsértik ezt az alapelvet.
Felhasználásfüggő is. Nekem teljesen jó lenne az udev + jmtpfs, mert csak egyetlen telót csatlakoztatok. Nekem teljesen felesleges, hogy állandóan fusson a gvfs + gvfs-mtp. A pulseaudio-val is az a gondom, hogy csak a Firefox miatt van fent, és rágok, hogy egy alkalmazás hülyesége miatt fut egy bloat szar. Mert ugyebár az ALSA is megfelelő lenne, a pulseaudio lényegében egy ALSA fölé húzott szerver-kliens alapú vezérlőréteg. Az ALSA önmagában bőven elég lenne, hogy egy alkalmazásnak legyen hangja.
-
Frawly
veterán
válasz
Shyciii
#6375
üzenetére
Akkor lehet rosszul emlékeztem a fogyasztására. És itt nem az a baj, hogy fogyaszt memóriát, hanem akkor is foglalja, ha nem használsz MTP-t épp. Ez itt a gond. Elindul, fut a háttérben. Ha csak addig foglalná, amíg ténylegesen használom, akkor nem érdekelne.
Egyébként elméletben a jmtpfs-t is lehetne automatizálni, egy udev szabályt felvenni, ha az adott usb eszközt csatlakoztatják (ezt ki kell nézni, hogy mit ír ki rá, amikor a teló csatlakoztatva van), akkor automatikusan futtassa le a jmtpfs-ses scriptet. De még nem csináltam ilyet.
-
-
Frawly
veterán
válasz
Shyciii
#6361
üzenetére
De, érdemes, ha minimalista rendszert akarsz. Én pl. ilyen minimalista, majdnem csak terminal only, meg fapad tiling WM-es rendszerre soha nem tennék fel gvfs-mtp-t, felteszi a gvfs-t, meg egy csomó bloat függőséget, futás közben eszik egy csomó memóriát. Persze akinek eleve full extrás DE-s bloat rendszere van, annak mindegy, már nem oszt-szoroz, sőt, azokba sokszor már be is van építve ilyen megoldás.
Minimalista rendszerekre teljesen jó a jmtpfs, annyi kényelmetlensége valóban van, hogy nem teljesen automata (bár azért valami udev szabállyal lehet ki lehetne trükközni) alapból, de mégis stabilan működik.
Nálam úgy van megcsinálva, hogy a Vifm-ből hívom a jmtpfs-ses scriptet, mikor a telefon csatolására fenntartott mappára váltanék bookmark-kal benne, nyilván ehhez a telefont előtte csatlakoztatnom kell bekapcsolt MPT-vel. De működik, még csak kényelmetlennek sem mondanám.
A minimalista rendszerek ilyenek, elsőre észszerűtlennek tűnnek, nem is azonnal lehet beleszokni, egy folyamat, míg átállsz ilyenekre.
-
#63718632
törölt tag
válasz
Shyciii
#6361
üzenetére
Nálam ez a téma úgy jött, hogy két cimbim egyszerre talált meg vele tegnap. Mindegyik a telóját szerette volna usb-n összekötni és fájlokat mozgatni a belső tárhelyről a gépre.
Ezt én eddig bluetooth-al oldottam meg.
Debian-on ez pikk-pakk összejött.
Arch-on meg láthatod a történéseket. Elindultam az Arch Wiki alapján, aztán mikor terminálból ment jmtpfs-el. Arra gyártottam ezt a kis felcsatoló szkriptecskét asztali indítóval.
Jó kis gyakorlat volt ez nekem, nem kellet még ilyet csinálnom.
Cimbi meg fel tudja tenni a gvfs-mtp csomagot és örűl majd, hogy működik. -
-
Laszlo733
aktív tag
-
Frawly
veterán
válasz
Shyciii
#6314
üzenetére
Használd a free parancs kimenetét. Az a legpontosabb. A memóriahasználatot a kernelstatisztikákból kérdezi le, amit a /proc/meminfo cat-elésével is elérhetsz. Az ebben írt adatokat gyúrja át emészthető formában.
Értelmezni meg úgy kell a memóriafoglalást a free kimenetében, hogy össze kell adni a used, shared, buffers oszlopokat, a cache-t nem szabad hozzáadni, mert azt a kernel dinamikusan szabályozza, nem veszi el az alkalmazások elől a memóriát. Ha kell az alkalmazásnak, akkor a kernel felszabadítja a cache-t. Amit a free parancs a „free” és avaible oszlopoknál ír, az viszont nem a valóságot tükrözi.
-
Frawly
veterán
válasz
Shyciii
#6305
üzenetére
Egyik AUR helper sem tökéletes. Hibás vagy nem forduló, felrakahatatlan AUR csomagot bármelyik helpert használva lehet lelni. Ez az AUR mindenképp egy bizonytalan valami, bárki feltölthet rá akármit, nincs ellenőrizve a minősége, meg gyakran az AUR-os csomagot el szokta hanyagolni a gazdája, hosszú ideig nem frissíti, ezért el szoktak ezek törni működésképtelenre.
-
#63718632
törölt tag
válasz
Shyciii
#6284
üzenetére
Igazából én nem tudom megítélni a yay, a trizen és a pikaur közti különbségeket. Nem olyan régóta van kapcsolatom az Arch-al. Jobbára a yay addig kell, amíg feleteszem vele a pamac-aur-t.
Az utóbbi hetek történései is abból adódnak, hogy cimbimnek van két régebbi notija, amik még linuxal tökéletesen működnek. Vele meg sikerült megszerettetni a linuxot, igazából az XP után már nem kívánta a Windowst. Szeret töltögetni tecsőről és találtam is hozzá progikat. Egy gond van, amikor az api változás miatt egy program verzió nem tud működni, amíg az újabb ki nem jön, vagy frissül. Így lett a választás az ArchLabs, mert mindkét notin ez fut a legjobban, egyforma rendszer és itt frissül minden a leghamarabb. Úgy hogy nem kell ppa-zni, .deb-ezni, appimage-zni, snap-ezni, flatpak-ezni. Egy felületen frissül a rendszer és az AUR-os programok is. Ezért kell a pamac-aur csomagkezelő-frissítés kezelő. Ő csak használja a rendszert és így meg frissíti. El is van csodálkozva a frissítések mennyiségétől és intenzitásától.
Mélyebben majd mostantól tudok foglalkozni az Arch-al. -
attilav2
őstag
válasz
Shyciii
#6250
üzenetére
Igen az Arch elég gyorsan megvan a frissítéssel, ha dkms kernelmoduljaid vannak (pl vmware hez kell) akkor kicsit tovább tart a frissítés, feltéve hogy a kernel is frissül. Tumbleweed-en hosszabb a frissítési idő, csak néhány naponta érkeznek frissítések és sok csomag frissül egyszerre, nomeg a zypper lassabb mint a pacman.
-
Frawly
veterán
válasz
Shyciii
#6215
üzenetére
Ezért nem érdemes egy böngészőnél lecövekelni, mert abban vannak a jelszavak, kártyaadatok. Erre password manager való, pl. Linuxra ajánlom a KeyPass X-et. Szépen el tudod menteni benne weboldalanként és bankkártyánként az adatokat, hogy aztán bármilyen böngészőben használd.
Az adatokat AES titkosítással tárolja, egy mesterjelszóval levédve, innentől csak erre az egyetlen egy jelszóra kell emlékeznek.
-
-
Siriusb
veterán
-
Frawly
veterán
válasz
Shyciii
#6173
üzenetére
Így van, látszatvédelem volt, nem töltődött be. Épp ezért nem csak fel kell tenni a csomagot ész nélkül, hanem az Arch Wikin utánaolvasni a használatának és beállításának. Nem díszből írnak hozzá több oldalnyi cikket, persze kezdőknek úgy tűnik, hogy nagyon kockák akarnak csak ott okoskodni, de amit írnak, az pechre mind fontos.
-
Frawly
veterán
válasz
Shyciii
#6069
üzenetére
Pedig a 850 Pro egy elég jó SSD, nincs is rajta NAND cache, csak DRAM cache. Nagyon gyors, klasszik/planár MLC NAND van rajta, még nagyobb csíkszélességen gyártva, így nem csak gyors, de elég strapabíró is. NAND cache ezért is nem kell neki, mert olyan jófajta NAND van rajta, ami nem cache módban is elég gyors, konzisztensen tudja tartani az írást/olvasást, végig a meghajtó teljes tárterületén.
Ezzel a cache problémával inkább nagyon olcsó SSD-ken találkozni, ahol planár TLC, vagy gyérebb 3D TLC/QLC NAND van (A400, BX500, 660p), na, azok tényleg mocskosul be tudnak lassulni, ha kifogy alóluk a cache. Ha viszont sokat másolsz nagy tételben, akkor nyilván nem ilyen SSD-t kell venni.
Illetve nálam áll hegyekben a sok giga RAM is kernel cache-nek, meg az MX300-nak is még normális a cache-elése, nem egy sebességbajnok SSD, de azt a sebességet konzisztensen, belassulások nélkül tartja, így talán én azért nem futottam bele abba, amit írtok.
Egyébként az iotop-pal tudod nézni, ha a rendszer I/O miatt van terhelve.
-
Frawly
veterán
válasz
Shyciii
#6066
üzenetére
Na, a 27% már reálisabb, de amellett még mindig nem kéne akadnia az egérkurzornak. Nálam ilyen nagy SSD-ről SSD-re másolás közben is teljesen simán gördül az egérkurzor, sehol egy megakadás. Pedig mint írtam, sima vanilla Arch, meg lófütykös számítási teljesítményű régi notebook.
De, hogy ha 2-3 hónapja nem csinálta, akkor az van, amit legelőször írtam, hogy ez valami friss bug, vagy a kernelben, vagy valami userspace toolban, ami most jött elő nemrég.
-
Frawly
veterán
válasz
Shyciii
#6060
üzenetére
Morbid, amit írtok, Archon nekem meg nem eszi meg, ext4-ről másolok ugyanarra az ext4 partícióra, egy régi SATA SSD, és a proci sem erős, egy i5-2520M, ami kb. egy asztali közepes C2Q szintjén lehet mindössze, szóval kb. 10 éves szint, másolás közben 5-25% között ingadozik az össz procihasználat (ez már ki van vetítve 4 szálra, a 100% lenne az, amikor az összes szál maximumra lenne terhelve). Az idő java részében közötte van a két szélső értéknek, és 11% körül van. Az is igaz, hogy nálam az SSD sem gyors (MX300), tartós írásnál mindössze 300 MB-ra maxolódik ki, még az sincs meg mindenhol, néha beesik 200 közelébe, pedig SATA3 módban fut, nem ütközik bele SATA2 limitbe.
Kipróbáltam NTFS-ről is ext4-re, igaz az SATA2-re korlátozott SSD-ről ment (mSATA Samsung 860 EVO), de ramdrive-ra másoltam, ami kb. 6000 MB/sec-et tud. Itt sem volt több 33-37%-nál a procihasználat, igaz ezt konzisztensen tartotta, nem nagyon ingadozott. Pedig a legfrissebb rendszerem van Archon, friss ntfs-3g-vel, kernellel, meg mindennel, annyira friss, hogy a Testing tárolóból van a legtöbb minden. Talán ami nálam eltér, hogy terminálos alkalmazásokat használok, meg ultraminimalista waylandes felületet, míg nálatok a grafikus felületnek egy ilyen lemeztartalmat kijelző frissítési bugja dobhatja meg a procihasználatot.
Meg kéne nézzétek, hogy konkrétan melyik folyamat eszi annyira a procit.
-
Frawly
veterán
válasz
Shyciii
#6058
üzenetére
Ebben teljesen igazad van, még ramdrive-nál és NVMe SSD-nél sem lenne szabad 100%-ig tekernie a procit, akkor sem, ha az gyengébb. Épp ezért, én inkább gyanakszok arra, hogy valami újonnan előkerült bug, de tényleg simán lehet, hogy ennyire szuboptimálisra van megírva.
-
Sonja
nagyúr
válasz
Shyciii
#6044
üzenetére
Én ilyenre inkább exFAT-re formázott USB-s külső HDD-t használok. Hamarosan véglegesen bekerül a kernelbe a Microsoft-os exFAT implementáció, így natív lesz a sebessége. Eddig minden cucc (régi 2012-es TV, Dune HD médialejátszó, stb.) szépen kezeli, probléma nélkül. Szvsz érdemesebb átváltanod rá.
-
attilav2
őstag
válasz
Shyciii
#5979
üzenetére
_Nem működik_ sima chromium alatt a hardveres videógyorsítás, akármit is írjon a chrome://gpu alatt. A chrome://flags alatt az unavailable résznél van a hardware video decode, be se lehet kapcsolni. 1080P 60fps youtube videó 30-50% proci terhelés, szóval sima chromium alatt semmilyen videógyorsítás nincs. A chromium-vaapi-bin aur-os chromiumnál sincs vga gyorsítás. Aki gyorsítást akar az felgányolja az ubuntus dev-chromiumot ahogy fentebb írtam. Vagy lefordítja az aur-os chromium-dev csomagot csak győzze kivárni.
-
attilav2
őstag
válasz
Shyciii
#5977
üzenetére
Pontosan milyen vga-d van?
Ez lényeges, mertlinkeltem egy hivatalos Arch fórumos threadet valamelyik fentebbi hsz-ban ahol panaszkodnak hogy nem megy náluk a hw video gyorsítás sima chromiummal egyes intel, nvidia és amd vga-kkal. Ha megnézed a chrome://flags -ot akkor a hw accelerated video decode vagy vmi ilyesmi, enabled -en van? -
Frawly
veterán
válasz
Shyciii
#5891
üzenetére
Ez nem csak az Openboxot fenyegeti, az IceWM-et, meg a többi régi X.org-os WM-et sem fejlesztik már. Egy megoldás van, megtanulsz programozni, forkolod, és karban tartod te.
Elvileg DPI-t a többféle módon tudsz állítani, ~/.Xresources fájlban, X.org beállításaiban, randr-ban. Ennek ellenére megvannak a korlátai, a HiDPI-t semmiképp nem fogja támogatni az Openbox. Kézzel még annyit tudsz rajta segíteni, hogy nagy felbontású kijelzőn beállítasz rohadt nagy betűtípust, 20 pontosat vagy nagyobbat, meg eleve olyan témát választasz, amin nagyobbak a grafikus elemek. Esetleg lehet a Gtk témával is variálni, de olyat még nem csináltam. Körülményes, sok hekkelést igényel, de elérhető, hogy normálisan nézzen ki ultranagy felbontáson, meg nagy képpontsűrűségen is.
-
Frawly
veterán
válasz
Shyciii
#5889
üzenetére
Gondolom az Openbox fejlesztője úgy van vele, hogy amit akart funkciónak, az már benne van, stabilan működik, és lezártnak tekinti a fejlesztést. Ez viszont soha nem jó hozzáállás. Pl. engem az idegesített az Openboxban, hogy témázásnál csak két színű XBM képelemeket támogat, és emiatt nagyon korlátozott, amit designügyileg csinosítani lehet rajta.
-
Frawly
veterán
válasz
Shyciii
#5887
üzenetére
Nyilván az Openboxot úgy értem, hogy felkonfigurálva, panellel, indítómenüvel, stb.. Alap konfigban tényleg fapados lesz klasszik DE usereknek. De még mindig jobb ebben is, mint a tiling WM-ek, mert ott szürke háttér sincs, meg kattintani sem lehet semmire, hogy legalább egy kamu menü előjöjjön.
Az engem is aggaszt, hogy az Openboxot rég nem fejlesztik, több éve, igaz egy éve jött ki belőle új verzió, de abban is minimális változás volt.
-
Frawly
veterán
válasz
Shyciii
#5885
üzenetére
A Gnome szerintem is rossz. Semmit nem lehet rajta állítani. Még ha fel is teszi az ember a Gnome Tweaks-t, akkor is egy csomó dolog állíthatatlan marad, ilyen alap dolgok, hogy hol legyen a panel, meg mi legyen rajta. Fel lehet tenni rá addonokat, de azok sem segítenek minden hiányosságon.
RAM-nál nem a swappiness értékével érdemes játszani, hanem venni kell elég RAM-ot. Min. 8 GB-ra bővítsél, ha kifogod olcsón, van rá keret, akkor 16-ra, igaz az már overkill lehet, bár erősen felhasználásfüggő. A 32+ GB-nak viszont tényleg nincs értelme átlag felhasználásnál, az csak felesleges pénzégetés.
A Sway-en még gondolkodok, mert ez a stabil tárolókban felrakott 1.1.1 jól működik, és végre rátaláltam a redshift-wlr-gamma-control-git AUR csomagra, amivel van újra redshift-elési lehetőség is. De ennek ellenére elkezdem újra használgatni a dwm-et is.
Az Openbox valóban nagyon jó, az a fajta felület, ameddig átlag desktophoz szokott user is le tud menni minimalizmusban. A tiling WM-ek meg az IceWM már túl fapados lehet DE-khez szokott emberkéknek.
-
Frawly
veterán
válasz
Shyciii
#5883
üzenetére
Igen, a KDE és a Gnome3 a két legnagyobb, ami támogat Waylandet. Ezen kívül van a Sway WM, Enlightenment, ami használható. A többi waylandes felület még nagyon demo/alpha állapotban van, nem használhatók.
De én pl. most fogom dobni a Sway WM-et is. Most próbáltam frissíteni a legújabb dev-git-es ágra, erre felcserélődtek a touchpad és trackpoint gombjai, a konfig fájlban az új left_handed disable opcióval sem sikerült helyreállítani. Befrissítettem a többi Sway összetevőt is, wlroots, swaybg, stb., de erre az egész segfault-olt. Most egyelőre a stabil 1.1.1-es van fent az Arch hivatalos tárolóból, ez is relatíve friss verzió, de elegem van belőle, hogy ilyen trehány banda fejleszti. Visszaállok X.org + dwm-re.
Kár érte, mert a Wayland tetszene. Egyszerű, gyors, pattogós. Semmi 1000 éves visszafelé kompatibilitás, vsync-kel kínlódás meg bloatság. De ha a fejlesztők ennyire töketlenek hozzá, hogy nem tudnak rá normális felületet írni, akkor nincs értelme.
KDE-t, Gnome-ot nem teszek fel, túl bloatak. Ezen kívül a Gnome túl fapados is, esküszöm dwm-en többet lehet testre szabni.
-
Frawly
veterán
válasz
Shyciii
#5876
üzenetére
Az SSDM csak a KDE Waylandet támogatja. A GDM jóformán az összes létező waylandes felületet. A LightDM csak X.org-os felületeket.
Ha konzolon jelentkezel be, akkor a képernyő zárolására vannak grafikus programok, pl. i3lock, vagy hasonló, igaz ezek nagyon fapadosak.
Egyébként az Arch + minimalista WM felállásban ez a nehéz. Nem telepíteni, hanem mindent beállítani, testre szabni. Ezeket a DE-kkel készen kapod, de WM-ek alatt mindenről a usernek kell gondoskodnia.
-
Frawly
veterán
válasz
Shyciii
#5866
üzenetére
Lehet, hogy alapesetben lesz benne egy vezetékes kapcsolat, de ha nem lenne, akkor bizony fel kell venni nm-appletben egy vezetékes kapcsolatot, IP-nek dinamikust adsz meg, és mindent default-on hagysz, meg bejelölöd, hogy az legyen az alapértelmezett kapcsolat.
Tint2 elmegy, de a polybar szerintem is jobb.
Én anno LXDM-et használtam login managernek Openbox mellé. De mióta áttértem minimalista megoldásokra, azóta nem használok semmilyet. Egyszerűen konzolon jelentkezek be, és bizonyos konzolok (pl. 1-es, 2-es) úgy van beállítva a bashrc-ben, hogy az adott WM-et indítsa el (SwayWM, dwm) bejelentkezés után automatikusan. Ennek csak annyi a kellemetlensége a login managerhez képest, hogy a felhasználói neved is nekem kell beírnom, nem csak a jelszót. Viszont ezt felfogható egy plusz biztonsági lépésként, mert így a rendszerbe kontárkodóknak nem csak a jelszavad kell kitalálni, hanem előbb a felhasználói nevet is.
A login managereket én azért dobtam, mert fagyogatott a GDM-en és a KDE login managerén kívül az összes, az Intel GPU drivere miatt. Meg a SwayWM waylandes, és azt nem is tudja sok login manager indítani, lényegében csak a GDM támogatná, az meg nekem bloat.
-
#63718632
törölt tag
válasz
Shyciii
#5873
üzenetére
Akkor se működött, ha a /user/share/pixmaps-ba raktam, chmod 777-el. Szintén leírást követve (Arch Wiki-LightDM+Greeter). Az bosszantott, hogy hogy a fenébe tudja pl. a grub könyvtárból meg megjeleníteni az Archlabs háttérképet. Megnéztem ki a tulajdonosa és tadam. Így mindegy is hol van az adott háttétkép, melyik könyvtárban, a lényeg, hogy a root-é legyen.
-
Frawly
veterán
válasz
Shyciii
#5864
üzenetére
Akkor viszont ha van Network Manager, akkor dhchcd-t nem szabad használni, hanem a kapcsolatokat felvenni a grafikus nm-applet-ben. Majd csak utána fognak működni, meg legközelebbi bootolásnál automatikusan kapcsolódni, meg DHCP-ről címet kérni.
Tudom mit beszélek, én is használtam már Archon Openbox + Tint2 + NetworkManager + nm-applet + Wi-Fi felállást.
-
Frawly
veterán
válasz
Shyciii
#5856
üzenetére
De, kapcsolatot létre kell hozni Network Managerben, pl. nmcli-vel. Vagy wifi-menu-vel.
Bár az sem mindegy, hogy vezetékes vagy vezeték nélküli kapcsolatról van szó. Ha csak simán vezetékes, akkor lehet kap dhcpcd automatikus indulásával is IP-t, de Wi-Fi sose ilyen egyszerű, mert ott SSID, jelszó, frekiállítás, stb. van.
Szerk.: látom vezetékes kapcsolat. Ahhoz nem kell Network Managert felrakni, ha nem tervezel másik kapcsolatot használni mellette.
-
vargalex
félisten
válasz
Shyciii
#5860
üzenetére
Nem írtam, hogy scriptekkel kellene telepíteni. Én még soha nem telepítettem úgy... Csak annyit írtam, hogy miért van NetworkManager-ed, ha nincs GUI-d és nincs is hozzá semmilyen config.
A telepítő indításkor alapból indítja a dhcpcd-t, így van net. Viszont ez a service telepítés után nincs engedélyezve, így a már telepített rendszert boot-olva kell egysystemctl start dhcpcd.servicevagy interface specifikusan
systemctl start dhcpcd@interface.servicede ez ott is van a wiki-n.
-
vargalex
félisten
válasz
Shyciii
#5856
üzenetére
Ha nincs GUI, akkor miért raktál fel NetworkManager-t? Ha jól látom, az alapból semmilyen konfigurációt nem tartalmaz, így nem is fog DHCP-n IP-t kérni. Úgyhogy, vagy beállítasz egy connection-t a /etc/NetworkManager/system-connection-s alá, vagy tiltsd a NetworkManager-t és engedélyezd a megfelelő interface-ra a dhcpcd-t.
Ha ez egy szerver, akkor felesleges a NetworkManager. Teljesen jó a systemd-networkd, vagy a dhcpcd. -
Siriusb
veterán
válasz
Shyciii
#5854
üzenetére
Ezek szerint sem netctl, sem más nem zavar be. Egyáltalán hoztál létre nm-ben kapcsolatot?
Pl. nmcli c-vel ki tudod listázni, miket állítottál be. Ha meg fel van telepítve a network-manager-applet, grafikus felületen is ellenőrizheted.Szerk.:
ráadásként átnyálazhatod a logot journalctl -b-vel, abból is kiderülhet, mi a hiba. -
-
Frawly
veterán
válasz
Shyciii
#5843
üzenetére
Nálam i7-2620M prociról van szó (Sandy Bridge), 16 giga RAM, Crucial MX300 SATA3 SSD, Arch Linux Openboxon próbáltam akkoriban, pluginek nélkül az Atomot. Nem mértem hány másodperc, de elég lassú volt minden tekintetben.
A GIMP meg a LibreOffice minden gépen lassan indul, i9-esen, meg Threadripperen is, még az sem számít nekik, ha NVMe SSD-t teszel alá. De csak az első indítás ilyen, ha nem rebootol valaki, másodjára gyorsabban nyílnak meg. De a GIMP-nél meg a LibreOffice-nál nincs gond ugyanezen a gépen, lassan indulnak, de aztán használható sebességgel futnak, nem úgy, mint az Atom.
-
#63718632
törölt tag
válasz
Shyciii
#5818
üzenetére
Köszi szépen és Frawly-nak is. Végül a Yay-t raktam fel. Igaz tényleg csak addig kellett míg a pamac-aur-t telepítettem. Kellett egy grafikus felület a frissítések kezeléséhez és az Aur-os progik frissítéseihez is.
Egyik cimborámnak pakoltam össze a rendszert és van egy-két progi amiből mindig a legfrisebb kell neki. Ezt más disztrókon kivárni akár sok idő is lehet.
Az Ő szempontjából mindegy, hogy a Debian, Mint vagy Arch rendszert nem ismeri, csak használja. Ha baj van, nálam köt ki. A Pamac-al meg feltolja magának a frissítéseket két kattintásból. Én el vagyok ettől puritánabb dolgokkal is. Igaz az Arch-ot csak kóstolgatom. -
vinibali
őstag
válasz
Shyciii
#5798
üzenetére
én pár éve álltam vissza MBR-re, és akkor is csak azért lett pár hónapra UEFI-s bootom, mert akkor azt gondoltam, hogy a TLC-s SSD-hez kívánt 6MB-os szektor eltolás majd komoly előnyökkel jár, (Setting up Samsung 840 EVO SSDs on Linux), de aztán elengedtem. Windows is állandóan módosítgatta a boot sorrendet.
-
Frawly
veterán
válasz
Shyciii
#5793
üzenetére
A HDMI-s gépre még nem tettem fel az Archot, de használtam már Linuxon HDMI-n. Meg kéne jelennie a HDMI-s hangeszköznek a PulseAudio kimenetei között, azt kéne kiválasztani. Ezt alapból nem is mpv-ben kell állítani, hanem a pamixer-ben, hogy a megfelelő kimenetet használja. Valószínű analóg jack kimenetre állítottad, azért nem küldi ki a hangot.
-
Laszlo733
aktív tag
válasz
Shyciii
#5781
üzenetére
Köszi. Próbáltam onnan, de mindig beleütköztem valami hibába. Végül felraktam yay -ból. / lehet ezzel kellett volna kezdenem
/Egy kérdés:
Elvileg a trizen és társai is telepítésre kerültek, de ennek ellenére nincs ott a kis " ufo " fejecske a keresősáv előtt. Ez így normális?
-
Frawly
veterán
válasz
Shyciii
#5744
üzenetére
Ennek egyszerű a megoldása, tegyél fel Qt-s sötét témát, ami hasonlít a sötét Gtk-s témádra. Persze Arch Wiki alapján rá lehet erőszakolni a Gtk-sat is a Qt-s progikra, de ez bugokkal járhat.
Nálam már csak egy Qt-s alkalmazás maradt, a qBittorrent, de le fogom cserélni, úgyis egyre ritkábban használom és egyre alapabb dolgokra. Régen viszont nagy szükségem volt rá, mert elég nagy seedállományom volt, amit nehéz volt gondozni, de ma már ez nem érint.
VLC helyett ajánlom az mpv-t. Notepadqq helyett meg SciTe. De ez egy fejlődési folyamat, ahogy egyre hosszabban használsz Linuxot, úgy fejlődik az alkalmazásválasztékod is, terelődsz az egyre kevésbé bloat megoldások irányába. Lásd KDE helyett már Openboxot használsz, qBittorrent helyett Transmissiont (Delugot nem ajánlom, Pythonban írt, erőforrás-zabáló, lassú), XnView helyett feh-t. Majd fog ez még fejlődni, mire eljutsz te is a terminálos alkalmazásokig, meg a még fapadosabb WM-ekig.
-
vargalex
félisten
válasz
Shyciii
#5762
üzenetére
A transmission valóban kis erőforrásigényű, nem véletlenül alkalmazzák embedded rendszereknél is.
16 MB/s persze nem gond egy x86-os CPU-nak. Az érvelésedet továbbra sem értem, különösen annak fényében nem, hogy úgyis nyitva van több fül a böngésződben. Egy új fül már nem hinném, hogy (sokkal) több RAM használatot eredményezne, mint egy új natív alkalmazás... -
-
aki33
csendes tag
.
Új hozzászólás Aktív témák
Hirdetés
BoB
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Assassin's Creed Shadows Collector's Edition PC
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Xbox Ultimate előfizetések
- Több Lenovo Thinkpad x1 carbon gen 4 / 5 / 6 / 7 X1 Yoga gen3 6-9. gen i7, i5 procik
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest