Sway-jel kapcsolatos kérdések

Ebben az a szep, hogy olyat akarsz, amit elvileg by default megcsinal :)

In the next step, swayimg adds two Sway rules for the self window: "floating enable" and "move position". Then it creates a new Wayland window and draws the image from the specified file.

https://github.com/artemsen/swayimg/blob/master/README.md#how-it-works

Ahogy nézem, jól csinálod pedig. Biztosan swayimg néven fut a bináris. Az is lehet, hogy swayimg-ben be van állítva, hogy felülírja az ablak, képernyő beállításait, nem ismerem ezt a progit, de néhány szoftver erre kényes szokott lenni, hogy nem követi a WM szabályait, hanem saját hatalmúlag partizánakciózik, és ez nem csak Wayland meg Sway alatt probléma, hanem X-es tiling WM-ekkel is elő szokott fordulni.

Én Sway alatt az imv-t használtam, sőt, használom most X.org + bspwm kombóval is.

na poenbol megneztem.

app_id nem lesz jo, mert egyreszt lesz egy app_id ami a tartalmazo terminal, masreszt abban van a floating swayimg.

nalam pl terminatorban elinditva:
 

eff@eff-tp:~$ swaymsg -t get_tree | grep app_id
              "app_id": null,
              "app_id": "terminator",
              "app_id": "terminator",
              "app_id": "swayimg_61d5f4100004314e",

de a get_tree segithet a debuggolasban.

Esetleg probalkozz a `title` fielddel, az `swayimg: kep.png`

Igen, ezek kellenek, amiket írtál. Ryzen 4700U-n én is ezeket használom az integrált GPU-hoz (RX Vega 7) és egy másik gépen a dedikált AMD RX570-hez is. Azt is jól gondolod, hogy az xf86-video-amdgpu nem kell, az csak X.org alá szükséges, Sway/Wayland alatt nem kell, még az XWayland sem igényli. Ezek közül csak a vulkan-radeont kell telepíteni, a többit behúzza automatikusan függőségnek a Sway és a Steam.

Amit esetleg feltehetsz még, az a libva-mesa-driver, ami VA-API hardveres videódekódolást tesz lehetővé a GPU oldaláról. Lehet helyette a mesa-vdpau csomagot is használni, az VDPAU gyorsítást kapcsolt be, de az kevesebb videókódeket tud dekódolni.

A vulkan-radeon helyett lehet használni az amdvlk csomagot, az az AMD által fejlesztett Vulkan drivert szállítja, nem a Mesa-félét, de a vulkan-radeon ajánlottabb helyette, állítólag lényegesen jobb teljesítményt nyújt.

Nem értem miért kérdezed. A helyesírást feszegeted (szabályzat szerinti toldalékolás: Sway-jel) vagy csak nem tartod hihetőnek, hogy Wayland alatt ennyire jól fusson? Ha az utóbbi, akkor elárulom, hogy a Wayland sok esetben tényleg gyorsabb, mivel kisebb az overheadje, jobbak a frametime-ok. Ajánlom neked is, hogy próbáld ki, főleg, ha nem NV GPU-t használsz, hanem AMD/Intelt. Meg fogsz lepődni, hogy sokszor mennyivel jobban, simábban, tearingmentesebben futnak egyes kódok.

Próbáltad újraindítani a rendszert? Az output parancs paraméterei közül próbáld meg kiszedni a felbontást, de főleg a 75Hz-et, lehet az a beállítás fixálja le a frissítési frekit. Esetleg próbáld ilyen sortöréses szintaxissal, ahol az se mindegy, hogy a kapcsos zárójelek melyik sorban vannak:

output DP-1 {
adaptive_sync on
bg /usr/share/backgrounds/arch/arch.png fill
}

Ezt egyébként az én gépeimen nem próbáltam még, mármint a FreeSyncet, pedig a GPU-k és kijelzők is támogatnák, de mikor még Sway-t használtam, akkor még az nem támogatta ezt a feature-t. Hétvégén lehet megpróbálom újra a Sway-t, rég néztem rá. Már most is fent van, csak nincs rendesen bekonfigolva, át kell hegesztenem a konfigját egy kicsit a régihez képest.

Jól néz ki. Pár jótanács: a TERM legyen "alacritty" és vedd fel a COLORTERM változóban a "truecolor" értéket, úgy nem csak 256 színt tud majd a terminál, hanem 16,7 milliót.

Nem vagyok benne biztos, de szerintem a DP-1 és HDMI-1 elé nem kell a $ karakter.

Ha fájlkezelőből nyitod, az a shell rc-jával (.zshrc, .bashrc vagy akármelyik másik shellről legyen szó) nem foglalkozik, mivel saját hatáskörben kezel mindent. Ha azt akarod, hogy az mc is így kezelje, akkor az adott fájlkiterjesztést így részletezve imv * -r -s full -u linear formában adagolod be neki sima imv helyett.

