Sziasztok,
Feltettem egy Debian 11.5-ös Minimal telepítésként, külön feltettem rá Xorg szükséges csomagjait (nem az összeset), egy Bspwm tilling windows manager-t, és az nm-applet (network-manager-gnome csomaggal jött meg) elindítva a polybar esetén egy üres hely jelenik meg, az ikon nem látható, és fizikailag sincsen ott, mert hiába kattintok nem jelenik meg a menü. Az érdekesség, hogy vannak olyan ritka pillanatok, mikor viszont megjelenik, mintha valami más kezelné a hálózati ikont a systemraybe. További infó, hogy az nm-tray-t felrakva sem jelenik meg az ikonja, viszont ott ha kattintok, akkor annak a menüje megjelenik. Ha a transmission-nek engedélyezem a systray ikonját, akkor az rendben megjelenik. Mintha csak a hálózati cuccok systray ikonjával csinálná ezt a galibát. A polybar-os fejlesztő azt mondja, hogy szerine a systray-t valami más alkalmazás használja, azért van ez a gond, de szerintem akkor semmilyen ikonnak nem kellene megjelennie. Külön furcsaság, hogy ha Arch linux-ot teleptek kézzel minimálba ugyanezzel a felállásban, akkor ott nincs ilyen probléma, így ez valami Debian specifikus "érdekesség" lesz. Notification-höz Dunst programot használok.
További infó, hogy ha polybar-t debeug info-ban indítom el, akkor sokszot ez látszik (de nem mindig):
warn: Systray selection already managed (window=0x1c00006)
* Deactivating tray manager
Vagyis olyaan mintha használná tényleg valami, de nem tudom mi, mikor minimal debian-t raktam fel, nincsen más ablakkezelő felrakva. Ha xprop -id -val lekérem a window után kapot értéket, akkor hibát dob, hogy nincs hozzá semmi, mintha nem létezne.
Annyit még érdemes tudni, hogy a .bash_profile -ból indítom a startx-et
[[ -f ~/.bashrc ]] && . ~/.bashrc
if [[ "$(tty)" == "/dev/tty1" ]]
then
startx
fi
És a .xinitrc -ben indítom a bspwm-et:
exec bspwm
Van valakinek ötlete, hog Debian esetén mi okozhatja ezt a problémát?
MEGOLDÁS:
1. Az ablakkezelő startup file-jábe fel kell venni: dunst ~/.config/dunst/dunstrc &
2. Ha nincs fent, akkor a libnotify-bin -t fel kell installálni, és a xinit.rc file-ba bele kell írni: systemctl --user import-environment DISPLAY
Hozzászólások
Fedorán akkor nem jelenik meg, ha nincs hozzá semmilyen hálózati kapcsolat. Például notebook egy szállodában, mielőtt wifit konfigoltam volna. Ellenben a helye ott van, azon jobb egérgombbal el lehet érni a menüt.
A hibaüzenet alapján a te problémád valóban más lesz. A wmctrl parancs talán segítségedre lehet, olvasgasd a doksiját. Amúgy meg Debiant utálom, mert a Debian csomagjait még hátrafelé nyilazást követően lóról leszállva sátorban csomagolták valami i386-oson. Azért nem korábbin, mert korábbin nem fut a Linux kernel. :P Ez utóbbival azt akarom mondani, láttam már olyan bugot, amelyet Debianban meg akartak oldani, évekkel korábban Fedorán is előjött, de a project main ágában már rég javították a bugot, a világ el is felejtette már, a Debianban meg aktuális kínszenvedés volt, mert a project valamelyik középkorból származó még bugos kódja volt forkolva, használva.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Elolvastam a doksiját, de ebből nem látom, hogy miben tudna segíteni.
Most lehet én emlékszek rosszul, de tudtommal a polybarnak nincs default systray támogatása, valami modult be kell izzítani alatta, és akkor is korlátozott lesz, nem támogat lenyíló menüket. Próbálj meg feltenni tesztképpen egy systray-alkalmazást, pl. trayer, nézd meg, hogy azon megjelenik-e az ikon.
Egyébként meg pont ez ezeknek a minimális WM-eknek, bar-oknak a lényege, hogy más workflow-ra vannak tervezve, terminálos-billentyűzetesre. Tehát aki ilyeneket használ, nem nagyon szokott systray-t használni, sem nm-applet-re kattintani, mivel egeret se nagyon használ. Így inkább javaslom, hogy az sxhkdrc-be vegyél fel egy billentyűkombót, és abba drótozd be, hogy arra induljon el terminálban az nm-tui. Polybarban meg csak a szokásos hálózati modult engedélyezd, ami kijelzi, hogy van-e net, esetleg Wi-Fi-nál SSID meg jelerősség. Polybar még tudna olyat, hogy kattinthatóvá teszed valamelyik bar-modul-részt, és arra kattintva is bedrótozhatod ezt a terminálban futtatott nm-tui-megoldást, esetleg még nm-ből a GUI-sat is.
Maga a bspwm nem gond, az tud teljes X, freedesktop, EWMH, ICCCM támogatást, inkább a polybar korlátja lesz ez.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
A polybarnak van systray támogatása. Ezt a megoldásrt Arch Linux alatt már vagy 2 éve használom, csak gondoltam ugyanezt megcsinálom Debian alatt is. Amúgy polybarnál is úgy használom, hogy csak a wifi jelre kattintva jön elő az nm-applet, és jobb clickre el is tűnik, és csak a fő infók látszanak alapból. Meg persze már is le van szkriptezve így (pl hangerő), és ez működik rendben Arch Linuxon.
Kipróbáltam hogy kilőttem a polybar-t, és elindítottam a trayert, és ott sem jelenik meg az nm-applet ikonja, miközben pl a transmission tray ikonja megjelenik. Viszont így most a konzol írt ki két hibaüzenetet:
(nm-applet:5359): libnotify-WARNING **: 20:12:22.096: Failed to connect to proxy
(nm-applet:5359): nm-applet-WARNING **: 20:12:47.123: Failed to show notification: Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached
Libnotify és Dunst-öt használok a notification kezelésére. Pl USB-s eszköz csatolásakor jön is notification.
Van, de 1) nem teljes szintű, 2) alapból nincs engedélyezve a konfigban a systray modul, neked kell beletenni vagy ha már bent van, akkor kivenni a kommentjelet előtte. Azt hittem, hogy ezt nem tetted meg.
Archon a network-manager-applet csomagnak valóban függősége a libnotify, aminek vannak további függőségei, de semmi xfce-notifyd, meg semmi dunst nem kell neki.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
No kipórbáltam a hibaüzenet miatt, hogy feltettem az xfce4-notifyd csomagot (ez nem annyira erőforrászabáló), és bár így is van hibaüzenet:
(nm-applet:6907): nm-applet-WARNING **: 20:27:23.578: Failed to show notification: Error calling StartServiceByName for org.freedesktop.Notifications: Unit xfce4-notifyd.service failed to load properly: File exists.
De így már látszik a polybar alatt az ikon, ahogy a scriptezés meghívja, és reagál is rá. Tehát a notificationnal van valami gond. A dunst kevés hozzá valamiért Debian alatt. Valami speckó csomag hiányozhat neki.
Asszem megvan a megoldás, de még tesztelem pár napot, aztán átírom a topicot megoldvára.
A lényeg, hogy a bspwmrc-be beteszem, hogy induljon el a dunst is a saját configjával:
dunst -config ~/.config/dunst/dunstrc
Csak furcsállom, hogy ez kell, mert az usb-s automount scriptem (nem használok udiskie-t), ott kiírja, hogy csatlakoztattam, tehát valahogy ő mégis látja, hogy fut. Ráadásul az Arch Linux még a Debian minimálnál is minimálabb, és ott ez nem kell. Dehát ez is szép a linuxban, hogy vannak ilyen érdekes kihívások :)
Köszönöm a segítséget mindkettőtöknek! :)
Fura, mert az nm-applet-nek semmi köze sincs sem a dunst-hoz, se az xfce4-notifyd-hez. Anno használtam én is nm-applet-et Arch + Openbox + Tint2 alatt, és semmi ilyen nem kellett neki. Utoljára akármilyen rendszerikonom Sway alatt volt, a swaybar-on, ott is simán működött, igaz akkor már nem nm-applet, hanem még qBittorrent, Steam, stb.. Most már jó ideje semmilyen systray-t nem használok, polybar helyett is lemonbar-t, ami nem támogatja őket. Értesítéseket sincsenek nálam, azokat különösen utálom, mert elvonják a figyelmem, zavaróak. Anno Windows meg KDE alatt is ez volt a halálom, hogy minden nyomta az arcomba a hülye értesítéseit. Ezek nyilvánvalóan WM-nél és dunstnál nem játszanak, de akkor se szeretem.
Dunst ettől független, annak futnia kell, ha értesítéseket akarsz, különben hiába küldözgetsz neki értesítéseket, nem lesz demon, ami lekezelje. Ez független bármilyen systray-től, és nm-applet-től. Csodálkozok, hogy a Debian minimal ennyire más, mint az Arch, hogy semmi nem működik rajta. Elvileg ugyanannak kéne lennie, mindkettő épp úgy minimális, systemd-s disztró, ha mindkettőre felteszed ugyanazokat a csomagokat, és konfigfájlokat, akkor azonosan kéne működniük. Lehet valami nonfree tárolót nem engedélyeztél, esetleg a Debian még egy régi verziót használ, aminek mások a függőségei. Esetleg a Debian kihagyott valami feature-t valamelyik csomag fordítása során. Tippelgetek csak.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Hát ez az, ezért mondom, hogy fura. Főleg hogy Arch Linuxon minden további nélkül működött ezen beállítás nélkül, dehát hiába mindkettő linux, azért nem kevés különbség van. Arch-ot összességében már tán 5-6 éve nyomom, és tán 3 éve nagyon durván minimalizálva (180MB-ot foglal most épp tisztán, amit lehet scriptel oldok meg, és nem plusz csomaggal), de totál csupaszon sem volt erre szükség. Debian minimal install, csak standard utillities. és mégis ez van. Systray-t én is csak az nm-applet miatt "használoK", de mivel baromi ritkán kell, így nem is töltődik be, csak ha szükség van rá. A fényerő, hangerő, hangkikapcs minden scriptezve fut nálam. Amúgy a libnotify felkerül a debiannal is alapból, de az önmagában kevés, attól még kell egy daemon is, erre használom a Dunst-ot, mert alig foglal valamit.
Én is meglepődtem, hogy ekkora különbség van köztük .Az még oké, hogy jópár csomagnak más a neve, de az hogy Debian a csomagokat ennyire szétdarabolja, hogy most majdnem 1200db csomag van, míg ugyanezzel a megoldással Archon 700db csomag alatt vagyok. A nonfree tároló és a contrib is engeyélezve van alapból, mert nonfree-s telepítőt használtam, mert a debian nem ismeri az ath10-es drivereket (Arch azt is ismerte alapból).
Amúgy Openboxot én is használtam anno. Az volt az első lépés a minimalizálás felé :D Sway-en én is gondolkodtam már, de mivel sok program még mindig ragaszkodik az X11-hez, így a sway is max leemulálja, akkor úgy nemigen van értelme, pedig végre végetérhetne az X11-nek, mert eléggé elavult.
Polybarhoz amúgy 2 dolog miatt ragaszkodom:
- nagyon jól scriptezhető egér action-ökhöz is, meg gyakorlatilag bármire
- Nem csak balra és jobbra lehet illeszteni modulokat, hanenem középre is. Ezt viszont nem tudja semmi, amikor utoljára néztem. Nekem a dátum és idő mindig középen van, mert úgy áttekinthetőbb számomra. Tint2 anno nem tudta, lemonban szintúgy, xmobar sem. Lehet hog azóta ez változott, majd megsasolom.
Igen, azért más a kettő. A Debian valóban szétdarabolja a csomagokat, sőt, meg is duplázza, mert ha valamit forráskódból forgatsz, akkor külön vannak a -dev végű csomagok is, míg Archon minden csomag egyben bináris és dev forráskódos is. Így a csomagszám nem összehasonlítható.
A dunst valóban nem foglal sokat, de ha nekem nem kell, akkor az a kevés is minek menjen? Igazából hallottam olyan véleményeket is, hogy ezek a bar-ok is pótcselekvés kategória, mert meg lehet lenni nélkülük, és valóban, én is csak arra használom, hogy az idő-dátum és az épp használt virtuális asztal kint legyen, meg csak megszokás, esztétikum. Az a 180 mega nagyon badass, nálam nincs se NetworkManager, se dunst, és mégse tudok 280 mega alá bemenni. Talán az AMD-s GPU driverek miatt.
A bspwm minimálisabb, mint a Sway, maradj annál. A Sway se rossz, nekem bejött, a Wayland-del sem volt gondom (igaz nem használok Nvidiát, OBS-t, stb., ami segíthet ebben), de jelenleg én is X-en vagyok. 2 év bspwm-ről váltottam 3 hónapja dkwm-re, ami szintén egy bspwm-klón, csak normálisabb szintaxissal, és bináris fás bonyolítás nélkül, és többféle dinamikus tiling layoutot tud (szemben a bspwm-mel, ami csak Fibonacci-spirált lényegében). Azért inkább X, mert portolhatóan akarom tartani a rendszerem, workflow-m, ha a Linuxszal történne valami, akkor BSD-re tervezek váltani, és ott a Sway, Wayland nem játszik. Jó, FreeBSD-n van rá valami hekkelés, de az is kivétel, mint fő szabály. X meg hagyományos WM-ek mindenre vannak viszont, így univerzálisabb. Bár azért a Sway is portolható, mert i3wm formájában használható X-en is, csak egy-két wayland-specifikus beállítást kell kikommentelni a konfigban.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Biztos meg lehet élni a bar-ok nélkül, viszont a több desktop kijelzése, hogy épp melyiken vagyok, az óra, dátum, akksikijelzés (Notebookról használom), és hát a hangerő és fényerő kijelzése értékre szerintem fontos. nyilván lekérdezhetem parancssorban is, de mennyivel több idő, mint hogy odapillantok? Azért az egyszerűsítésnek is ésszerűnek kell lennie szerintem.
Badass a 180 körüli érték, de igaz. Íme: https://ibb.co/FxtstJF
De az ésszerűség határán egy picit túl is minimalizáltam. Nincs grafikus login manager, rendesen konzolosan lépek be, nincsen usb-s automount csomagból, csak script, hangerő, fényerőt is mind scriptből valósítom meg, így nincs egy rakat alsa utils és társai sem. Terminál indítása is kb 6-7MB-al növeli csak meg, mert a suckless terminal-t használom. Azt magam fordítottam, mert amiket találtam abban számomra sok felesleges dolog volt, szal eléggé minimál. Filekezlő is vifm, ugye az is konzolos :D
Bspwm-el csak egy bajom van, hogy alapból nincsen benne Swallow funkció, és el is zárkózott tőle teljesen a fejlesztő. Úgyhogy arra is külsős megoldás kellett, ami nem megy a Debian stable alatt, mert python-ból nincs meg a minimál verzió. Majd nézek másikat. Ez a dkwm hol található, mert githubon sem találom. A fibonacci elrendezés amúgy nekem bejön, mert az i3-as sima felosztás pl egy notin igencsak nem jó, nem látható rendesen a tartalom.
A dk-t itt találod. Bemutató videó itt van róla. Swallow-funkciót szerintem majdnem biztos, hogy nem tud. 99,99%-ban ugyanaz, mint a bspwm, csak bspc helyett dkcmd-vel üzensz a WM-nek, és máshogy adod meg mögötte a paramétereket (egyszerűbben), nincs benne ez a binary tree, root node, ilyen-olyan node-os bonyolítás, meg az a korlátozás, hogy csak spirált layoutot tud (emellett tud a dk grid, vertical/horizontal master-stack, master-doublestack sémákat is). Épp úgy sxhkd-t használ a billentyűfigyelésre, és épp úgy shell scriptből konfigurálod. Meg kemény 100KB-tal kevesebb memóriát eszik, mint a bspwm, ami elhanyagolható. Ennyi a különbség. Arra figyelj, ha kipróbálod a dkwm-et, akkor először nem fog indulni, mert sír, hogy nem talált socket-et, de ha a .bashrc-ben definiálod a DKSOCK környezeti változót, hogy a /tmp/dk__0_0.socket legyen az értéke, akkor menni fog, ez sajnos egy bug, amihez kell ez az apró hack. Igen, bug, mert automatikusan létrehozza a tmp-ben a .socket fájlt, de mikor indulna, valami miatt nem találja, míg meg nem mutatod neki.
Login managert, automount-ot, stb. én se használok. Én is tty-ről indítom .bashrc-ből a WM-et. Majdnem minden programom nekem is konzolos-terminálos (Vifm, neovim, calc, htop, saját mount, wi-fi, hangerőkezelő, frissítő, online rádióhallgatós, fzf-es, jmtpfs-es, ntpdate-es, stb. scriptek, cmus, mpv, feh, sxiv, zathura, stardict-cli, curl wttr.in, calcurse, transmission-cli + tremc, pulsemixer, scrot, redshift, XeTeX, pandoc, python + numpy/sympy, R, imagemagick display/convert, ffmpeg, mind gyorsbillentyűre drótozva), kivétel nagyon kevés van (Firefox, Steam, játékok, illetve most álltam vissza neomutt-ról Thunderbird-re, és épp visszaállóban vagyok átmenetileg stardict-cli-ról Goldendict-re). Én viszont a terminált is belemérem a fogyasztásba, szintén st-t használok. Nálam eleve a systemd, pipewire a wireplumberrel, X.org, stb. annyit eszik, hogy azok egymagukban foglalnak 170-180 megát, és akkor erre jön még rá a kernel, wm, lemonbar, az utóbbi által futtatott scriptek, stb..
Vannak emberek, akik meg úgy oldják meg a tilingot, hogy feltesznek egy akármilyen sima WM-et, abban teljes képernyőn használnak mindent, csak a terminált osztják fel tmux-szal, és abban megy a tiling. Van benne logika, mert ha az embernek épp tiling felosztás kell, akkor úgyis terminálban futó programokhoz lesz rá szüksége. Nálam is főként teljes képernyős ablakok vannak az 1-es virtuális desktopon, a 2-esen meg ablakréses grid tiling, amit persze tudok váltogatni más felosztásra. A 3-as virtuális asztal nem létezik, amíg létre nem hozom, azt csak floating ablakos programokhoz izzítom be.
Egyébként nekem ezekből a minimalista WM-ekből két dolog hiányzott világ életemben: az Openboxból megszokott kulturált taskváltó, lehet helyette ugyan rofi-t haszhnálni, de az meg nem olyan jó, vannak bugjai (ha véletlenül nyitod meg, nem tudod bezárni, míg ablakot nem váltottál). A másik, jelentősebb korlát, hogy teljes képernyős és floating alkalmazásról nem tudnak átváltani egy másik ablakba, úgy, hogy az az előtérben legyen, ezt egyik sem tudta, amit próbáltam, azok közül, ez egy általános korlát. Az Openbox, IceWM, JWM tudja, de azok stacking WM-ek, nem tiling-kategóriába tartoznak.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Köszi, megnéztem, de számomra sajnos nem tud olyan plusz funkciót, ami nekem kellene. A plusz elrendezések jó ötlet, nagy monitoron lenne is értelme, de nekem notebookon a bspwm spiral-ja pont jó. Sajnos ez sem tud swallow funkciót. Talán majd 1 év múlva. Akkor újra ránézek :)
Ahogy nézem akkor te is kellőképp leminimalizáltad, úgyhogy nem értem, hogy nálad miért foglal 200MB felett. Talán a xorg telepítésnél az összes csomagot és drivert felraktad? Én ott is öszesen kb 6db csomagot raktam fel a xorg-nál a videókártyákkal együtt számolva. Ráadásul a lemonbar amit használsz biztos kevesebbet foglal, mint nálam a polybar. A polybar elég sokat tud zabikálni. Amúgy ahogy nézem Arch Linux alatt viszont nekem is 220MB+-2MB-ot mutat, úgyhogy a Debian bánik takarékosabban most. Az st terminált indítva 196MB-ot foglal, vagyis így is 200 alatt van. Viszont nem tudom, hogy te honnan olvasod ki az értéket, de én a polybar-ra a free -m értékét iratom ki.
Nálam csak a transmisson megy teljes ablakba, és javarészt a Chrome (tudom, gyalázat :D), de minden más sokszor felosztottan működik, de van, hogy a chrome mellé is megy még más, szal nálam a virtuális asztalok (5-öt használok, mert van hogy ezen dolgozom, és nem a céges notin Windows alatt...) nagyon képlékenyek. Egyedül a felugró informális ablakokra állítottam be floating-ot, többi nekem tilling. Én teljesen leszoktam a task váltóról. Mivel a programoknak nincsen fix helye, így fejből megy hogy hova ugorjak, de sok embernek fixen nyílnak a programok egy-egy virtuális asztalon, és akkor nekik meg azért nem kell. Rofi-t én csak programelindításra használom, és akkor is csak abba az esetben, ha nem gyakori programot használok, mert az alap progikhoz: st, vifm, chrome stb van bill kombó. Ssh-s csatlakozást használok még rofi alatt, de azt sem mindig, mert ha épp vifm-ben vagyok, akkor onnan is el tudom indítani, oda is tettem parancsot.
Egyelőre még nem tudom, hogy mi legyen. Pár napig használom így a Debian-t (magánhasználatra, mert a céges szerverekre Debiant használok amúgyis), aztán eldöntöm, hogy maradok az eddig régóta használt Arch Linuxnál, vagy lesz akkor az ugyanúgy, ugyanarra felkonfogolt Debian.
Majdnem mindegy melyiknél maradsz. Akár Debian is lehet, ha az megfelel, és nem kellenek az új verziós szoftverek, ellenkező esetben csakis Arch. WM-ből még ránézhetsz a Herbstluft WM-re, az is nagyon hasonló a bspwm-hez, dkwm-hez, épp úgy dinamikus tiling, épp úgy shell scriptből konfigurálod, csak bspc/dkcmd helyett herbstclient-tel üzengetsz neki. Annyi, hogy tud billentyűket kezelni, de használhatod hozzá az sxhkd-t is (vagy mxhkd, xbindkeys valamelyikét). Minimalista WM-ekből ez a Herbstluft és az Xmonad tudja a legtöbbet, bár utóbbi szerintem bloatabb és nehezen konfigurálható a Haskell miatt. Esetleg még awesome, de az meg megint többszörösét foglalja a bspwm-nek. Meg az i3wm,/Sway de az se annyira ultraminimalista, és sok embernek nem jön be a manual tiling miatt. A dwm, 2bwm, evilwm viszont már nagyon fapad. A dwm-et fel lehet patchelni, de annak az a buktatója, hogy akkor meg a bspwm-hez képest nem lesz minimalistább összességében, mivel nő a memóriaigénye, ahogy patcheled bele az extra funkciókat.
Pont ezt a baj, hogy nem tudom tovább minimalizálni a rendszert, ha belefeszülök, akkor se. Tippre az AMD GPU drivere foglalja, mert a régi inteles laptopon (X220) ennek felét foglalta majdnem (az is igaz, hogy az Sway Wayland + XWayland felállás volt, de megállt 140-170 MB között), szerintem egy modern GPU drivere ennyivel bonyásabb, nagyobb. Plusz a Pipewire is bloatabb már, mint anno a Pulseaudio volt. Simán lehet a különbség a Debian is. Arch alatt hihetőbb az a 220 MB. Természetesen én is a free -m kimenetét nézem, de ugyanazt kell mutassa a top parancs is. A htop, btop, grafikus feladatkezelők viszont máshogy mérik, az nem mérvadó.
Amivel még küszködök, az a panel minimalizálása. Hiába tértem át ugyanis a minimalistább lemonbar-ra, ha annak meg egy csomó scriptet meg figyelő progit kell futtatni, hogy a polybar szintjét elérje (asztalok kijelzőse, ablakcím, hangerő, esetleg hálózat vagy energiaprofil, és végül dátum-idő), és amit nyerek a réven, elbukom a vámon, összességében előrébb nem leszek vele. A WM-et sem tudom tovább minimalizálni, a TinyWM nem használó, illetve elkezdtem írni egy shell scriptes saját WM-et, a no-wm mintájára, de az sem használható állapotú, annyira fapad, hogy használhatatlan, csak proof of concept. Próbáltam a sytemd-journald-t is letiltani, de akkor meg hibádzott a dmesg log is, így újra engedélyeztem. At-spi-s cuccok is tiltva vannak, legalábbis automatán nem indulnak el, csak a Firefoxszal. dbus-t nem tudom letiltani, mert pár programnak kell, redshift, Steam, Firefox, stb.. Tervezek xterm-re átállni, mert az új verzió támogatja a truecolor-t és unicode-ot, és valami 6-7 megával kevesebbet eszik, mint az st, de a konfigurálása szarabb, mert .Xresource fájlnak kell küzdeni az ósdi szintaxisával.
Esetleg gondoltam, hogy konzolt használok és azon tmux, de akkor meg se hardveres gyorsítás, se rendes színmélység, meg a böngészőnek, ennek annak kell az X. Igazából a stardict CLI-je is bejött, nem azért tettem félre, mert rossz, bevált, hanem saját konverziójú szótárakkal használom, és azoknál hibát vétettem a létrehozáskor/indexeléskor, így egy csomó szót nem talál meg bennük a startdict, amit a Goldendict igen, mert az saját maga átindexeli. A neomutt is majdnem bevált, ami bajom van vele, hogy lassan indul, mert hosszan várakozik a mailserverre, míg az új leveleket lekéri IMAP-ból, de addig nem jelenik meg a felülete. Próbáltam még aerc-t, de azzal meg az a bajom, hogy a HTML maileknél fixen van drótozva, hogy csak w3m-mel lehet nézni őket, normál böngészőben nem engedi megnyitni. Pedig majdnem ott lennék, hogy a böngészőn és játékokon és launchereiken kívül minden alkalmazásom terminálos legyen. A hajszál választ el tőle, de az stabilan elérhetetlenné teszi egyelőre.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Herbstluft WM nekem nagyon nem akart működni. Mikor Openbox-ról át akartam állni tiling windows managerre, akkor az alábbiakat próbáltam ki: bspwm, herbstluft, i3, qtile, spectrewm, stumpwm (és nem olyan rág a leftwm-et is). Ezekközül a bspwm-et találtam megfelelőnek számomra. Az xmonad-ot eleve elejtettem a Haskell miatt, a dwm-et azért mert minden egyes beállítás miatt újra kell fordítani. A qtile is feleslegesen van a python miatt bonyolítva. I3-at meg nem értem miért van agyon hypolva.
Nálam a polybar 9MB-ot foglal most Debianon. Ez most meglepett, mert Arch linux alatt mikor legutóbb néztem, akkor majdnem 30MB-ot foglalt. Lehet hogy pont ez a különbség érhető tetten abban, hogy Debian alatt kevesebb memóriát eszik. Szal ha Arch-on vagy, akkor nem biztos, hogy a lemonbar scriptezve többet eszik, a polybar.
xterm 6-7MB-al kevesebbet eszik, mint az st? Valami ott nem stimmel. Nekem az st elindulásakor 8-10MB-ot eszik meg (mikor hogy van kedve), az xterm meg 10MB-ot most ahogy kipróbáltam. Ráadásul az xterm iszonyat lassú az st-hez képest. Ezt még idén néztem újra, mikor viszgáltam az st és alacritty sebességét, gondoltam xterm, urxvt-t is megnéztem, és ez utóbbi kettő jóval lassabb volt, mint az st, vagy gpu gyorsított alacritty.
Amúgy csesztette a csőrőm ez az nm-applet-es hiba, hiszen nem minden Linux "fajtán" probléma. Az egyik megoldás ugye meglett, de van egy olyan megoldás, ami miatt nem kell a háttérben futtatni a dunst-öt (vagy más notification managert), és úgy is működik. Mindkettőt beírtam az első posztba.
Lényeg, hogy a xinitrc-be be kell írni: systemctl --user import-environment DISPLAY
Mert bár ez a sor szerepel a Debian rendszerben, de csak akkor működik, ha a dunst-öt systemd service-ként rakják fel, amúgy nem fut le...Kész vagyok...:D
Nálam az st 16 404 KB-ot eszik (htop - memory resident/RSS oszlop), igaz belepatcheltem 1-2 funkciót (görgetés, egérkezelés, vágólapos funkciók), nem sokat, de így kicsivel nehezebb, mint a stock st. Az xterm 9 388 KB-ot, legalábbis nálam, igaz nincs még bekonfigolva, azzal nőhet a fogyasztása. Az Alacritty mint már írtam, akkor gyorsabb csak, mint az st, ha már fut, és mondjuk elindítasz benne egy olyan parancsot, ami hirtelen kitol nagyon sok ezer sort, ott megcsillan a GPU gyorsítás. De ilyet nem sok mindenki csinál, értelme sincs sok, mert ha ennyi sorod és kimeneted van, az eleve visszagörgethetetlen, átláthatatlan mennyiség, azt jobb less-ben vagy más pagerben nézni, vagy fájlba irányítani, ha csak a nyers terminálbetöltési sebességet nézed (mikor gyorsbillentyűre indul vagy benne valami programmal együtt), akkor az nálam messze veri sebességben az Alacritty-t, de ez várható is, mivel utóbbi 6-szor annyi kódot, libet tölt be. Az xterm is elég gyorsnak tűnik szemre.
Ez a systemdctl --user import-environment DISPLAY sor elfér, de szerintem felesleges, lényegében a DISPLAY környezeti változót importálja újra a userednek, ezt megteheted a profiles-ban, shellrc-ben, vagy amiben akarod. Én nem használok ilyet, nem kellett még egyik WM-nek sem, igaz én nem használtam még Debiant sima WM-hez, csak nagyon régen debianoztam, és akkor még kezdő normiként full DE-ket futtattam rajta, pl. KDE4. Úgyhogy nem zárom ki, hogy elméletben kellhet az ilyen varázslás, de az is minimum furcsa, hogy miért kéne.
A Herbstluft nem rossz, de idő kell a konfigurálásához. Iszonyat sok funkció van benne, így több munkát jelent a bekonfigurálása is. Még én sem tettem fel, de néztem róla videókat a YT-on (distrotube, jake@linux, the linux cast), meg dokumentációt. Komoly cuccnak tűnik. Egyszer tuti felteszem, megnézem milyen, meg hogy mennyit foglal.
Polybar az megint szórhat. Debianon lehet eleve kevesebbet ehet, plusz annak is a függvénye, hogy milyen modulokat kapcsolsz be rajta, minél többet, annál inkább nő a fogyasztása. A lemonbar soványabb, de csak a bar, ami kevesebbet is tud (önmagában lényegében semmit, csak kiírja, amit beleirányítasz), így shell scriptek futtatásával kell pótolnod (hogy infót adjon ugyanazokról), de azokkal együtt meg nem fogyaszt már kevesebbet, úgyhogy én is fontolgatom, hogy visszaállok polybarra, meg ha a fogyasztás ugyanannyi, azt jobban megéri használni.
Mondjuk azt továbbra sem értem, hogy Archon miért van nagyobb foglalás. Ott is épp úgy gcc-vel fordítanak, sőt, még optimalizálnak is, pl. LTO. Debug szimbólumokat épp úgy ki-strip-elik, mint a Debian. Úgyhogy rejtély, mert ha még elméletben lehet is egy kis eltérés, nem lehetne ekkora, hogy néha majdnem fele legyen az egyik a másiknak.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Az st-be én is belepatcheltem ezeket a funkciókat, hisz a görgetés (bill is, egér is), clipboard alap dolog. Az xterm szemre gyors, de nagyjából itt ki is merült. Ráadásul bármit akarok, akkor .XResources -ban módosítani kell, és valahogy sosem akart rendesen működni nekem a vágólap. Aztán ráakadtam az st-re, és maradtam nála, mert hipergyors, és alig foglal nekem memóriát. Amúgy az Arch Linux is volt hogy ilyen keveset fogyasztott nekem, pedig nemigen használok azóta új programokat, szolgáltatásokat meg egyáltalán nem. Szerintem Arch-nak pont az a hátránya, ami az előnye is, hogy minden újdonságot frissítést azonnal megkap, függetlenül hogy jól működik-e vagy sem, és ezért is nőtt meg a memóriaéhsége. Ezekkel nem foglalkoznak, csak nyomják bele az új dolgokat. Persze egy 12-16GB-os gépnél ez pont nem érdekes, de nálam 4GB memória van, és ha dolgozom is ezen, akkor baromi gyorsan el tud fogyni.
Hiába mondod, hogy felesleges az a sor, mikor csak azzal működik rendesen, és úgy ahogy kellene. Nem mellesleg ezt valamelyik tilling WM leírásban/fórumon találtam, hogy Debian esetén erre szükség van bizonyos körülmények esetén. Hát ez a körülmény ezekszerint pont ilyen.
Distrotube-ot én is követem már régóta. Láttam a Herb-es videót is, meg a Tilling WM-es rendezős videót is, ahol le is hordta a Herb-et, pedig az elején még tetszett neki :D
Amúgy BSPWM-hez tegnap találtam (bár nem ezt kerestem kifejezetten) layout váltót: https://github.com/phenax/bsp-layout Faxán működik, és rém egyszerű használni, ráadásul így workspacenként is be lehet állítani, hogy milyen layout-ot használjon. Az even egész jó, most azt használgatom. Kiderül, hogy hosszútávon hasznosabb lesz-e, mint a default Spiral.
Polybaron pontosan ugyanazokat a modulokat, és scripteket használom Debian alatt, mint Archon, mégis Archon jóval több memóriát eszik. Másfél éve indult el kb, hogy az Arch nekem egyre többet evett már alapból is, pedig ugyanazon programokat használom.
Ja, ez az, amit nem szeretek én se az xterm-ben, ez az ósdi .Xresources, pain in the ass konfigolni. Én se véletlenül vagyok st-n, nem menőzésből, hanem ez az, ami gyors, normálisan konfigurálható, és működik. Abban valószínű igazad van, hogy az Arch azzal, hogy bleeding edge, némi bloatságot is bevállal. Eleve az, hogy kötelező Archon systemd-t, initramfs-t használni, már az is egyfajta bloatság. Az a 4 giga ma már elég kevés, még ilyen minimalista, terminálos, tiling WM-es felhasználásnál is nagyon a határon van, ahogy meg egy böngészőt is beröffentesz rajta, akkor meg aztán végképp nem sok mindenre elég. Nálam már kb. 6 éve nincs 8 giga RAM-osnál kevesebb memóriájú gép, kb. 5 éve meg 16 giga RAM-nál kevesebbel szerelt (ami meg nekem overkill már, de nem drága, nem luxus ma már), így végül is nem érdekes, ami miatt a RAM fogyasztáson rugózok, hogy a minimalizmusnak mérőfoka, meg pl. ha egy alkalmazás több memóriát köt le a szükségesnél, az a rendszer többi részének (proci, kernel, ütemező) is felesleges többletmunka, így indikátorként veszem figyelembe a bloatság kiszűrésére.
A bspwm-nél azért vigyáznék, mert ezek a 3rd party scriptek bugzani tudnak, ha épp crashelt egy alkalmazás, vagy nem szabályosan zártad be, vagy valami rendhagyó módon váltottál virtuális asztalt, stb., és a script összezavarodik, mert úgy tudja, hogy fut az alkalmazás, közben meg már nem, és glitcheket okoz. Az a baja a bspwm-nek, hogy igazából kézi tiling (ahogy az i3wm/Sway is), neked kell megmondani, hogy hová nyíljon az új ablak, legalábbis erre lett tervezve. Tud ugyan automata (ún. dinamikus) tilingot is, de akkor csak a Fibonacci-spirált kiosztást, abból egy befelé és kifelé hajló változatot, ami kb. ugyanaz, és kifújt. Új layout-ot is nehéz bele integrálni, mert a készítők nagyon ragaszodnak ehhez a szigorú binary tree, root node, ilyen-olyan node működéshez, pont ez az egyetlen, ami miatt váltottam dkwm-re, mert egyébként a bspwm is tökre megfelelt. Annyi, hogy mikor másik layoutot akartam, akkor bspwm-en trükközni kellett, áttettem az ablakfókuszt egy másik alkalmazásra, ahhoz képest kezdte újra a spirált, azzal lehetett kitrükközni félkézileg egyfajta grid és master-stack kiosztást.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Eddig tökéletesen működik ez a layout script. Igaz friss, és folyamatosan fejleszti, javítja a srác. A másik script amit használok, az a swallow funkció. Ezeréves, de sosem hibázott, úgyhogy nagyon stabil így a bspwm. Egyedül max akkor váltanék róla, ha hasonlóan jót találnék, könnyen konfigurálva, kellően kevés erőforrással, és gyári swallow funkcióval.
Ha majd lesz felesleges időm, akkor csak nekiveselkedem a dwm -nek. Mondjuk lehet hogy jobb lett volna nyáron, mikor főnök szabin volt :D
Ja, a swallow-val nincs baja, az valóban működik, az autolayout tud hibádzani, nálam is bugzott, meg videókon is ezt a visszajelzést hallottam, hogy nekik se volt jó, bár én még nem ezt a scriptet próbáltam, amit te is használsz. A swallow egyébként az a funkció, amit nem a WM-nek kéne csinálni, hanem a terminálemulátorokba kéne beépíteniük, ha olyan alkalmazás indul terminálból, ami új ablakot nyitott, akkor az nyelje el a terminált (ha így van beállítva, igény szerint kikapcsolhatóra).
A dwm is jó, de annak ahogy már írtam, az a csapdája, hogy mire hozzáadod a billentyűkonfigot (sok billentyűvel), belepatcheled a neked kellő funkciókat, rendesen beizzítod a bar-ját, saját scripttel megtoldva, akkor a végén ugyanott leszel, mint egy bspwm + lemonbar/polybar + sxhkd kombóval. Semmivel nem lesz se gyorsabb, se kevesebb memóriát nem fog lényegében enni (max. csak pár KB-tal). Működni működik, de elég nagy munka felpatchelni, konfigolni, és így egy kicsit sok hűhó a semmiért. Érdekességnek azért megpróbálhatod, legalább ebben is lesz tapasztalatod, meg szakmailag-linuxügyileg fejleszt.
A distrotube-nak az a baja, hogy elfogult a faszi, néhány kedvencét tolja állandóan (xmonad, qtile, doom emacs), a többinek meg nem ad kellő esélyt. Azért javaslom, hogy egy adott megoldást, WM-et nézz meg más csatornákról is, pl. The Linux Cast, Jake@Linux, Brodie Robertson, OldTechBloke, vagy amit még az adott témában felhoz a kereső.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Természetesen nem csak Distrotube-ot néztem/nézek. Csak abból nem is lehetne rendesen megtanulni linuxozni.
Közben bekonfiguráltam az xterm-et. Ugyanúgy lehessen copyzni, színes legyen, beraktam egy Mono-s fontra, mert azonkívűl egyik fontot sem akart elfogadni, pedig Iosevka szerintem az egyik legjobb terminálnak, lehet scrollozni stb, és futtattam egy egyszerű tesztet: exa -laR /
st (11MB memóriafoglalás):
real 0m10.827s
user 0m9.929s
sys 0m6.046s
xterm (8MB memóriafoglalás):
real 0m43.892s
user 0m14.197s
sys 0m11.032s
Nem csak az értékeken látszik, hogy brutális lassú, de szemmel is látható volt ahogy pörgette. Arról nem is beszélve, hogy erősen volt flickering is. Ha gondolo átállhatsz xterm-re de szerintem teljesen felesleges. rxvt-unicode szintén ugyanez, akkor már azt is kipróbáltam felkonfigurálva, mert úgyis hasonló az xtermhez.
Kösz, hogy lemérted, ez valóban nem néz ki jól. Ennek ellenére nálam ez továbbra sem dealbreaker, mert még mindig szintetikus teszt. Ahogy már írtam, nem életszerű, hogy terminálba akarsz kihányatni egy sok ezer soros exa -laR / kimenetet (én ls-t használok, nem exa-t, de nagyon hasonlóak ebből a szempontból), mivel nehéz visszagörgetni, átlátni. Úgyis van valami pipe-on keresztül grep-pel fésülöd át, vagy pager-ben vagy editorban nyitod meg (less, more, bat, vim, neovim, akármi), vagy egy fájlba irányítod át, és akkor ezek a sebességbeli különbségek kb. ki is egyenlítődnek, mivel nem a terminál kirajzolási sebessége lesz a szűk keresztmetszet. Nálam konkrétan tmpfs ramdrive-ra irányítva az ls -laR / kimenetét,
st:real 0m2.493s
user 0m0.744s
sys 0m1.717
real 0m2.438s
user 0m0.767s
sys 0m1.646s
xterm:
real 0m2.493s
user 0m0.744s
sys 0m1.717
Szépen látszik ebben az életszerűbb tesztben, hogy az xterm néhol már csak 55-71 ms-mal lassabb, sőt, a usertime-ban meg egyenesen 23 ms-mal gyorsabb, ezek olyan apró eltérések, hogy emberileg nem érzed meg egyszeri futásnál, ahogy pl. egy játéknál azt se veszed észre, ha 60 vagy 65 fps-sel fut. Persze, azt nem tagadta senki, hogy ennek ellenére az st gyorsabb, eleve erre is lett tervezve, hogy minimális mennyiságű kódsor legyen, az xterm egy sokszorosan nagyobb kódbázis, persze, hogy a nyers teljesítménye szintetikus teszteken nem akkora. Ebben a szintetikus tesztben az Alacritty, Kitty még jobban teljesítene, mert az a GPU-gyorsításból is profitál, de ez megint az a szint, ami a normál felhasználásnál nem jön ki, cserében viszont mérhetően lassabban indulnak.
Az urxvt-vel nekem az volt a gondom, hogy néha pont a Unicode/UTF-8 karakakterek azok, amiket nem jelenít meg, pedig a nevét is arról kapta, hogy ezekkel kompatibilis. Amúgy ezt leszámítva nem volt vele még bajom. Egy terminál van X-en, amit nem próbáltam még ki, az a Sakura. A híréből ítélve minimalista, de nem tudom milyen, fogalmam sincs.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Visszaváltottam dk-ről bspwm-re. Kényszerűségből, a legutóbbi dk verzió bugos lett. Az a fő baj vele, hogy egy fejlesztős projekt, nincsenek bedolgozók, nincs kontroll, a fejlesztő meg rossz irányba viszi. A legutolsó frissítés után a teljes képernyős mód elkezdett bugzani, pl. böngészőben nézett teljes képernyős videóról elváltottam másik munkaasztalra, majd vissza, a böngésző került teljes képernyőre, nem a lejátszott videó, de voltak más alkalmazások is, amikkel hasonló baj volt. Kár érte, mert amúgy jobb, mint a bspwm, de a bspwm stabilabb, több fejlesztős, tapasztaltabbak is a fejlesztők, régebb óta futó projekt.
Egyébként tartom, hogy a bspwm a legrugalmasabb WM a minimalisták közül. Vannak mások több funkcióval, de azok nem minimalisták, és vannak minimalistábbak, de azok meg rugalmatlanok, csomó mindent nem támogatnak. A bspwm egyfajta legoptimálisabb középút a minimallizmus terén.
A másik nagy váltás, hogy visszaváltottam lemonbar-ról polybar-ra. Lemonbar-on idegesített, hogy a néhány betűkombót nem jól jelenített meg, csak túl távol egymástól, erre régen találtam leírást (Xft bug), de most nem találom, így nem tudtam javítani. A másik, ami baj volt vele, hogy összességében több memóriát evett, mint a polybar, 21 vs. 16 MB, vagyis önmagában kevesebbet, de mikor futott hozzá az összes szükséges script, azokkal együtt már többet. Plusz a polybar szebb is. Lehet a dzen2-t egyszer kipróbálom.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Igen, ezt én is tapasztaltam. Volt egy kevéske levelezésem vele, és megállapítottam, hogy nemigazán viszi jó irányba az én szempontomból. Közben pár napja átváltottam dwm -re és dwmblocks-ot használok bar-ként. Mindent egyenként lepatcheltem lefordítottam. Majdnem egy az egyben ugyanazt tufja, mint amit bspwm alatt csináltam, és most így még lefaragtam 15MB memóriahasználatot :D
Egyelőre maradok ezen, aztán majd kiderül, hogy visszaváltok-e bspwm-re vagy sem.
Igen, ezt én is tapasztaltam. Volt egy kevéske levelezésem vele, és megállapítottam, hogy nemigazán viszi jó irányba az én szempontomból. Közben pár napja átváltottam dwm -re és dwmblocks-ot használok bar-ként. Mindent egyenként lepatcheltem lefordítottam. Majdnem egy az egyben ugyanazt tufja, mint amit bspwm alatt csináltam, és most így még lefaragtam 15MB memóriahasználatot :D
Egyelőre maradok ezen, aztán majd kiderül, hogy visszaváltok-e bspwm-re vagy sem.
dwm-mel nekem az a fő bajom, hogy nem EHWM kompatibilis (xdo, xdotool tudja kezelni), sem IPC-je nincs (dk, bspwm, herbstluft, i3wm, Sway, berrywm, awesome, stb. mind rendelkezik ezzel), így nem tudsz neki toolokkal kívülről üzengetni, hogy mit csináljon, pl. tegyen egy alkalmazást teljes képernyőre (hacsak előre be nem emeled a kódjába szabályként). A másik, hogy patchelgetni a kódját elég fájdalmas, főleg, mikor több patcht is hozzáadsz. Egyébként zseniális cucc lenne, nem kizárt, hogy én is szaladok vele még köröket később.
A dwm igazi előnye, hogy a billentyűidet is kezeli. Önmagában nem sokkal kisebb, mint egy dk, bspwm, de viszont nem igényel maga mellé külön bar-t, külön sxhkd-t, így már átveszi a vezetést minimalizmusban. Másik előnye, hogy többféle layoutot tud, míg a bswpm lényegében csak egyet (spirál kifelé-befelé).
Memóriahasználatot én már jó ideje nem tudok lefaragni, ezzel a dk + lemonbar -> bspwm + polybar váltás is kb. azonos memóriából van el, közben meg az Arch bloatosodik. Régen 265 mega körül volt, aztán 285, majd 300, most már 320-on vagyok sajnos. Pipewire, systemd, X, meg egyéb szutykok bloatosodnak. Mindegy, mert a 16 giga RAM-ból így is majdnem az egész üresen áll állandóan, a kernel használgatja cache-elésre, meg én tmpfs ramdrive-nak, hogy ne álljon parlagon kihasználatlanul. Inkább csak az zavar, hogy a több memóriafogyasztás lassabb futást is indikál általában.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
A statusbarra van EHWM patch, ha jól rémlik. Szerencsére nekem az nem létfontosságú. IPC-re meg van patch. Az igen! Arch akkor nagyon megnőtt. Mondjuk ezért is hagytam el anno. Meg az elrontott frissírtések miatt is. Amúgy a dwm patchelése sajnos nem megy flottul. Minél többet használsz, annál inkább hibádzik, vagyis bizonyos sorokat kihagy, úgyhogy azt utána kézzel kell módosítani. Meg van, ami már alapból hibádzik, mert nem lett frissítve, így azt is kézzel kell módosítani, szal "jó" móka. Igaz miután az ember készen van vele, akkor csak hasznlni kell :D Meg vannak érdekességek. A doksi, meg más példa filejából azt látom, hogy ha egy speciális ablakot alapból floatinak akarom előhozni, akkor 1-es értéket kell adni a megfelelő helyre. De nem működik. Aztán tök véletlenül láttam máshol, hogy nem 1-es írt, hanem True. És lőn azzal működik, pedig a hivatalos doksiban is 1-es szerepel...Szal azért van káromkodás részemről...Nah mindegy. Most ilyenem van, hogy ezt kell használnom egy ideig, aztán majd kiderül mi lesz később :D
Ez van, a dwm nem felhasználóbarát. Elírsz valamit a C-s kódban, attól még lefordulhat, és nem fogod érteni, hogy mitől nem működik valami. Idegek kellenek hozzá, meg nagyon figyelni, rettenet low level cucc. Mondom, főleg akkor nehézkes, ha több patcht is hozzáadsz, mert minden patch úgy van tervezve, hogy a patcheletlen alapverzióhoz képest nézi az eltéréseket, és belezavarodik, ha már másik patch fent van. Nem lehetetlen megcsinálni, de elég türelemörlő, sokat kell vele próbálkozni.
A memóriahasználat függ egyébként a GPU-tól is (vagyis nem a GPU-tól magától, hanem az azt hajtó driverek komplexitásától). Míg Intel GPU-t használtam, addig majdnem 100 megával alacsonyabb volt a rendszer memóriafogyasztása, AMD GPU-val megnőtt. Nvidiával még nem próbáltam, de azt írják, hogy akkor még jobban megnő.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)