Nem, a zoom rohad ki, amikor megprobalok bekapcsolodni egy call-ba. De ugy tunik csak akkor, ha nem terminalbol inditom. Meg nem sikerult rajonnom, hogy mi az ami hianyzik neki.
Ugy tunik terminalbol inditva nem dol be, meg probalkozok vele.

Ezt nekem is csinálta, még mikor Sway-t használtam. Nem a Brave, mert azt akkor még nem futtattam, hanem pl. Alacritty terminál, ami szintén waylandes, de mégis, ahogy elindítottam, indult vele az xwayland. Fene se érti miért, mikor nem kell neki. Ennek ellenére nem nagy bug, mert legalább előre be van töltve, sok memóriát, prociidőt nem kér, és ha tényleg X-es alkalmazást indítasz (amit elég nehéz megúszni), akkor legalább használatra kész.

Nem lehet megszabadulni tőlük, mert ezek az X-es függőségek kellhetnek az xwaylandnek is. Olyan workflow-t még nem tudsz kialakítani, hogy minden alkalmazásod waylandes legyen. Írtad, hogy futtatsz Steam-et, játékokat, azok is X only alkalmazások, ahogy egy csomó más minden, pl. dmenu (bár erre van waylandes alternatíva, pl. wrofi, stb.), zathura, szóval én nem szedegetném le. Nem sok minden fut belőle, ha épp nincs használva, pár megát foglal.

Jól néz ez ki, egyedül én a transzparens háttérborítót venném ki, zavarja az olvasást. Az MQA meg egy csalás, audiofúl hülyítés, eleve veszteséges tömörítés, ami ráadásul csak interpolációval van felülmintavételezve. Sokat nem vesztesz vele.

A Strawberry egyébként egy nagyon jó audiolejátszó, funkciókban gazdag, de nekem túl bloat, ahogy írod is, sok qt-s függőség kell neki. Így ha audiolejátszó kell, akkor cmus vagy mpd+ncmpcpp, de sokszor beérem a sima mpv-vel, ha meg grafikus kell, akkor Deadbeef, ami egy foobar2000-klón, és csak Gtk-s meg gst-codec-es függőségek kellenek neki, de azt meg más Gtk-s alkalmazás már úgyis felvitte jó eséllyel a rendszerre, valami másik lejátszó, böngészők, stb.. Deadbeefet én csak tömeges tag-szerkesztésre, meg nehezen sciptesíthető konvertálásokra használok, de ebben a szerepkörben is igyekszem kiváltani. Most a jelenlegi rendszeremen fent sincs, mert még nem kellett semmihez.

A Spotify-t én is pont emaitt dobtam, tompa, kásás a hangja. Nem a formátumukkal van baj, mert a 320 kbps-os ogg Vorbis tudna sokkal jobb minőséget, hanem feltehetően valami normalizációs szűrővel, vagy valami hardverkimélő gyorstömörítéssel kókányolják össze a fájlokat, amiatt szót rosszul.

Tidal TUI-t nem fog senki csinálni, sem más streamszolgáltatóhoz klienst, mert ezek mindegyike úgy van megcsinálva, hogy a teljesen zárt API miatt csak webről lehessen használni, ezért van az, hogy a „natív” streamappok is mind Electron-alapúak, mert lényegében egy álcázott Chrome-ablakban fut webtartalom, annyi erővel akkor az ember használja böngészőből.

Így van, a /etc/environments-es megoldás a szakmailag legkifogástalanabb, legajánlottabb. Mindennek ellenére én nem használom, nem azért, mert baj lenne vele, hanem nem volt még rá szükségem, működik minden anélkül is., meg a felhasználóoldali shell rc-kben történő változókezelés inkább csak rugalmasabb, nem kell a módosításához állandóan rendszergazdai jog, stb.. De ez leginkább ízlés, preferencia kérdése. Ha neked csak az environmentses megoldás működik, maradj annál.

Passz, fogalmam sincs. Tidal-t pedig használok, de csak saját klienssel Androidon, meg Linuxon böngészőben a webinterface-üket. Elvileg ahhoz nincs köze, hogy milyen hálózatkezelő modullal kapcsolódsz, meg hogy X.org vagy Wayland fut-e. Pipewire-ről nem tudsz Alsára váltani, max. Pulseaudio-ra, de nem ez okozza.

Amire tudok mégis tippelni, az az, hogy a többi platformon is megszakad szerintem a buffering, csak ott nagyobb buffer van beállítva, addigra annyira megtelik a cache, hogy nem veszed észre lejátszás közben, míg a Strawberry-nél talán kisebbre van állítva a buffer.

Értesítéseket nem használok, de tippre a programok lehet nem kompatibilisek azzal a protokollal,, amit a notify-send használ. Csak tipp.

Én imv-t használtam Sway/Wayland alatt, az tökéletesen működik, még most X.org alatt is, mivel mindkettőt támogatja natívan. A swayimg-t nem próbáltam, de így elsőre morbidnak tűnik, hogy floating ablakokat erőltet. Automatán abban a módban kéne induljon, amelyet épp használsz, ha tiling, akkor abban, ha monocle/fullscreen, akkor abban, így a meglévő módokhoz kéne igazodnia. Főleg, hogy tiling WM-hez tervezték, nem floatinghoz. Ezzel a for_window megoldással viszont bármilyen ablakozó módot rá tudsz erőltetni akármilyen programra, nem csak floatingot, és nem csak Sway alatt, hanem i3wm alatt is működik.

Ezt a .zshrc-s megoldást se értem, mert ez shell aliast hoz létre, és nem billentyűkombinációt. Tehát ezt az aliast neked kell kézzel beírva futtatni, vagy scriptből meghívni.

Az a 485 csomag viszont betyár sovány egy rendszer, gondolom akkor X-es csomagok sincsenek fent. Nálam most 898 csomag van fent, Arch, bspwm, X.org, de van egy pár WM (dwm, IceWM) és rakat program fent, játékok, natív, steames, protonos, meg egy csomó dev/shell tool, tömörítő, stb. programozáshoz, szótárkonverziókhoz, némelyikről már azt se tudom, hogy mire kellett a csomag. Egy 2000 csomagos, full DE-s Ubuntu, Mint, stb.-hez képest ez még ez is rettenet sovány, 7,7 gigát foglal a rendszer (a játékok, adatok, torrentek, stb. nem a root partíción vannak, hanem a home-on, cache-es mappák meg RAM-ban).

Ha a kép közepét akarod nézni, akkor indítsd úgy a swayimg-t, hogy skálázza le a képet az adott ablak méretéhez automatikusan. Vagy indítsd az alkalmazást full screen-ben, így középen lesz a kép. Az ilyen floating barmolásnak nem sok értelme van tiling WM alatt. A floating ablakok mindenképpen csak hack tiling WM-ben, és csak azért támogatják, hogy ha valaki még olyan speciális, GUI-s programmal dolgozik, aminek sok alablaka van (pl. GIMP, más kép/videószerkesztők, vagy egyes debuggerek, IDE-k), vagy splash screenje, vagy párbeszédablaka van, akkor az ne nézzen ki hülyén full screenben meg tiling layout-ban. De nem ajánlott floatingot használni, ha csak egy mód van rá, kerüld, mert egy csomó korlátot jelent, pl. ha az előtérben fut egy floating ablak, akkor nem tudsz egy másik ablakra úgy átváltani, hogy a floating is a háttérben legyen, ki fogja takarni a többi tartalmat. Mindenképp pain in the ass, csak vész esetén használd.

Nekem egyébként a képnéző, videólejátszó mindig monocle/fullscreen módban van (és az imv automatikusan az ablak méretéhez skálázza a képet), mert ugye amikor az ember ilyen vizális tartalmat néz, akkor arra kíváncsi, és nem néz úgyse más sallangot a képernyőről, így értelmetlen ablakba benyomorgatni. Persze ez mindenkinek preferenciafüggő, attól függően, hogy milyen workflow-t és programokat használ. Annak ellenére, hogy a tiling WM pont azoknak való, akik inkább terminálos programokat meg egyszerű tiling, full screen layoutokat használnak, és nem hagyományos sokablakos, párbeszédablakos GUI programokat, azaz eleve indításból egy másfajta workflow-ra vannak kitalálva, ahol csak terminál meg, meg CLI/TUI/framebufferszerű programok (utóbbi pl. mpv, zathura, imv, stb.), és minden keyboard driven (nem egerészős, dokkra, ikonokra, stb. katttintgatós hagyományos GUI szemlélet).

A compose helyes működéséhez elvileg az is kell, hogy a ~/.XCompose fájlban bekonfigold, hogy egyes compose billentyűkombinációkra milyen karakter renderelődjön le. Legalábbis nekem az Arch Wikiből nem jön le, nem használok compose megoldást, pedig már sokan ajánlották, de mindig lusta vagyok bekonfigurálni.

Passz, sose használtam még ezt a formátumot. Ha linkelsz egy ingyenes mintafájlt, kipróbálom. Szerintem támogatnia kéne, mert bár én nem látom a támogatott formátumok listáján, de a DeadBeeF tud FFmpeg-et is használni, az meg kb. minden létező formátumot szokott tudni kikódolni.

Nem így kéne?

sudo systemctl start .......service
sudo systemctl enable .....service
systemctl status .....service

A qemu-t én is így használom, vagyis hasonlóan, csak én alias helyett shell scriptként indítom, de minden más hasonló, az -m, -cpu, -enable-kvm kapcsoló, virtio driver stb.. Fapados, favágó megoldás, de simán működik, nincs extra függőség, meg egyéb sallang. Egyébként meg a virtmanager se rossz (az is épp úgy qemu/KVM alapú), még az is sokkal jobb a Virtualbox-nál, stabilabb és nem kell külön kernelmodulokat feltenni minden egyes kernelfrissítésnél. Az ember egyszerűen sok ráncot lespórol így a homlokáról.

A virtuális lemezeket te mivel csatolod fel a host rendszer alá?

Küldtél be a javításodról patch-et az aur-ba? Anélkül te is elmehetsz a búsba... Már bocs. 

Én semmilyet, az fstrim-et használom helyette, azt is néha, karbantartás jelleggel, 1-2 hetente lefuttatva, kézileg indítok egy scriptet, ami terminálban kijelzi az összes SSD-m SMART adataiból kiolvasott állapotot (smartctl és nvme paranccsal lekérdezve, mennyi írás, éves, napos átlag szintjén, hány % van hátra az SSD élettartamából, ilyen átlagütemben tovább írva mikor érem el a TBW limitet), meg a végén fstrim -a -v parancsot hajt végre, ami az összes felcsatolt SSD-t trimezi. A legtöbb disztró is fstrim-et használ már, amit kb. 1 hetente ütemeznek egy fstrim nevű systemd service-szel, ritkábban cronjobbal (ha nem systemd-s disztróról van szó).

1-2 hetente nekem elég futtatni, nem sokat írok az SSD-kre, napi átlag 5 giga (per SSD, per gép) körül mindössze. Ennek is nagy része frissítéskor (pacman -Syu) történik, és természetesen néha többet, ma pl. lehúztam egy 45 gigás enmagos torrentet, egy sorozatévad AMAZON WEB 1080p-ben, de az ilyen kiugrások beleolvadnak a nagy átlagba, és kompenzálják olyan napok, amikor meg kevesebbet írok rá. Még a pacman cache, böngészőcache is ramdrive (tmpfs) van, de nem az SSD kímélése miatt, hanem úgyse tervezem az unokáknak bekeretezve eltenni. 1-2 hetente azért megejtem, lefuttatom kézzel a scriptet (gyorsbillentyűre hívom, nem kell gépelgetni, mint egy hülye, természetesen), már csak amolyan kíváncsiság szintjén is, hogy hogyan állnak az SSD-k, mennyi írás, hány fokosak, stb., hogy ha valami rendellenesen sokat írt rá vagy elkezdenek túlzott mértékben forrósodni, akkor észrevegyem időben. Néha érdemes ránézni, pont a Prohardveren volt 1-2 emberke, akiknél 1-2 bugos program rojtosra írta az SSD-tjüket ilyen 300 TB feletti mennyiségben okozva többletírást, és sajnos csak későn vették észre, mikor az SSD már belassult, furcsaságokat produkált, stb..

Ha akarod, használhatsz helyette természetesen a discard nevű mount paramétert, akár kézi mountoláskor, akár az fstab-ban. Ez igazából hittétel kérdése, hogy ki mire esküszik. Mindkét megoldás működik mindenféle fájlrendszeren, és mind SATA/AHCI, mind NVMe SSD-nél. Egyedül az NTFS-3G az egyetlen, amelyiknél az fstrim működik csak, discard opció nincsen, de ez is csak erre a userland-es 3G-s implementációra igaz, a natív kerneles (Paragon-féle) NTFS3 drivernél mindkettő játszik. Illetve még a ZFS lóg ki egy kicsit, mert azon nincs fstrim, de helyette van az fstrim-et kiváltó zpool trim utasítás, meg ugye a jó öreg discard paraméter.

Mindig is fstrim-et használtam, de 6 hónapig teszteltem néhány éve a discard-os megoldást is. Egyikkel sem volt problémám, teljesítménybeli különbséget se vettem észre. Vagyis f2fs-en volt problémám az fstrim-mel, azt egy f2fs driverben fellépő regresszió okozta, ismert bug volt, amit ki is javítottak egy idő után, ma már ezzel nem kell foglalkozni.

Mindjárt feltöltöm neked a scripteket valahova. Bár alapból nem fogod tudni használni, telepítened kell a függőségeket (calc, smartmontools, ha NVMe SSD-d van, akkor nvme), és bele kell javíts a scriptbe is, mert egy-két adat a te SSD-idnél különbözni fog, üzembe állítási dátum, smart attribútumok neve, TBW, stb.. De alapnak jó, hogy ki tudj belőle indulni.

Nálam is van az fstabban noatime, de nem én tettem bele, az Arch telepítéskor a genfstab nevű script hegeszti bele, én meg csak lusta vagyok kiszedni, meg amúgy is egyetértek vele, nem kell access time. Természetesen azzal sincs baj, ha a nodiratime-ot is felveszed, hibát nem követsz el vele, csak felesleges. Meg azzal se nyírod ki az SSD-t, ha az access time rögzítése nincs tiltva, akinek kell használja, nem okoz magas írásterhelést egy átlagos desktop rendszeren, vagy egy kisebb forgalmú szerveren. Annyi, hogy átlag felhasználó nem veszi hasznát.

A pacman-nak meg lehet adni a pacman.conf-ban a CacheDir = részben, hogy melyik mappába firkáljon, adj meg valami olyan mappát, ami tmpfs-re mutat, pl. /tmp/ vagy /run/user, de akár sajátot is csinálhatsz. Ezt sem az SSD kímélése miatt teszem, de még soha nem volt rá szükségem, hogy a pacman cache-ből kelljen valami, és csak állandóan begyűlt a cache sok gigára, lehetett állandóan valaminek a takarításával szarakodni. Elvileg még azt is lehet csinálni, hogy a pacman egyáltalán ne használjon cache-t, de ezt nem ajánlom, mert ha beakad egy telepítés, frissítés, és újra kell indítani a pacman parancsot, akkor ne kezdjen már elölről letöltögetni minden csomagot újra. tmpfs-ben legalább megmarad a cache újraindításig, vagy kézi törlésig.

Az SSD-khez már rég nem kell feketemágia. Modern rendszerek default jól kezelik. Ez még az SSD-k korai idejéből való, hogy fekete mágiával kell optimalizálni, mert akkor még sok user XP-n gányolt, meg klónozgatták az SSD-re a még HDD-s CHF-eltolással (63 szektor) particionált rendszereiket, és se az eltolás nem volt jó, se TRIM nem volt, meg volt néhány hülye, aki megszokásból futtatta rajta feleslegesen a defragot is. Max csak akkor fontos, ha valami spéci adattárolást használsz, RAID, LVM, LUKS, ZFS, virtuális lemezkép, mert ezeken az absztrakciós tétegeken át kell engedni a TRIM-et, egyébként a trimelést végző parancs nem jutna el a meghajtó vezérlőjéig.

Innen letöltheted a scripteket, ezek Samsung 860 EVO, Crucial MX300, Crucial MX500, Hynix BC511 NVMe, Intel 670p NVMe SSD-khez íródtak (voltak, vannak más SSD-im is, Adata SU650, Samsung PM800, stb., de ezeket külső SSD-nek használom, használtam csak). Ahogy már írtam, kellenek a függőségek, calc, smartmontools, nvme (utóbbi csak NVMe SSD-nél), meg bele kell aktualizálj mindegyikbe. Egy részük még régebbi Bash-specifikus script, ezeket már nem is használom (eleve már néhány SSD nincs is meg, amihez készültek), az újabbak POSIX kompatibilis shell scriptek (ezért van furcsán megoldva a script végén a billentyűfigyelés, és nem a szokásos read paranccsal, meg echo helyett fprint van), természetesen épp úgy működik Bash-sel is. A scripteket lehet egymásból hívni. doas-t használnak, ezt kicserélheted sudo-ra. A calc lecserélhető bc-re vagy dc-re.

Az az 513 csomag elég minimalistának hangzik, de a 400 mega az meg egy kicsit soknak. Igaz 2+ éve használtam, de akkor nekem egy régi inteles notin 140-170 MB között evett. Az új SSD milyen modell pontosan, és milyet váltott? Meglehet, hogy a régi lassult már be, de lehet valóban a sallangmentes rendszer is, főleg, ha a régi DE-kkel volt bloatosítva.

A Draculát én is szeretem, sötét, de nem túlságosan, meg nem unalmas szürke, hanem enyhe lilás beütés. Én most Tokyo Night-on vagyok (ez is kicsit lilás szürke), de csak neovim-ben, a WM-nek nálam sosincs témája, színezése. Egy háttérkép, meg felül egy fekete panel fehér betűkkel, meg általában a háttérképhez illő színnel van rajta egy-két elválasztókarakter, pl. | vagy ≣, de tényleg ennyi. Egyszerűen lusta vagyok komplett színtémát csinálni minden háttérképhez. Még a terminálomnak sem szokott lenni színtémája, az unalmas, sztenderd VGA/base16 színeket használom, de a shell prompt, fm6000 fetch, man, ls, stb. kimenete azért egységesen színezve van (jelenleg retró CGA neonlila-türkiz), meg egyes alkalmazásoknak van saját témája, neovim, mc, Vifm, htop, neomutt, saját scriptek, stb., mindegyiknek más, sőt, némelyiknek alternatív színe van, ha rootként fut. A terminálnak azért sem jó nagyon egyedi színtémát adni, mert vannak programok, amikben fixre drótozott (nem cserélhető, egyedi témából kilógó) színek vannak, és ezek legtöbbször nem mutatnak jól tetszőleges témával, egyenesen akár szarul nézhetnek ki, és belefáradtam ezzel küzdeni. Nem azért van a rendszer, hogy állandóan témázzak, meg csinosítsam, hanem hogy használjam.

zsh-t nem használok, de ahogy nézem, mindent jól csináltál. Amit megtennék, hogy megnézni, hogy a cache fájl létrejött-e az adott útvonalon, esetleg amikor már fut az zsh, akkor kézzel indítani shellből az autoload -Uz compinit && compinit parancsot. Esetleg még ami gyanús, az a matcher-list, próbaképp kikommentezheted, lehet csak az illeszkedik rosszul, és azért nem működik. Csak tipp. Basht használok, mert igaz, hogy az kevesebbet tud, de nekem elég (azért autocompletion-t, fzf history-t, aliasokat, stb. bedrótoztam), plusz a Bash sztenderd, fent kell lennie, mivel egy csomó más szoftver fixre drótozottan dependelhet rá, és feleslegesnek tartom, hogy ha már fent van úgyis, akkor egy másik shellt használjak. A zsh-val az is a bajom, hogy mire ezeket az extra modulokat beleintegrálom, kiegészítés, menük, stb., addigra bloat lesz a Bash-hoz képest. Sőt, igazából többféle shellt használok, a /bin/sh nálam a /bin/dash-re mutat, ami egy minimál POSIX shell és a scriptek is gyorsabban futnak benne, a login shellem /bin/bash, de ez nem zárná ki, hogy a terminálokat valami másik shellel indítsam, mert végül is szimpatikus a zsh és a fish is interaktív shellnek, de egyelőre még maradok a Bashnél. Esetleg ha arra annyira ráunnék, akkor váltok valami másra. Van még a nushell és elérhető a MS-féle powershell is, de azok vicc kategória szerintem. A tradicionális Unix shellek (ksh, csh, tcsh, stb.) nekem meg túl fapad interkatív shellként, elég buták, és elég korlátozottan okosíthatók.

Ami a mime-t illeti, az ugyanaz X-en és Waylanden is. Attól is függ, hogy milyen programokat használsz. Ha mindent terminálos programokból nyitogatsz, akkor nincs rá szükség, WM-nek sincs rá szüksége. Csak azoknál a GUI és egyéb terminálos programoknál számít, amelyek valami freedesktop/xdg-open megoldással dolgoznak, mert ők az általad is betett mime-config alapján döntik el, hogy melyik alapértelmezett alkalmazással milyen fájlokat nyissanak meg, azt se kiterjesztés, hanem kontent/mime alapján. Nálam pl. csak a Firefox miatt kellett, mert régen rákérdezett egyes fájltípusoknál, hogy mivel nyissa meg, ezt a funkciót mintha kiszedték volna (rákérdez, hogy megnyissa-e vagy mentse, de megnyitásnál nem engedi állítani, hogy mivel nyissa meg), és néhány fájltípusnál (pl. képek) állandóan Wine-ban akarta megnyitni a szemét a fájlokat. Ez ellen kettős védekezést valósítottam meg, egyrészt a winecfg-ben kivettem az asztali integráció fülön a pipát a „társítások kezelése” opció elöl, másrészt a stackoverflow-ról szedtem egy scriptet, amit átalakítottam, és fzf-fel kiválaszt egy fájlt, arról eldönti, hogy milyen mime típus, majd szintén fzf-fel enged kitallózni egy .desktop fájlt, hogy milyen alapértelmezett alkalmazással nyissa meg, és ennyi. Itt a kódja (fzf és xdg-utils kell neki):

#!/bin/sh
FAJL=$(cd /;fzf)
FILETYPE=$(xdg-mime query filetype /$FAJL)
APP=$(fd -H .desktop / | fzf)
APP=$(basename -- $APP)
xdg-mime default "$APP" "$FILETYPE"
echo "$APP set as default application to open $FILETYPE"

Egyébként nincs mit. Azért is szoktam ilyen részletesen írni, mert van relevanciája, csak sok fórumozónak hosszú meg érdektelen szokott lenni. A swayimg-t nem ismerem, hogy az mit tud, én anno imv-t használtam, bár nem azért, mert az volt a legjobb, hanem akkoriban kb. az egyetlen olyan kicsit is használható képnéző volt, mi tényleg tudott natív Waylandet, sok más választás nem volt. mpv, firefox, zathura, ffmpeg, normális terminálos text editor (vim-változatok, Emacs, micro, helix, kakoune, jed, stb.), egyéb kombónak még X-en (sőt, néha Windowson) sincs párja. Minimalisták, gyorsak, részletesen konfigurálhatóak (és általában pluginelhetőek), modális módban, gyorsbillentyűkkel irányíthatók, nagyon hatékonyak emiatt. Főleg akkor mutatkozik meg az igazi erejük, ha valami régi, gyenge gépen, vékonykliensen, SBC-n van az ember, pl. egy zathura milyen villám módon vágja képernyőre, meg milyen vajsimán lapozza a több ezer oldalas pdf-eket is, amikkel a hagyományos GUI pdf-nézők (Evince, Okular, Foxit, Adobe Reader) még erősebb hardveren is beakadhatnak, belassulhatnak.

A másik előnye akármilyen gépen a sebesség. Hiába is mondják az átlag userek, hogy őket nem érdekli, mert úgyis i7-i9-esük meg Ryzenük van, meg sok giga RAM, azért még ilyen gépeken is számít, hogy a bootidő 3 mp. (nem 9-30), az alkalmazások azonnal pattannak képernyőre, még pár ms-os mikrolag sincs, nem kell soha semminek a betöltődésére várni, splashscreen-eket nézegetni, stb.. Aki hozzászokott ehhez a gördülékenységhez, gyorsan reagáló rendszerhez, annak nagyon fájdalmas egy hagyományos Win, MacOS, Gnome, KDE, Budgie, Cinnamon, stb. ökoszisztémára visszamenni, ott GUI-s bloatok lomhaságát elviselni, hibernálgatni, meg az is lényegesen lassabb, hogy mindenféle elrejtett ikont, GUI beállítási lehetőségeket keresgetni, egérrel végigkattintani, egy gyorsbillentyű, vagy 2-3 karakteres fuzzy find benyomása helyett.

Ezt lehet én is megcsinálom. Még külön tmpfs-t se kell neki csinálni, mert a /tmp/ Archon default tmpfs máris, elég csak a yay-t vagy paru-t beállítani, hogy a .cache mappát a /tmp/akármi/-be tegye.

Ez melyik kernel amúgy, egy időben használtam én is a linux-amd-znver2 kernelt a Ryzen 4700U-s gépen. Ez nem Zen-kernel, hanem 3+ generációs (Zen2) Ryzen procikhoz és AMD GPU-khoz készült. Baj nem volt vele, de kicsit lassabbnak és bloatabbank tűnt, mint a gyári Arch kernel, és meguntam, hogy 1-2 naponta újraforgatta az egész kernelt. Van egy másik is, linux-amd, az már a leírása szerint Zen3-hoz, van most olyan procim is, Ryzen 6800H, de még nem próbáltam.

Nem vagyok benne biztos, de úgy emlékszem, hogy replace-nél eltávolítja a régit. Nyugodtan meg kell ilyenkor engedni neki, ez csak egy sima csomagátszervezés volt, magát a rendszer működését nem érinti. Én egyébként utálom ezt az at-spi-szutykot, főleg a Firefox és még néhány Gtk3, Gtk4, Gnome függőségeket használó GUI-s program használja. Eltávolítani nem lehet, mert a hiánya eltör egy csomó mindent, de én kvázi letiltottam, így nem indul automatikusan (csak a Firefox indítja el, mikor az indul). Ehhez a login shellem rc-jébe felvettem az export NO_AT_BRIDGE=1 sort, meg az /etc/xdg/autostart/at-spi-akármi fájlt töröltem. Ilyenkor tud bejönni a Gentoo előnye, ott a Firefox forgatásánál ki tudod kapcsolni ezeket a szutykokat, hogy pl. ne kelljen neki Pulseaudio, Orca reader, at-spi-modul, stb.. Archon viszont belefordítják ezeket, mert generic disztró, és mindenféle user/felhasználási igényt le kell fedjen. Ha kiszedegetnének belőle ezt-azt, akkor jönne a tömeges sírás a felhasználóktól, hogy nem megy, szar a Linux, instabil a rolling, bla-bla.

Lehet ez valami alapértelmezés. Elvileg a mount parancs és az fstab sorában meg tudsz adni extra csatolási paramétereket, már nem is emlékszem, vagy permission= vagy valami mask= (ez fordítottja a permisson-nek) paramétert, ahol be tudod állítani, hogy milyen jogokkal csatolja. Az a baj, hogy most megyek melózni, hirtelen nem találom a doksiban, az Arch Wikinek valami mély bugyrából rémlik.

De az is jó, ha teljesen kiveszed ezt a /var/cache/pacman/pkg csatolást, és simán használod a /tmp/ mappát, a /etc/pacman.conf fájlban meg tudod adni, hogy mit használjon cache-mappában. Pl. CacheDir = /tmp/ vagy hasonló.

Vagy akár ignorálhatod is, ez a figyelmeztetés, nem valós hiba. Elvileg valóban biztonsági kockázat egy rendszermappára 1777 jogokat adni (ez a legteljesebb jogkör), de most egy pacman cache esetében ez nem jelent gondot. Valami gonosz szoftver bele tud rondítani, aztán mi van? Következtő bootkor úgyis törölve lesz, pacmant indítani nem lesz úgy se joga hozzá, így nagyon egy ártó kód sem tud ezzel visszaélni. Ezt a pacman csomag telepítőscriptje viszont nem tudja, az úgy van beállítva, hogy rendszermappáknál meg az ilyen nem egyező jogosultságoknál automatikusan figyelmeztessen, emlékeztessen a biztonságilag helyes gyakorlatra. Túl komolyan nem kell venni, ha egyébként tudod mit csinálsz.

Conky-nak sajnos nincs alternatívája Wayland alatt. De szerintem a Conky-nak X-en sincs értelme. Ami infót kell állandóan látni, tegyed ki a panelre, amit nem kell állandóan látni, arra írsz egy scriptet, amit bedrótozott gyorsbillentyűre meghívsz és vagy értesítésekként írja ki a dolgokat, vagy egy terminálban.

Időjárásra én ezt használom (illetve használtam Sway alatt is) terminálban megnyílóként:
curl wttr.in/~varosod_neve?3Fq

Bár nem vagyok vele elégedett, mármint nem a technikai részével, mert az rendben van, hanem ez a wttr.in sokszor csak túlterhelt, nem jön be, illetve amit ír időjárást, az sincs sokszor köszönőviszonyban azzal, amilyen idő utána igazából lesz, még 12 órára előre se találják el.

Swaynál, Waylandnél alapszabály, hogy türelmesnek kell lenni, egy csomó konfigolást igényel. Menni fog az, nem kell feladni, ha nem megy elsőre. Utána kell nézni a dolgoknak, X-es programokhoz alternatívákat kell keresni, konfigfájlokat türelmesen megírni. Mivel minimalista tiling WM, ezért sok mindenről neked kell gondoskodnod. Ez nem Gnome, meg Xfce, ahol minden be van készítve, mindenféle panel, applet, értesítések, stb.. Sok apró beállítás kell, több mindent saját scripttel kell megoldani, de megéri, mert utána olyan rendszered lesz, ami tényleg a kezed alatt lesz, úgy működik, ahogy te akarod, és nem lesz benne a corporate overlordok bloat sallangjai.

Ezzel én is találkoztam, épp írtam a Pipewire topikba. Természetesen kiderült, hogy semmi köze a Pipewire-hez, Wireplumber-hez, sem a Sway/Wayland-hez. Ez egy AMD Zen platformbug, ami a prociban lévő fTPM-et érinti. Nekem is előjött Ryzen 6800H-n, de a 6.2.x-es kernelekben már javították, illetve több alaplapgyártó is adott ki erre új BIOS-t, sajnos az enyém laptop, nem asztali gép, és ezen nem javították.

A 6.1-es kernellel jelent meg először. Az oka, hogy az fTPM-mel összeakad a hardware random generator funkció.

Az még nem is lenne baj, ha nem lenne kötelező használni. De sajnos a sok soydev erre dependeli a szoftverét, és emiatt használni kell. Ha tényleg nem lenne semminek függősége, akkor mindenki használhatna olyan initrendszert, amilyet akar, akinek a systemd kell, az azt, aki meg utálja, mint mi, az meg feltehetne mást.

Persze most is lehet alternatív initrendszert használni, sysvinit, OpenRC, runit, s6 init, stb., csak ahogy feltesz az ember valami systemd-re dependelő szoftvert, azonnal felmegy a rendszerre az elogind, ilyend, olyand, arról nem is szólva, hogy udevd is megy alapból a nem systemd-s disztrókon is, így meg az ember csak áltatja magát, hogy ő más initrendszert használ, ha egyszer a háttérben épp úgy futnak a systemd részei, akkor már csinálják az initet is. Ez benne a kicseszés. Inkább olyan a systemd, mint a rákos daganat, nem lehet tőle megszabadulni, mindenhova áttétet képez.

Ez a homed se kellett a háta közepére senkinek, de nem bírták ki, hogy beletegyenek egy újabb bloatot.