Keresés

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

  • Frawly

    veterán

    válasz Shyciii #7342 üzenetére

    Én kézileg mountolok, ha annyira gyakran csinálnám, akkor írnék rá egy fzf scriptet, ami az lsblk által listázott eszközök közül engedne választani, meg utána néhány célmappa között, és felcsatolná fuse mount-tal, hogy ne kelljen hozzá root jelszó, meg ne csak root tudjon hozzáférni a felcsatolt meghajtóhoz.

    Androidos telót jmtpfs-t használó scripttel csatolom fel, megint gyorsbillentyűre meghívva. Notification sem kell egyáltalán, nem használok olyat, a script terminálablakban mutatja a csatolás sikerességét vagy sikertelenségét, ha tudomásul vettem, bezárom a terminálablakot.

    A gvfs bloat, de azt elismerem, hogy aki sokféle eszközt, meghajtót, virtuális FS-t csatolgat fel, ebből áll szinte a napja, annak megéri feltenni, mert kényelmes automatikus megoldás, meg egy csomó fájlkezelő is natívan kezeli a gvfs-es megosztásokat. Tehát bloat, de egyes esetekben kínálhat olyan előnyt, amikor a bloatsága indokolható. Én kb. minden 2 hétben egyszer csatolok fel, egy nyomorult eszközt, azért ne fusson mindenféle gvfs folyamat a háttérben. Nagy tévedés, hogy 35 MB-tot foglal, vagyis lehet annyit, de csak a fő gvfs process, de futtat az ám egy csomó gvfs-blabla folyamatot is, és végeredményben úgy bekajál 80-100 MB memóriát is akár, hogy jó recsegős-kolbászosat böffent utána, nálam meg az egész grafikus felület nem eszik ennyit, ennek jó a felét foglalja mindenestől, feh, polybar, picom-mal együtt.

    Meg azt is szem előtt kell tartani, hogy aki full Gtk-s DE-t használ, annak már be van töltve a memóriába egy csomó gtk-s lib, így a gvfs ezeket tudja shared library-ként használni, újra ezeket nem tölti be, így pedig ebben az esetben sokkal kevesebb plusz memóriafogyasztást okoz. Így Gnome, Xfce, Mate, Cinnamon, LXDE, Budgie, stb. alatt okés lehet a használata. Én viszont gtk-s programok közül csak egyet használok rendszeresen, az a Firefox, és nagy ritkán Wine, Steam használja még, így nem ezek nálam nincsenek betöltve shared library-ként, extra 80-100 MB memóriafogyasztást meg nem akarok. Nem mintha a 16 giga RAM-ba nem férne bele, de a minimalilzmus a bootot is gyorsítja, a rendszernek induláskor negyede, ötöde szutykot kell betölteni, a procinak is sokkal kevesebb munka kevesebb kódot futtatni, a lemezeknek (hiába SSD, az egyik ráadásul NVMe) is kevesebb munka töltögetni. És hiába mondja uby, hogy +x MB nem tétel több giga RAM-nál, és valóban nem, de egy kis 100 ms itt, egy kis 200 ms ott, a sok apró sallang betöltése meg a végén sokra megy, mikor már 30-100 ilyen összegyűlik. Én is használtam korábban ezeket a bloat megoldásokat, de aztán rájön az ember, hogy ezek mind kiválthatók, nélkülözhetők.

  • Frawly

    veterán

    válasz #63718632 #7330 üzenetére

    Az Arch telepítés nem csak pacmannal telepítésből áll. Az is igaz, hogy pl. a particionálást a legtöbb partíció formázását csak egyszer kell megcsinálni, utána újratelepítéseknél elég már csak a root partíciót formázni. Azon túl meg csak loadkeys, genfstab, locale.conf szerkesztése, locale-gen, pacstrap base linux möhöh, arch-chroot, cat "blabla" > /etc/hostname, /etc/vconsole.conf szerkesztése, pacman -S csomagok, stb.. Bár mirrorlistet se árt szerkeszteni, kikommentelni, hogy melyik közeli szervert használja. Aztán grub-install, grub-mkconfig, passwd root, useradd -G blabla, paswd userneved, exit, umount -a, reboot.

    Hardveres óra állítása nem szokott kelleni, időzóna telepítés után is beállítható systemctl-lel, nagyon más nincs. Persze most csak elnagyolva foglaltam össze.

    Én azért sem csinálok telepítőscriptet, mert szinte mindig másmilyen rendszert építek, hiába is lenne régről scriptem, ha egy csomó telepítési lépést máshogy csinálok, más csomagokat telepítek, stb..

    Script nélkül sem nagy munka telepíteni, mert a gépelgetés nagyja is megúszható, Tab billentyűre kiegészíti a parancsokat, mindig csak egy-két karaktert viszel be, utána már Tab-ra fel kéne ismernie, hogy mit akarsz írni.

  • Frawly

    veterán

    válasz #63718632 #7324 üzenetére

    Ebben igazad van, hogy emlékeztetőnek is jó a script, erre nem gondoltam. Scriptet írni nem nehéz, lényegében egy #!/bin/bash sor után szépen sorban beleírod a parancsokat, amit kézzel is kiadnál, mentés után meg chmod +x paranccsal futtathatóvá teszed. Kicsit bonyolultabbá akkor válik, ha valami változót használsz, meg feltételes elágazásokat, de ha valamilyen prognyelven programoztál már, akkor az se húzós.

  • Frawly

    veterán

    válasz szuszinho #7320 üzenetére

    Ez biztosan nem lehet, mert az iptables a base csomag részét képezi, és a kernelbe is bele vannak fordítva a hozzá szükséges modulok, Archon a kernel elég fullos konfiggal van fordítva, nem nagyon van belőle kihagyva semmi.

    Én inkább SSL hibát gyanítok a háttérben, esetleg jogosultság nincs meg. Ez a nem tudsz belépni mit takar, mi a hibaüzi PONTOSAN, szó szerint?

  • Frawly

    veterán

    válasz #63718632 #7318 üzenetére

    A saját scriptet nem ajánlom, mert nagyobb munka megírni meg folyamatosan gondozni, mint a rendszert feltelepíteni. És ha scriptet használsz, nem fogod látni, hogy mi miért nem megy, kifelejtettél-e valamit, vagy a rendszertelepítés menete változott, amihez a script nincs hozzáigazítva.

    Így én egy pacman -Qq csomaglistán kívül semmit nem mentenék. Elvileg a felhasználód beállításai meg megmaradnak, ha a /home-ot külön partícióra tetted.

    Nálam ezért is rövidebb az Arch telepítése, az EFI /boot és a /home is külön partíciókon vannak, így egy újratelepítéskor csak a root partíciót formázom, meg arra telepítek, a boot és home része a régi telepítésből van, így egy csomó telepítési lépést kihagyhatok, megspórolhatok reinstallkor. Persze a home-ot sem egyben húzom vissza, általában átnevezem a régi /home/felhasználkói-mappát, de fontos-alap config fájlokat visszahúzok belőle.

    Esetleg a /etc/ mappából lehet még pár fontos config fájlt elmenteni, pacman.conf, ntp, hostname, /etc/systemd/system.conf, sudoers, stb., de ezt nem szoktam részemről megejteni.

  • Frawly

    veterán

    válasz #63718632 #7317 üzenetére

    Ja, akkor jó. Bár azt hiszem, hogy az xfce4 csomagcsoportnak be kéne húznia a gvfs-t függőségnek. Ezért mondom, hogy fullos DE-vel nem nehéz Archot (meg Gentoo-t) telepíteni, mert a DE behúz minden függőséget, beállít mindent, gondoskodik mindenről.

    Minimalista WM-nél van az, hogy semmiről nincs gondoskodva, fel is soroltam sok ilyet, a meghajtók automata csatolását, és még pár dolgot pont kifelejtettem a példák közül.

    Mondom, a minimalista WM az olyan, elindítod, kapsz egy szürke/fekete hátteret, egy egérkurzort, de semmi nem működik. Semmi. Kattintgathatsz akárhova, se ikonok, se dokk, se semmi. Egy-két minimalista WM néha mégis tartalmaz panelt vagy jobb klikkes asztali indítómenüt (pl. dwm, xmonad, stb. tartalmaz egy minimalista panelt, az Openbox, Fluxbox tartlamaz indítómenüt, az IceWM tartalmazza mindkettő), de ez inkább kivétel már, mint fő szabály.

    A legdurvább ilyen szempontból a bspwm, az még a billetnyűleütéseket sem kezeli, ahhoz is shkxd-t kell feltenni kézzel, és bekonfigurálva a WM-mel indítani, különben még kilépni sem lehet belőle sehogy, csak ha konzolra átvált az ember és kilövi a xorg folyamatokat.

    A DE viszont pont attól DE, hogy minden bele van készítve, WM, kompozitor, tálca, ikonkezelés, témázás, mindenféle automata mount, hálózati megosztásos csatolása, archívumkezeléses, értesítős bizbasz, hozzákörítve mindenféle alap alkalmazással, szövegszerkesztő, fájlkezelő, böngésző, panelappletek, vezérlőpult, stb.. Viszont cserébe egy minimálisabb WM-hez képest megeszik +200-500 MB lemezhelyet, és +100-1000 MB memóriát, attól függően, hogy milyen DE-ről van szó, miket tartalmaz, milyen libeket használ (Qt, Gtk, melyik alverzió). De nyilván más igényeket és felhasználási kört fednek le a különböző DE-k és WM-ek.

  • Frawly

    veterán

    válasz #63718632 #7311 üzenetére

    Az első felét megválaszolta a kolléga. A /run/ mappában hozd létre kézzel a media mappát. Vagy csinálsz a ~/ mappádba csinálsz egy megosztási mappát, és szimbolikus linket hozol létre hozzá, ami a /run/media-ra mutat:
    ln. -s /home/felhasználónév/csatolási_mappa/ /run/media/

    Bár azt sem értem, hogy mi az, hogy /run/media-ba csatolódnak? Mi csatolja őket oda? Magától semmi nem csatolódik Linux alatt, az ne tévesszen meg, hogy nagyobb DE-knek van automount szolgáltatása, ez nem alapból adott minden grafikus felületen, meg rendszeren. Te oda mountolod, ahová akarod, akár az fstab-ban, akár kézzel vagy scripttől, terminálból. Lehet ha automata megoldás csatolja, akkor létrehozza a /run/media/-t.

    Xorg indítása előtt nincs nagyon tennivaló, főleg, ha olyan fullosabb DE-t futtatsz, mint az Xfce4. Ha kisebb WM, akkor annak az indulása előtt lehet indítani szükséges dolgokat ~/xinitrc fájlban (dbus szolgáltatás, vagy valami más kézi apróság, amit a WM nem old meg saját hatáskörben), de ezt lehet a WM indulásával együtt autostartba is tenni általában.

    Neked ilyesmire duplán nincs szükséged, mivel az Xfce4 mindent intéz, kompozitálás, dbus, panel, háttérkép, panelappletek, értesítések, billkiosztás, egérbeállítások, és nem te indítod startx-szel, hanem elvileg lightdm-et tettél fel, és abból indul. Így semmi állítani való nincs, a X.org mindent detektál. Xorg és login manager telepítése után vagy újraindítod a rendszert, vagy elindítod sytemctl enabla loginmanageres && systemctl start loginmanagered paranncsal a login managert, és mehet a móka. Fontos, hogy a login managered systemd service-ét engedélyezni kell, különben újraindításkor nem fog indulni a rendszerrel, hanem neked kell mindig kézzel elindítani.

    Állítgatni csak minimalista rendszeren kell, de ott sem a X.org-ot magát általában, hanem a WM autostartjában futtatni a fentebb sorolt dolgokat, hogy legyen minden, mert a minimalista WM-ek általában alapindulásban SEMMIT nem tudnak, se háttérkép (fekete vagy szürke háttér van csak), sokszor panel se, se indítómenü, se képernyőkikapcsolás, se egér/bill-beállítás, se semmi, mindenről neked kell gondoskodni. A fullos DE-k viszont eleve úgy jönnek, hogy minden be van állítva, neked már csak grafikus menükben testre kell szabni (téma, panel megjelenése, háttérkép váltása) és használni a rendszert. Viszont ennek megvan a hátránya is, mert tömegigényekhez állítják be, meg eldöntik milyen komponensek legyenek benne, és ezeket vissza kell csinálnod kézzel, le kell szedegetni.

  • Frawly

    veterán

    válasz #63718632 #7309 üzenetére

    A X.org alaptelepítésben tartalmaz egy úgynevezett TWM nevű (Tom's Windows Manager) minimalista ablakkezelőt, egy nagyon régi, 30+ éves, elavult, bűn ronda valami, de ha nem tudsz konzolhoz hozzáférni, arra jó, hogy elindítsad a TWM-et mondjuk LightDM-ből, és ott megnyitva egy terminált be tudod veretni a parancsokat, tudod telepíteni, amit kifelejtettél, és nem kell megint telepítőben elölről mountolni, meg arch-chroot-ozni. Persze célszerűbb inkább konzolt lenyitni, de csak vész esetre mondom, hogy ilyen lehetőség is fennállhat.

  • Frawly

    veterán

    válasz #63718632 #7298 üzenetére

    Ezt a három csomagot elvileg behúzza a base csomagcsoport, de azt nem kötelező használni.

    Igazi hardveren jobban járnál vele, úgy valósabb tapasztalatot szerzel, látod hogy fut, milyen driverek kellenek. Virtuális gépben elődordulhatnak bugok, és nem fogod tudni, hogy az Archban van a bug, vagy a virtuális gépben. VBox alatt egyébként a hardverekhez vbox guest csomag kell, már nem tudom mi pontosan a neve, bár lehet most már a kernelbe is bele vannak forgatva, rég telepítettem virtuális gépre.

    Magyarítást nem ajánlom. A magyar (hu, 105 gombos, sztenderd) kiosztás oké, meg az UTF-8, ezzel lesz magyar billentyűzet és minden ékezetes karakter, nyomdai jel, stb., de a teljes rendszer magyarítását nem ajánlom. Nem azért, mert nem lennék ősmagyar hazafi, de angol rendszeren nem kell mindenhez külön még magyar nyelvi csomagot töltögetni (Firefox, LibreOffice, KDE, tököm tudja mi), nem lesznek félig és félrefordított dolgok. De a legjelentősebb érv, hogy ha valami problémába futsz, akkor az angol nyelvű hibaüzenetekre rákeresve valamelyik netes keresőben sokkal több találat lesz, hamarabb találsz megoldást, könnyebben követsz tutoriálokat, mert össze tudod vetni, hogy ott mit írnak, mit kéne kiírnia a parancsnak, és ehhez képest nálad mit írt ki.

    Persze, használhatod magyarul, működik, akkor a locale.conf-ban hu_HU.UTF-8-at adsz meg (vagy kiveszed ezen sor elől a kommentjelet) és ezután adagolod be neki a localegen-t, de ezzel kulturális buborékba zárod magad, meg később a rendszeradminisztrálást megnehezíted magadnak.

    A linux-firmware csomag mindig kell. Régen ez a base része volt, nem is értem miért vették ki, csak arra jó, hogy kifelejtsék az emberek telepítéskor. Xorg-ot és DE-t mindegy mivel telepíted, sudo vagy su root, csak legyen telepítési jogod, meg tudj a /usr/bin, /etc, stb. mappába írni.

    Grafikus login managerből vissza tudsz váltani konzolra, Ctrl+Alt+F2, vagy Ctrl+Alt+F3-F7, nyomogatni kell, míg nem kapsz valami konzolt. Bár ez tényleg függ, hogy a virtuális gép ezt hogy kezeli-e, hogy van beállítva, host OS elnyeli-e ezeket a billentyűket. Mondom, valós hardverre telepítve, mondjuk pendrive-ra, külső merevlemezre telepítve jobban járnál vele.

    De mint te is látod, egyre jobban belejössz. Ehhez türelem kell, meg utánajárás, rá kell szánni az időt, de később kamatozik.

  • Frawly

    veterán

    válasz #63718632 #7295 üzenetére

    Ez ilyen, kezdőként egy számára ismeretlen haladó disztrón mindenki bénázik. Anno én is megszenvedtem az Arch-csal, igaz akkor én mindjárt LVM LUKS-ra akartam telepíteni, ami nehezebb, valami 6. nekifutásra ment csak, az első kísérlet nagyon csúfos és villámgyors kudarccal végződött (akárcsak egy éve a Gentoo). De ha kitapasztaltad, akkor utána már minden reinstall egyre könnyebb, már érted és tudod mit csinálsz, emlékszel milyen csomagok kellenek, melyik konfigfájlban mit kell átírni (konfigot vissza is lehet húzni mentésből).

    GRUB az ilyen, nem elég feltenni, még konfigurálni is kell, ami alapból csak egy parancs, nem nagy szám, de könnyen kifelejthető lépés.

    Milyen nettel akarsz netezni? Vezetékes vagy Wi-Fi? Milyen hardver pontosan, márka, típus? Az Arch-nak van erről szócikke, Wi-Fi-ról külön, hogy lspci-vel beazonosítod a hardvert, majd lsmod-dal listázva megnézed, hogy kernelmodul töltődött-e be hozzá, majd ip link paranccsal megnézed UP állapotban van-e (ha Wi-Fi), majd konfiguráció után nyomod neki a hálózati szolgáltatás indítását, vagy a dhcpcd-t.

    A konfigurálás attól függ, hogy mivel akarod menedzselni a hálózati kapcsolatokat. A legnépszerűbb (és egyben legbloatabb) a Network Manager (hozzá nm-cli, nm-gui, nm-applet), ami a systemd netctl-re épül, az meg a wpa_supplicantra és dhcpcd-re. De lehet simán netclt-lel, lehet csak wpa_supplicant és dhcpcd egymagában, lehet iwd vagy connman (ez az Artixosok meg colomb2 kolléga kedvence), számtalan módja lehet, mindegyik megoldásról van önálló Arch Wiki cikk.

    Neted sokféle okból nem lehet. Nincs fent a linux-firmware csomag, nincs fent megfelelő kernelmodul (ha a kártya igényel ilyet), nincs bekonfigurálva, vagy be van, de dhcpcd nem fut és nem kap IP-t, stb.. És ezeket telepíteni is kell, meg reboot előtt, mikor még van a telepítőben neted. Nem szabad kifelejteni egy kapcsolódó csomagot sem, mert akkor a rebootolt rendszeren már nincs az, hogy elfelejtetted, mert net híján nem tudsz hiányzó csomagokat telepíteni, hanem újra kell telepítővel vitézkedni, live boot, partíciók felcsatolása, arch-chroot, stb..

    De érdemes nekifutni, megcsinálni, mert csak egyszer kell kitapasztalni, utána mindig menni fog. Ha ezeket kitapasztalod, utána lényegében már a saját disztród építed fel, és nem leszel másnak a disztrójára, flavorjére, forkjára, remasterére, installer scriptjére, mások defaultjára szorulva, hanem csinálod magadnak a sajátot, Arch alapokon, olyan beállításokkal és csomagokkal, amilyet akarsz, olyan grafikus felület, olyan téma, olyan login manager, olyan megoldás, amilyet akarsz.

    Mindjárt az egész géped konfigját is írhatod, milyen GPU, milyen proci, milyen grafikus felületet akarsz, ezekre is tudok tanácsokat írni, hogy milyen csomagokat célszerű feltenni, mikre kell figyelni.

  • Frawly

    veterán

    válasz #63718632 #7292 üzenetére

    Jól gyanítod, akkor kell multilib tárolót engedélyezni, ha 32 bites programokat akarsz használni, pl. Wine, Steam, meg még van egy pár.

    Vanilla Archnak nincs telepítője, te telepíted kézzel. De talán egyik Arch származékon sincs alapból engedélyezve telepítés után a multilib, azt neked kell beállítani, a /etc/pacman.conf fájlban kiveszed a kommentjelet a [multilib] sor és a közvetlenül azalatt lévő Include = /etc/pacman.d/mirrorlist sor elől, elmented, lefuttatsz egy pacman -Syy-t, és már telepíthetsz is a multilib tárolóból. Nem egy nagy szám engedélyezni.

  • Frawly

    veterán

    válasz Archttila #7290 üzenetére

    Ez nyilván egyéni ízlés kérdése is. Meg attól is függ, hogy milyen képernyőn használod, mekkora felbontás, milyen jó a szemed, mihez szoktál hozzá, mekkora DPI, akarsz-e ligatúrát, nerd fontos kiegészítéseket (szimbólumok programozáshoz, terminálos fájlkezeléshez, panelekre, shell és vim powerline-hoz), stb..

    Ami még nem rossz, az a Monokai, Operator, meg MacOS alatt a default terminálfont, annak már elfelejtettem a nevét, de az se néz ki rosszul, én nem használtam még, de sok YouTube-videón látom, ahogy használják. distrotube elég régóta Mononoki Nerd fonttal tolja, az is egész jól néz ki.

    De még olyan állat is van, aki ilyen IBM Plex, VAX, cpi437 DOS/BIOS-klón, Commodore 64 klónfontot használ (C64-es kék színekkel), lenyitható Guake terminálban Quake 1 játékfontok, igaz ők egyben retróőrültek is, és ez a perverzitásuk sokszor már az olvashatóság rovására megy, de ők élvezik, hogy különcködnek.

    Nagyon jó ötleteket lehet meríteni fontok terén is (meg színséma, terminálos programok, CLI/TUI alkalmazások), a reddites szálakból, unixporn screenshotokból, youtuberek képernyőképéből. Nem csak a linuxosokét lehet nézni, hanem BSD-sekét, Mac-esekét is, azok között is vannak jók, amiből lehet ellesni jó dolgokat.

  • Frawly

    veterán

    válasz Frawly #7288 üzenetére

    A szárazon azt értem, hogy túl szabályosak benne a fontok, egyenes vonalakból és szabályos körívekből állnak, így túl szabályos, túl unalmas az egésznek a megjelenése, kicsit hideg, gépies, stílustalan. Ezért szeretem a Fantasque fontot, mert vidám, kézírás jellegű, de mégis jól olvasható, nem sivár, nem túl szabályos, emberibb.

  • Frawly

    veterán

    válasz Archttila #7287 üzenetére

    A Hack egy szolid font, valóban nem rossz. Az én ízlésemnek egy kicsit száraz, meg Unicode-karakterekből támogathatna többet, de végül is egész jó, valóban.

    Amit még érdemes megnézni a Hack-en kívül, aki jó terminálos fontot akar: Fantasque Sans Mono (ezt már próbáltad, de a többieknek is ajánlom), Adobe Source Code Pro, Fira Code/Nerd, Dejavu Sans Mono, Iosevka, Inconsolata, MS Cascadia, Ubuntu Mono/Nerd, Input Mono, Terminus (ez utóbbi legjobb szöveges tty konzolban).

  • Frawly

    veterán

    válasz szuszinho #7281 üzenetére

    Ez attól függ milyen szerver. A partíciók felcsatolása persze, hogy számít, mert először a root-ot kell felcsatolni, utána az annak a mappáiba csatolt egyéb partíciókat, és csak utána mehet a genfstab script futtatása, meg az arch-chroot.

    Bootloader annak függvénye, hogy mit használsz. Szerintem a systemd-boot elég egyszerű, csak a UUID-kre kell figyelni. Az EFI stub boot még egyszerűbb, de az nem minden UEFI-vel megy. És itt végig UEFI-t emlegetek, mert már minden szerver tudja.

    De hagyományos MBR + Legacy bootnál sem olyan nehéz GRUB2-őt telepíteni, lényegében:
    pacman -S grub && grub-install --target=i386-pc /dev/sdX && grub-mkconfig -o /boot/grub/grub.cfg

    De az a lényeg, hogy sikerült feltenned. Ez az Arch ilyen, először belerakod a munkát, de aztán kitapasztalod, hogy mit hogy kell, és többé nem leszel semmilyen más disztróra rászorulva, hogy menjenek a hardvereszközeid, menjen a bootolás, dualboot, multiboot, stb., nem leszel installer bugoknak kitéve, mert kézileg bármikor tudsz magadnak Archot telepíteni. Nem kell többé disztróhoppolni (hacsak nem akarsz még minimalistább disztrót, meg systemd-mentes megoldást), csak azért, mert az adott gépen egyik disztróval mennek a dolgok out of the box, máskor meg csak a másikkal.

    Archot egyébként csak akkor nehezebb telepíteni, ha túl spéci beállítás kell, RAID, LLVM, LUKS, és hasonlókkal van bonyolítva, meg Secure Boot, és társai. Na, akkor tényleg nagyobb munka. De csak házi szerverre, meg hagyományos desktopra felhúzni titkosítatlan ext4 partíciókra nem valami nagy szám, elég könnyen meg lehet tanulni.

  • Frawly

    veterán

    válasz Archttila #7279 üzenetére

    A distrotube-os fazonnak a gitlab tárolójában vannak ilyen Bash-sal vagy más shellel indítható színes mintákat random generáló scriptek, amivel csinosítja a megnyitott terminált. Ilyesmik, amik a te képernyőképeden is látszanak.

  • Frawly

    veterán

    válasz BoB #7276 üzenetére

    Kösz szépen a kioktatást, de épp ezzel kezdtem, hogy a haveged-et csak akkor ajánlom, ha a bootolás megakadna, én is innen ismerem. De azt kell érteni, hogy csak 1-2 gépen történik ez meg, akkor is kernelverzió és disztrófüggő. Legújabb kiadású disztrókon, meg nem túl régi hardvereken ez úgy ahogy van, nem szokott probléma lenni. És nem túl régi hardveren értem most az Rpi4-et is.

    Persze ettől még a biztonsági szakértők szerint a gyenge entrópia biztonsági kockázat, de ez is csak elméleti okoskodás, meg hype, mert olyat még senki nem tudott mutatni, hogy „gyenge” entrópiával generált hash-t, meg azzal használt titkosítást bárki is meg tudott volna törni gyakorlatilag. De ha tévedek, nyugodtan oktass ki, keress rá forrást, amiben igazolják, hogy ez megtörtént.

    Az a baj, hogy hiába írok, nem olvassátok el, vagy csak az utolsót, és azt is felszínesen.

    #7277 sati: Wofi helyett működik a dmenu is, meg tudsz fzf-fel terminálos megoldás is szögelni helyette. Én is így csinálom, dmenu és $mod + különböző billentyűkre indulnak bedrótozott alkalmazások, úgy értve, hogy $mod + A-Z/a-z/0-9/F1-F12-re vannak alkalmazások és WM funkciók bedrótozva, ritkán kell indítómenüznöm. Dokumentumaimat is fzf-et használó script indítja, ami a dmenu/Wofi-nál fejlettebb részleges egyezési mintákat tudó kereső, 1-2 karakter leütése után szinte bármelyik dokumentumomat megnyitom vim-ben. Illetve Vifm-ben is vannak 'A-z/'a-z-re bookmarkok bedrótozva, így megint 2 billentyű leütésére ott vagyok a legfontosabb mappákban. Sőt, Bash-an csináltam magamnak egy "cf" nevű aliast (change fuzzy directory rövidítése), ami fd (ez Rust-ban is gyorsabb find) és fzf segítségével 1-2 billentyű leütésére átvált közvetlenül akármilyen mappára, még csak Tab-os kiegészítés sem kell.

    Tehát nem úgy van, mint hagyományos WM/DE-kben, hogy indítómenükben kell egérrel turkászni, meg dokkra kattintgatni, és mindenféle fájl menüből meg fájl browserből mappákat, megnyitandó fájlokat keresgetni, és csomót kattintgatni, mindent elérek közvetlenül, mintha nem is lennének szinte mappák, vagy csak 1-2 szint mélység lenne. Nem kell kinyúlnom egérért, és kurzormozgató billentyűkért is nagyon-nagyon ritkán, végig az alfanumerikus részt használom gépírási tartásban.

  • Frawly

    veterán

    válasz szuszinho #7270 üzenetére

    Archnak elvileg működnie kell a több éves Vbox-verziókkal is. Írj részletes hibaüzenetet, hibaleírást, hogy mi nem ment rajta, hol akadt el a telepítés.

    Szerk.: az OpenRC-nél megjegyezném, hogy az /etc/conf.d/consolofont fájlban állításon túl természetesen lefuttattam az rc-update add consolefont boot parancsot is, sőt, próbáltam default run-level-lel is. Már nem tudom a vonatkozó korábbi hozzászólásom szerkeszteni, köszönhetően a PH áltak kínált, nagyvonalú 15 ms-os szerkesztési időnek, amiért évek óta hálás vagyok.

  • Frawly

    veterán

    válasz Archttila #7271 üzenetére

    Ha csak böngészőben kell YouTube alá, akkor arra elég lehet az apulse-t feltenni, vagy egy olyan Firefox buildet, ami Pulseaudio nélkül csak ALSA-val lett fordítva.

    Mert a böngészők hivatalosan már csak Pulseaudio-t támogatnak, de ez csupán az előfordított binárisokra, hivatalos buildekre vonatkozik, az nincs tiltva, hogy valaki forráskódból magának más beállítással, USE flag-gel pörgessen dolgokat. Pont ez a Gentoo lényege is, nem azért pörgeti az ember Gentoo alatt a forráskódokat, hogy a proci utasításkészletekre minél jobban rápotimalizálja, és ezzel nyerjen 1-2% futási sebességnövekedést (bár erre is jó), meg nem azért, mert nolifer és unatkozik, hanem hogy úgy forgassa maga a dolgokat, hogy kihagy belőle egy csomó sallangot, ezzel sok bináris (pl. kernel) fele akkora binárissá fordul, fele annyi memóriát igényel, kétszer olyan gyorsan tölt be, nem lesz sallang a rendszeren, nem lesz olyan, hogy egy dologért hegesszünk fel 100 darab függőséget.

    Ez a lényege a Gentoo-nak meg az Alpine Linuxnak, hogy a forráskódból pörgetés miatt nem csak hogy minimalizmus, hanem egyenesen ultraminimalizmus valósítható meg velük.

    Épp ezért szoktam helyteleníteni, mikor valaki Gnome3, KDE5 és egyéb bloat DE-kkel telepíti a Gentoo-t, persze működik úgy is, de akkor az előnye, lényege veszik oda, és akkor annyi erővel lehetett volna helyette egy full DE-s mainstream disztrót is feltenni, ami fent van 5 perc alatt és nem kell órákon át forráskódokat pörgetni kifelé.

  • Frawly

    veterán

    válasz vargalex #7264 üzenetére

    Igen, ezt pont ezért írtam neki előre, hogy kell az EDITOR="blabla" a visudo parancs elé. Nem véletlenül írok litániákat, igyekszek minden buktatóra és félreértési pontra részletesen kitérni, azokra is, amelyek az emberek 99%-a szerint anélkül is egyértelműek, de én tudom tapasztalatból, hogy abban a fentmaradó 1%-nyi esetben milyen hatalmas szopásokat lehet megelőzni, ha az ember nem tömör balladai homályozik, hanem normálisan és részletesen írja le a dolgokat, úgy, hogy semmi ne maradjon ki, semmiben ne legyen kétség, félreértés.

  • Frawly

    veterán

    válasz vargalex #7261 üzenetére

    Nem értek teljesen egyet. A kernel bootkor állítja be az entrópiát a random seedhez, akkor még desktop gépen is szöveges konzol van csak, se egér, se billentyűzet, se semmi. Nem látom be, hogy ez hogyan más egy headless cucctól.

    Ennél az alacsony entrópiánál is meg kell jegyeznem, hogy ez újabban ilyen paranoia csak, 40+ évig elég volt a „sima”, normál entrópia, most néhány paranoid ultra hardened biztonságmániás, NSA-CIA-ellenes sznob kitalálta, hogy mivel nem tökéletes randomságot ad, ezért elméletileg támadható, és ebben a vonatkozásban is próbálnak túlzásba, végletbe esni. De az van, hogy elméletileg minden lehetséges, de a gyakorlatban a sima entrópiás SSH/AES-hez használt, SHA, RSA hasheket sem tudta még senki feltörni, ha nem volt benne szándékos vagy túl felelőtlen implementációs hiba.

    Mondom, én most nem veled vitatkozok, meg nem próbálom a szakmai hozzáértésed kétségbe vonni, hanem ez a toljuk a magas entrópiát meg legyen deafult a haveged mánia ellen akarok a józanság irányába érvelni.

    #7262 sati: kösz, ezt nem is ismertem. Ki fogom próbálni, mert csak azért X.org-ozok most is, mert a Sway-nek alapból kell a systemd, ami systemd-mentes disztrókon eddig gondot okozott nekem.

    Egyébként azt kell mondjam, hogy objektíve nézve a systemd-nek vannak előnyei:
    1) bootidő egyértelműen a leggyorsabb az összes initrendszer között, mármint rendes menetben, mikor nem vár kilőhetetlen start job is running szutykokra
    2) ha beállítasz egy szolgáltatást, akkor az tuti működik.

    Persze ettől még utálom, és nem kéne mindent kötelezően a systemd-re dependelni. De sajnos most az OpenRC-vel szenvedek megint, hogy hiába állítom be a /etc/conf.d/consolofont fájlban, hogy az általam megadott Terminus2 32pt fontot használja, azt használja is, de csak bootkor és boot után az elsőnek megnyitott (tty1) konzolon. Ahogy átváltok tty2-re már újra bolha VGA BIOS betűk vannak.

    Ezzel szemben systemd-s disztrókon a terminus-font csomag telepítése után megadom az /etc/vconsole.conf fájlban megadom, hogy FONT=term-232n, akkor az működni fog, nem csak boot után, nem csak tty1-en, hanem minden tty-on, éjjel, nappal, fejen állva is.

    Érdekes, Gentoo-n jó volt OpenRC-vel, Void-on jó volt runit inittel, de most Artix-on nem jó OpenRC-vel. Fene se érti ezt, a doksik alapján jó helyen állítom, működik is, de csak félig.

  • Frawly

    veterán

    válasz #63718632 #7259 üzenetére

    A -s kihagyása nem baj, mert elvileg a default az /bin/bash a legtöbb disztrón, a legtöbb leírás csak azért említi, mert biztosra akarnak menni. A csoportok sem olyan tragédia, hogy kimaradtak, mert usermod paranccsal, amit már írtam, pótolható, akármikor később is. Az meg tényleg lehet, hogy a nox üti a utils-t. De még az is lehet, hogy a sima utils-t elég feltenni, mert abban benne vannak az X-es és noX-es (no X.org) hozzávalók.

    Egyébként én tervezem átállni zsh-re. Eddig ellenálltam neki, mert bloatabbnak tartottam, meg ugye mindenhol a Bash a sztenderd, de a zsh annyival többet tud, hogy állva hagyja az egész Bash-t.

    Jó még állítólag a Fish shell is, de az még nagyon kísérleti, meg több sztenderd dolgot sem támogat, pl. !! és !$ rövidítések, és hasonló sztenderd trükkök.

  • Frawly

    veterán

    válasz vargalex #7255 üzenetére

    Na, látod, ezt nem tudtam, hogy SSH-hoz kell haveged. Mikor legutóbb használtam, akkor még nem kellett. Akkor viszont visszavonom, ha tényleg ez a helyzet, hogy kell hozzá, akkor valóban szükséges a haveged, és headless rendszeren nem szabad akkor leszedni.

  • Frawly

    veterán

    válasz #63718632 #7254 üzenetére

    Nem is fontos a usered a wheel csoportba betenni, azt csak azért ajánlják, mert tradicionálisan a wheel csoport tagjai adminisztrálták a gépet a root-on kívül, így pár alkalmazás erre számít, hogy felhasználód benne lesz wheel felhasználói csoportban. De ha nagyon szigorúan nézzük, ez nem kötelező, simán lehet, hogy a sudoers fájlba az ALL-os sornál nem wheel-t adsz meg, hanem felhasználónevet, vagy azt a csoportnevet, amiben a felhasználód van.

    Én pont ezért ezzel kezdem a telepítést, eleve már a korlátozott felhasználóm így hozom létre, hogy benne van egy csomó csoportban:
    useradd -G wheel, video, audio, stb -s /bin/bash felhasználóinév
    passwd felhasználóinév
    visudo

    Ezekre nem csak Arch alatt van szükség, hanem Artix alatt, Void, Gentoo, stb.. De disztróként, és speciális alkalmazásonként változhat, hogy milyen felhasználói csoportok vannak meg kellenek, amibe a felhasználót hozzá kell adni. Elvileg van a felhasználókezelésnek egy új módja, systemd-homed, de ezt értelmes ember igyekszik elkerülni.

    Ha a virtuális gépben linuxok fognak, akkor azokban kéne működnie a virtualbox-tools-nak, illetve sok modern disztró már a live lemezképbe integrálja az elterjedtebb virtualizációs drivereket, QEMU, Virtualbox, VMware, stb., hogy ez is alapból menjen. Így az xrandr-nak kéne mennie, kivéve waylandes felületeken, mert ott a waylandes kompozitornak kell állítani, hogy milyen felbontást használjon.

    vbox-utils-guest-nox csomagot nem ismerem, feltehet azt is. Disztrófüggő mondom, hogy milyen OS, milyen disztró fut virtuális gépben, az támogatja-e.

  • Frawly

    veterán

    válasz vargalex #7250 üzenetére

    Elbeszélünk egymás mellett: én nem azt mondom, hogy valamihez nem jön jól a haveged, mert néha tényleg előnyös vagy indokolt lehet a használata. Ezt sose vitattam. De nem annyira alap dolog, hogy egy alaptelepítésbe beleerőltessék per default. Példának itt van ez a most szóba hozott sudo, sok usernek az alapabb dolog lenne, mert már reflexszerű toolként használják, és a legtöbb haladó disztrón külön kézzel kell feltenni, beállítani, hogy működjön. Na, így kéne ennek lennie a haveged-del is.

  • Frawly

    veterán

    válasz BoB #7249 üzenetére

    Én a kezdő Arch user szemszögéből írtam, aki felteszi első alkalommal az Archot, és hirtelen arcra esik, hogy alapból nem tud sudo-zni, mikor meg Ubuntu, Mint, Debian, Fedora, stb. rendszereken meg install után alapból megy.

    Pont azért írom, hogy alapból sehol nem lenne ez engedélyezve, bekapcsolva, csak a felhasználóbarát disztrókon a disztrókészítők alapból engedélyezik, csak ezt a laikus user nem látja, mert az automata installer végzi el ezt a lépést is, így a felhasználónak az jöhet le, hogy ez a sudo egy alap dolog Linuxon, ami minden disztrón működik. Hát nem.

    A nincs engedélyezve kifejezést meg nem úgy kell érteni, hogy tiltva van, hanem alapból csak nincs bekapcsolva. Még a sudo csomag sincs fent alapból, ha jól emlékszem, még azt is fel kell hozzá tenni, usercsoportot, /etc/sudoers-t állítani. És ez nem véletlen, mert biztonsági szakmai szemmel a sudo-t biztonsági kockázatnak tartják, és helyette vagy az su-t, vagy a root konzolt ajánlják, vagy grafikus felületen a pkexec meg admin:// módszerrel kell kiváltani. Ennek ellenére sokan mai napig ragaszkodnak hozzá, pl. én is, lehet rosszul teszem, pusztán megszokásból, az első, hogy minden Arch, Artix, Void, Gentoo, stb. installkor kézzel engedélyezem, mert már csukott szemmel tudom, hogy magától nem fog menni.

  • Frawly

    veterán

    válasz #63718632 #7241 üzenetére

    Nem baj, az első Arch installja mindenkinek ilyen kaotikus gányolás, bele fogsz jönni.

    Szép sorban: billkiosztást be tudod álltani Xfce-nek valami beállítópaneljében. Ennek hiányában jó az, amit a kolléga írt, a X.org-os megoldás. Én azt szoktam, hogy automatikus indulásba beteszem a setxkbmap -option grp_led:caps,grp:alt_space_toggle,caps:escape hu,us & sort, igaz nálad ezek az opciók nem biztosan kellenek, csak egyszerűen setxkbmap hu & ahogy olvasom, ezt már meg is tetted. Nálam van egy csomó plusz opció, hogy Alt+Space-re váltson alap magyar és alap amerikai kiosztás között, amerikai kiosztáson égjen a Caps Lock ledje, hogy jelezze ezt a tényt (hogy nem magyar kiosztás van érvényben), amúgy meg a Caps Lock billentyű szűnjön meg nagybetűsíteni, helyette Esc-ként viselkedjen, ami vim és vi/vim-billentyűket használó progiknál, böngészőkiegészítőknél fontos annak, aki ilyet használ.

    Az usered a sudo usermod -G wheel felhasználónév paranccsal tedd be a „wheel” csoportba, és a /etc/sudoers fájlt, de nem közvetlenül, hanem az EDITOR="szövegszerkesztőd" visudo paranccsal rendszergazdai módban szerkeszted, és a fájl vége felé a #%wheel ALL=(ALL) ALL sorból kiveszed a kettőskeresztes kommentjelent, majd elmented. Figyelem: NEHOGY elgépeld, kétszer is nézd meg, hogy a sudoers fájlt jól szerkesztetted-e meg, nem írtál-e félre valamit, nincs-e valahol felesleges szóköz, mert ha elrontod, akkor működésképtelen lesz a rendszer, és nem hogy senkinek nem lesz sudo joga, de még a root user jogosultsága is elkezdhet nem működni, hazavágod vele a teljes telepítést !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Ezért is csak visudo paranccsal lehet szerkeszteni ezt a fájlt, közvetlenül nem, a visudo egy script, ami ellenőrzi mit szerkesztettél bele, néhány hülyeséget ki tud szűrni, de nem minden user errort. Persze, ha tönkretennéd a sudoers fájlt, végül is Arch telepítőt bebootolva, partíciókat felcsatolva meg tudod javítani a fájl kicserélésével, de szopás, ha meg kell ilyet ejteni.

    Archon alaptelepítésben biztonsági okból nincs engedélyezve a sudo. Igazából egyik disztrón se, csak a felhasználóbarát disztrókon a fejlesztők átállítják install során, hogy ne a usernek kelljen ezzel szenvedni, és telepítés után mindjárt legyen sudo joga.

    Virtualboxnál azt kell feltenni, mit írtál, virtualbox-guest-utils csomag, és ez is csak akkor működik, ha a virtuális gépben futó OS épp támogatja ezt a funkciót, a legtöbb modern rendszer támogatja, a régi retró OS-ek közül nem mind.

  • Frawly

    veterán

    válasz Archttila #7239 üzenetére

    Akkor meg aztán végképp szedd le. Én, mikor használtam havegedet Archon, akkor kézzel tettem fel egy ubuntus cikk alapján, mert akkoriban több disztrón is gond volt, hogy a kernel várt alacsony random seed entrópiára, és ez megnyújtotta a bootolást másodpercekkel, néhány gépen percekkel. De ez csak néhány hétig kellett (és nálam kilépett, mikor végzett), utána elhárították ezt a problémát. Nyugodtan szedd le az RPi-ról, ha mégis lassú lenne a boot, várna valamire, akkor visszateszed.

  • Frawly

    veterán

    válasz vargalex #7225 üzenetére

    Igen, alacsony az entrópia, de működik haveged nélkül. Azt se felejtsük, hogy attól még, hogy valami szerver headless, az nem azt jelenti, hogy:
    1) NSA és CIA elleni is titkosítva kell legyen
    2) annyira magas entrópia kell a random seednek, hogy erős legyen a generált hash és titkosítási kulcs

    Egy házi projektben bőven elvan a szerver alacsony entrópiával is, pl. házi NAS, egyéb házi megoldás. Egy céges, mission critical szerver az más, ami meg van nyitva a publikumnak, és kívülről a netről törhetik, és komolyabb támadásnak van kitéve, mert mondjuk egy ismert szervezet oldala, vagy más szervere (ftp, egyéb).

    Igazából ezt, hogy headless, még annyiból sem értem, hogy egy szervernél holt mindegy, hogy van-e rá mondjuk egy monitor, billentyűzet kötve vagy headless. Attól, hogy valami headless, még nem igényli jobban a magasabb entrópiát.

    Persze, nem veletek vitatkozok, mert egyes esetekben valóban hasznos lehet a haveged, ezt nem vitatom, de hogy mindjárt default installba kötelezően a userre rátukmálni, az szerintem egy kicsit túlzás. Főleg ARM platformon, ahol az erőforrások amúgy is korlátosak általában. Egy desktop gépnél, egy mainstream full bloat DE-s disztrónál azt mondom, hogy ott beleerőltetik, mert már úgyis olyan hardverigénye van, hogy nem oszt, nem szoroz. De itt RPi-ról beszélünk.

    Persze az is igaz, hogy a haveged csak addig fogyaszt erőforrást, amíg lefut, utána elvileg kilép, nem fut tartósan, de pl. a telepített csomagja foglalja a plusz helyet. Sokkal bölcsebb lenne, ha az Arch ARM Wiki inkább csak ajánlaná a havegedet, de opcionálisan. Úgy aki paranoid a biztonság terén, az feltenné, aki meg nem, arra meg nem lenne +1 sallang rátolva.

  • Frawly

    veterán

    válasz vargalex #7223 üzenetére

    Kösz az infót, érdekes, ezt nem tudtam. Egyébként meg továbbra sem indokolt a haveged, SSH-hoz sem kötelező, a kernel anélkül is generál random seed-et. Az is igaz, hogy nem olyan nagy tragédia, ha fent van, de azért egy RPi-on elég korlátozottak az erőforrások, én emiatt leszedném mindenképp a havegedet.

    Arch ARM-et sem használtam még, nem tudtam, hogy ott tényleg van egy alaprendszer.

  • Frawly

    veterán

    válasz Archttila #7220 üzenetére

    Ez érdekes, hogy az archarm alaptelepítésben felteszi a haveged-et, mikor meg a mainline Arch meg arra törekszik, hogy a default minimáltelepítés egyre kisebb legyen, jól megritkították a base csomagcsoportot is emiatt, se kernel, se hdcpcd, se text editor, se semmi nem települ alapból. Természetesen mainline Archon haveged sem képezi részét az alaptelepítésnek, hiszen nem szükséges a rendszer működéséhez.

    Bár ezzel az alaptelepítéssel is lehet vitatkozni, mert Arch-nál nincs alaptelepítés. Az egy dolog, hogy az emberek 99%-a az installation guide alapján azzal kezdi, hogy felnyomatja a base csomagot, de ez nem kötelező, ki lehet hagyni, lehet helyette csak saját kútfőből csomagokat feltenni. A base csomagcsoport csak kényelmi funkció, hogy ha valaki nem tudja mi kell a rendszer alapműködéséhez, az se hagyjon ki semmit. Bár már ez sem mondható el róla, mióta kiszedtek belőle mindent.

    A qutebrowsert tesztelem pár hete, igaz nem intenzíven, de másodböngészőnek próbálgatom itt-ott. Eddig vegyesek vele a tapasztalatok, de még nem tudtam eldönteni, hogy mi lesz vele, adoptálom fő böngészőnek vagy dobom.

    Brave-et semmiképp nem akarok használni, nem szeretem a Chrome-alapú böngészőket, de ha használhatóak is lennének, akkor sem akarom azt a tábort erősíteni, hogy mindent bekebelezhessen a Google, már így is túl nagy hatalmuk van a böngészők piacán, weben, stb..

  • Frawly

    veterán

    válasz Archttila #7217 üzenetére

    Látod, az simán lehetséges, hogy yay-jal telepítetted, vagy valami yay-os alkalmazás húzta be függőségnek.

    Azt nem értem, hogy ezzel az mc-s hasonlattal mit akarsz, fogalmazd át. Sway és i3wm alatt alapból nem kéne dekorációnak lennie az ablakokon. Csak keretnek meg címsornak, de ezek is letilthatók. Sőt, a keret meg a címsor együtt jár, ha a keretet 0 pixelesre veszed, az letiltja egyben a címsort is, kivéve tabbed módban (maximalizált méretben fut az összes alkalmazás), de még ilyenkor is letiltható, ha a title bar fontot és padding-ot 0-ra veszed:

    default_border none (vagy 0)
    font pango:monospace 0 (erre nekem nem volt szükségem)
    titlebar_border_thickness 0
    titlebar_padding 0

    A neten azt írják, hogy egyes Gtk3 alkalmazások kliens oldalról erőltetik az ablakcímsort, nálam ez nem fordult elő, de ha nálad ez gondot okozna, akkor úgy tiltható, hogy a ~/.config/gtk-3.0/gtk.css fájlba beteszed ezt:

    .titlebar.default-decoration {
    margin: -200px;
    opacity: 0;
    }

  • Frawly

    veterán

    válasz Archttila #7212 üzenetére

    Ez egy crypto modul, amit a kernel bootkor random seedelésre használ. A kimenet szerint te tetted fel kézzel. Ha akarod leszedheted, nem kell fent lennie, bár nélküle előfordulhat, hogy bootoláskor a kernel kicsit több időt fog elszüttyögni random seed generálással, a haveged ezt van hivatva felgyorsítani. Nyugodtan távolítsd el így első körben.

  • Frawly

    veterán

    válasz Archttila #7206 üzenetére

    Örülök, hogy végre sikerülnek a dolgok. ARM-re igazából mindent le tudsz fordítani, csak az a kivétel, amelyik kódban x86(_64) ASM részletek vannak, vagy x86(_64) gépi kódú blob kell hozzá, vagy ha egy függőségében ilyen kód van. De a legtöbb csomagkezelő, átlag progi, terminálos megoldás, CLI program, server daemon, stb. nem ilyen.

    Egyébként meg ez a Linux valódi ereje, nem az, hogy ingyenes, hanem 15-20 éves gépre, gyufásdobozra, és szervereken át a szuperszámítógépekre mindenre ráskálázódik. Ez az, ami a Windowsnak meg a MacOS-nek sose fog menni, azok megmaradnak desktop only OS-nek aktuális x86-os gépekre.

    Na meg a szabadság, hogy a rendszer minden elemét te szabod meg, és konfigurálod, nem vagy kötve egyféle multi egyenmegoldásához, és nem vagy nekik kiszolgáltatva, hogy mit meddig szíveskednek támogatni.

  • Frawly

    veterán

    válasz Archttila #7203 üzenetére

    Ja, akkor jó. Amúgy a modern progiknak nem kell az fc-cache, anélkül is le kéne kövessék a fontváltozásokat, az fc-cache inkább legacy X-es alkalmazásoknak kell. Fura, hogy a Termite-nak szüksége volt rá. De nem baj, mert legalább akkor már ezt is kitapasztaltad. Ha már mindenre így rájöttél, akkor nagyon kézre fog állni a Wayland és a Sway is. Én most kísérletképpen az új gépre Artix-ot tettem X.org + Openboxszal, az Arch + Wayland + Sway helyett, de már hiányzik az Arch és a Sway is.Ja, akkor jó. Amúgy a modern progiknak nem kell az fc-cache, anélkül is le kéne kövessék a fontváltozásokat, az fc-cache inkább legacy X-es alkalmazásoknak kell. Fura, hogy a Termite-nak szüksége volt rá. De nem baj, mert legalább akkor már ezt is kitapasztaltad. Ha már mindenre így rájöttél, akkor nagyon kézre fog állni a Wayland és a Sway is. Én most kísérletképpen az új gépre Artix-ot tettem X.org + Openboxszal, az Arch + Wayland + Sway helyett, de már hiányzik az Arch és a Sway is.

  • Frawly

    veterán

    válasz Archttila #7200 üzenetére

    A screenshotodon jól van beállítva, a linkeden nem, ott feleslegesen van mögötte az a fontawesome valami. Nem árt egy fc-cache parancs sem. A Fantasque Sans Mono-t még bemásolgatni sem kell sehová, a pacman -S ttf-fantasque-sans-mono kiadásával telepíted, az rendszerszinten telepíti az összes felhasználónak, beregisztrálja, beteszi a megfelelő helyekre.

    A te screenshotodon látszik, hogy nem jelenik meg maga a font. A Fantasque Sans Mono kicsit a Comic Sans-ra hasonlít, ilyen vidám, ultramodern, kézírásos jellege van. Nálad meg valami szögletes fallback font jelenik meg.

    Próbáld meg újraindítani a rendszert fonttelepítés után, hátha segít. Esetleg terminálban nagyíts be a betűtípusnak, hogy akkor jól jelenik-e meg.

    Ha így sem megy, akkor valamelyik csomagod úgy lett fordítva, hogy nem kezeli normálisan a fontokat. Vagy a fontconfig mappában van elszúrva valami .conf fájl.

  • Frawly

    veterán

    válasz Archttila #7197 üzenetére

    Én is Termite-ot használok és nálam minden betűtípust elfogad. Ellenőrizd az Arch Wiki alapján, hogy a fontjaidat jó mappába tetted-e, és fc-list paranccsal néz meg, hogy mi a PONTOS neve az illető font-nak, néha trükkös, mert hol egybe van írva, hol külön, kis-nagybetű is számít, és nem mindig esik egybe a font fájlnevével sem. Én Fantasque Sans Mono-val használok, de használok mellette Dejavu Sans Mono-t, MS Cascadia, Adobe Source Code Pro, Ubuntu Mono fontokat is, külön termite-os conf-fal vagy grafikus progikban.

    Notification-t te is tudsz írni magadnak, csinálsz egy scriptet, ami megnyit egy terminált, abba elindít egy másik scriptet, ami az üzenetet kiírja, és x másodperc után bezárja magát. Igaz így nyomtalanul eltűnik, de ezt valami logolási módszerrel ki lehet egészíteni. Igazából még a Dunst-ot is kipróbálhatod, mert az a legjobb notification deamon, és igaz, hogy X.org-os, de mennie kell Wayland alatt is, XWaylandet használva.

  • Frawly

    veterán

    válasz Archttila #7195 üzenetére

    Nem használok notificiaton progit. Próbáld terminálból indítani, és egy másik terminálból küldj át rá értesítéseket, nézd meg mit ír ki futás közben, megkapja-e ezeket, ír-e hibát.

    Azt nem is tudtam, hogy a waybar már default konfigban ilyen csilivili. Git-es tárolóm még nincs, de tervezek egyet regisztrálni, mert még sose használtam sajátot, pedig hasznos.

  • Frawly

    veterán

    válasz Archttila #7191 üzenetére

    Ezt a waybar konfigot feltölthetnéd valahová, pastebin, vagy git vagy hasonló, elég jól néz ki. Az ARM-es Firefox szerintem lefordítható waylandes támogatással, én nem tudok olyan korlátról, hogy csak x86 és x86_64 alatt lehetne ezt beleforgatni. Azt meg ne kérdezd, hogy hol és milyen flag-et kell hozzáadni, utoljára Gentoo-n csináltam ilyet, és ott sem forgattam Firefoxot.

  • Frawly

    veterán

    válasz Xenophobermn #7186 üzenetére

    Valóban, ha PHP fájlban próbálom, nálam sem működik. De még egy olyan csavar is van benne, ha nem PHP fájlt szerkesztve beállítom neki a PHP-s kódszínezést, még úgy is működik, de ahogy elkezdem a fájlt PHP-s címkék közé tenni, úgy már átszínezi a változóneveket és többé nem megy ez a kettő kattintásos csoportos kiemelés. Szóval mindenképp a PHP-s kódértelmezőben van a hiba.

  • Frawly

    veterán

    válasz Xenophobermn #7184 üzenetére

    Nálam alapból ilyen mindkettő, nem kellett aktiválni külön. Próbáld meg a notepadqq konfigurációs fájlját törölni (vagy csak átnevezni), úgy visszaállnak az alapértelmezett beállítások. Ennek a fájlnak az elérési útja: ~/.config/Notepadqq/Notepadqq.ini

    Próbáld meg úgy is, hogy $változó nevet sima .txt szövegfájlba írod és úgy jelölöd ki duplakattintással, ha úgy megy, akkor a PHP kódfeldolgozóban van a hiba, nem magában a progiban.

  • Frawly

    veterán

    válasz Archttila #7180 üzenetére

    A FF-ot futtasd a MOZ_ENABLE_WAYLAND=1 környezeti változóval, pl. MOZ_ENABLE_WAYLAND=1 firefox, vagy scriptbe teszed bele, hogy a firefox indítása előtt: export MOZ_ENABLE_WAYLAND=1. Ezt a környezeti változót a /etc/environment fájlba, vagy export MOZ_ENABLE_WAYLAND=1 formában a /etc/profiles fájlba is beleteheted, akkor nem kell kiadni minden egyes indulás előtt.

    De még az is lehet, hogy az ARM-es Firefox build nem tartalmazza a Wayland-támogatást, ez egy olyan feature, amit fordításkor bele kell fordítani.

  • Frawly

    veterán

    válasz Xenophobermn #7177 üzenetére

    Nálam működik, notepadqq-ban is, és vim-ben is. Az elsőben dupla kattintás, és kijelöli a változónevet úgy, hogy a dollárjelet nem jelöli bele, és jelöli vele az összes előfordulást. Ugyanez vim-ben, normál módban a csillag billentyű, az is épp így dollárjel nélkül jelöli ki, de ott is működik.

  • Frawly

    veterán

    válasz Frawly #7170 üzenetére

    Most néztem, kimaradt a „se”. Úgy akartam, hogy a „JOE se rossz”, magyarán az is jó, csak nem népszerű, nem vonz sok embert, mert eleve WordStar-t kevesen használtak. Fáradtan nem kéne fórumozni.

    (#7171) sati: az a kiindulóprobléma a vágólappal, hogy az X-es alkalmazások látják egymás vágólapját, de a waylandes alkalmazásokét nem látják. És fordítva is igaz. Ha a FF-ot átkapcsolod Wayland-módba, akkor ugyan látni fogja a waylandes alkalmazások vágólapját, de cserébe akkor az X-esekét nem látja.

    A Wofi-ról hallottam, de még nem próbáltam. De ez a bemenu teljesen új, arról még nem is hallottam, hétvégén kipróbálom. Nálam jól megy a dmenu, még sose fagyott. Olyan viszont előfordult régebben, akkor is nagy ritkán, amikor néha úgy marad a képernyőn, és akkor nem lehet eltüntetni. Mostanában nem futottam bele.

  • Frawly

    veterán

    válasz bhonti #7168 üzenetére

    A JOE rossz, azt olyanoknak szokták ajánlani, akik régen WordStar editort használták DOS alatt, és nagyon be vannak idegződve az ujjaikba a WordStar-billkombók. De valamennyire hasonlít a nano-ra, pico-ra is.

    (#7169) sati: ezt nem tudtam, sajnálattal olvasom. Továbbra sem lehetetlen lefordítani szerintem, csak akkor mindkét progiknak fel kell keressed a git repóját, azt leklónozod git clone cím kiadásával, és kézzel forgatod le. Nehezebb, de abszolválható, mivel egyik progi sem olyan rettenet nagy.

  • Frawly

    veterán

    válasz Archttila #7164 üzenetére

    Ne add fel ilyen könnyen, ezért van AUR. Annál forráskódból pörgeti ki a makepgk script a dolgokat, így ARM-re fordítódik. Az AUR-ban a micro és clipman csomagokat telepítsd, szó szerint ez a nevük.

  • Frawly

    veterán

    válasz Shyciii #7162 üzenetére

    Ja, a micro jó. Olyan, mint a nano meg a pico, csak sokkal többet tud, hagyományos, sztenderd billentyűkombókat ismer, Ctrl+C/V, Ctrl/Shift-Ins, Ctrl+X, Ctrl+Q, Ctrl+S, stb., tehát sztenderd elvekre épülő, nem modalitással bonyolított, nem kell a használatát tanulni, mint a vimnél vagy Emacs-nél. Aki használt már nano-t vagy pico-t, vagy mceditet, Notepad/Notepad++ klónt, az a micro-val is könnyen boldogul, nem sokat kell tanulni rajta, de mégis terminálos, konzolos, text user interface-es, minimalista, csomó plugin és beállítási lehetőség, kódszínezés, scriptelhetőség, szóval komoly cucc, ötvözi a vim komolyságát, minimalizmusát a hagyományos szerkesztők egyszerű kezelhetőségével, az a fajta komplex editor, amiből komplett IDE is építhető, és lehetőségeiben felér a vim, Emacs, Kakoune, Visual Code, Atom, Sublime, Notepad++, stb. tudásához, komplexitásához.

    A Vifm-ben sem kötelező vi-os billentyűket használni, át lehet teljesen konfigolni (gyári billkombók kinullázása unbind-del, nyíl billentyűkre mozgás, F1-F10-es gyorsbillentyűk, mint nc/mc-ben, stb.), de akkor szerintem az értelme veszik oda.

    A vim-et meg azért nehéz tanulni, mert
    1) ahhoz, hogy profitálj belőle, szerintem tudni kell gépírni
    2) át kell álljon rá az agyad, mivel nem text editor igazából, hanem text processor, jobban hasonlít egy interaktív sed-re, mint egy text editorra. Ezért sok szerkesztési műveletet át kell fogalmazni, máshogy kell alatta megközelíteni, végezni, eltérő logikával. Ezt pedig nehéz szokni.

  • Frawly

    veterán

    válasz Archttila #7157 üzenetére

    Azt meg a gfx.webrender.all opció engedélyezésével lehet bekapcsolni, szintén az about:config oldalon. Ez bekapcsolja úgy a Webrender-t, hogy mindent azzal gyorsít.

    Sőt, Wayland alapokon ment egy ideig a VAAPI-alapú hardveres médiadekódolás is, de eltört.

    Editorból az mcedit helyett inkább a micro-t ajánlom (már ha a vim és Emacs nem jön be). Sokkal jobb editor, többet tud, könnyebb benne a kódszínezést is konfigolni. A nano-ra hasonlít, de annál jóval többet tud, nem csak az mcedit-nél.

    A betűtípusaid is kicsit furcsák, túl vékony betűtípus, és mintha pixeles lenne. Szemkímélőbb egy rendes OpenType vagy FreeType fontot használni betűsimítással, utóbbinak alapból be kéne lennie kapcsolva, ha nem lenne nálad, akkor a Sway konfigjában az output parancs mögé felveszed a subpixel paramétert, aminek az értéke lehet: rgb|bgr|vrgb|vbgr|none. Elvileg az rgb a legtöbb kijelzőn jól mutat, de lehet vele kísérletezni. Ha ez sem segítene, akkor a ~/.config/fontconfig/fonts.conf fájlban lehet a hinting-et beállítani, az egy kicsit megvastagítja a betűkirajzolást, vannak benne fokozatok, slight, medium, full.

    Ez egyébként ilyen műfaj, ezzel a konfigolással egy életre el lehet lenni. De a nagyjához elég pár hét, hogy kitapasztald az alapokat. De megéri, mert utána nem leszel semmilyen nagy cégnek a dizájndisztrójára rákényszerülve, mert a saját testreszabott disztród használod, saját magadnak támogatod, kitapasztalod mihez milyen hardveredhez driver, milyen csomag, milyen beállítás kell, onnantól megoldod magadnak. Nem kell olyanokon fetrengeni, hogy Mint alatt megváltozott a Cinmanó, meg a legújabb Ubuntun kivettek valami funkciót a Gnome-ból, meg a Snap van az ember arcába tolva, és azt kell elviselje, meg a legújabb Xubuntun az Xfce alatt bugzik a gyári kompozitor, tearing van, stb..

    Gentoo ehhez képest még időrablóbb, mikor dupla függőségei fával (csomagfüggőség mellett USE flag függőség) szenvedve kell mindent ötször forráskódból kipörgetni, mire jó lesz, rájön az ember mit hogyan érdemes. És akkor nem értik a linuxos OFF topikban, hogy miért nem álltam át Gentoo-ra, meg mi az, hogy nincs rá időm, mikor nem nehéz az. Ja, elméletben nem, csak mikor a gyakorlatban csinálja az ember, mindent kitapasztalni. Ráadásul a sok idő egyben kell neki, mert nem úgy van, hogy van 5 percem, kicsit reszelek a rendszeren, ha belelendül az ember a fordítgatásba, akár órákig pörögnek a kódok, nem lehet csak úgy kilépni.

    Anno az Arch-csal is megszenvedtem, de nem a disztróval, hanem a minimalista WM-ekkel, mikor DE-k használatáról tértem át, eleinte szokatlan volt, hogy ennyi mindent kézzel feltenni, konfigolni, panelt, menüt, kompozitort, mindenre a felhasználónak kell gondolni, minden apróságra, pedig előtte azt szokta meg, hogy DE-k alatt minden megy out of the box. De aztán meg lehet szokni, bele lehet jönni, mindig lehet vele tovább fejlődni. Épp ezért nem szoktam elmenteni a rendszertelepítést sem, mert mindig változik, konfigok is, mindig alakítok valamit, bevezetek valami újítást, és kb. fél évente úgy megváltozik a rendszer, hogy egy régi mentés visszahúzásával úgyse mennék semmire.

  • Frawly

    veterán

    válasz Archttila #7155 üzenetére

    Az about:config oldalon a layers.acceleration.force-enabled opciót engedélyezd, azaz állítsd true-ra. Utána újraindítva a FF-ot, az about:support oldalon az OpenGL Compositing-nál Basic-et kéne minimum írnia.

  • Frawly

    veterán

    válasz Archttila #7152 üzenetére

    Akkor próbáld meg a Mozilla oldaláról töltött tar.gz-s Firefoxot, abból is lehetőleg a Developer Editiont (béta), én is azt használom. Pedig én szoktam mondani, hogy Linuxon nem töltünk le weboldalról szutykokat, de ez az FF kivétel, 5+ éve használom, menet közben frissíti magát, nem hagyott még cserben, 2-3 naponta frissül. Igaz Wayland-es beállításokat rákényszerítve bármelyik FF bugozásba kezdhet, függetlenül attól, hogy melyik ág, milyen build, hányas verzió.

  • Frawly

    veterán

    válasz Archttila #7150 üzenetére

    Ez a hivatalos tárolóban lévő FF? Próbáld meg a Help menüből a Restart with Addons disabled opcióval? Esetleg ha konfiguráltad, hogy Wayland felett fusson, akkor állítsd vissza a gyári beállításokat az about:support oldalon a jobb felső sarokban lévő Refresh opcióval.

  • Frawly

    veterán

    válasz Archttila #7148 üzenetére

    Akkor jó. Már akartam írni, hogy a man sway-output oldalát olvasva lehet hozzájutni ehhez az infóhoz.

    Egyébként ez a Sway elég badass, sokat fejlődött az utóbbi időben, adaptive sync, fractional scaling, meg egy csomó mindent tud. Igaz a fractional scalingnél (HiDPI) azt írja, hogy X-es alkalmazások felé az XWayland nem támogatja. Vagyis át lesz méretezve az X-es alkalmazás is, de nem tört szorzóval, hanem egésszel.

  • Frawly

    veterán

    válasz Archttila #7141 üzenetére

    XWayland mindenképp kell, nem úszod meg, telepítsed a csomagját. A dmenu is X alapú alkalmazás, meg a Termite is, hiába állítják utóbbinál hogy natív waylandes, ettől még nem rossz terminál, én is ezt használom.

    Ha jól emlékszem, Firefox alatt sem elég csak egy környezeti változót módosítani, valamit kell hozzá mókolni az about:config oldalon is, hogy tényleg Wayland-módban menjen, és még utána is lehet egyes Firefox-verzióknál instabilitással számolni, mert csak kísérleti szinten támogatott feature. A Firefox meg a böngészők is alapból X-et használnak, én is így használom.

    A Waylandnek ez a baja, hogy kevés alkalmazás van rá natívan, vannak, de nem mindenre, de ez nem baj, mert az X-es alkalmazások felé az XWayland tökéletesen működik, egyedül a vágólapkezelés problémás, amire múltkor írtam megoldást. Nem kell tőle tartani, mert nem dobja meg túlságosan az erőforrásigényt.

    Félre ne értsd nem bugos, amik vannak Waylandre alkalmazások és WM-ek, DE-ek, azok jól működnek, de még mindig nem túl sok minden támogatja natívan. Valahogy a fejlesztők lusták és konzervatívak, hogy jó volt eddig 30+ évig az X, akkor nem holnaptól fogják dobni, jó lesz az továbbra is alapon. Pedig már rég használható állapotban van a Wayland is, én már majd 2 éve használom, fél évig Gnome-mal, és másfél éve SwayWM-mel, de tettem kitérőt Westonra is.

  • Frawly

    veterán

    válasz vargalex #7142 üzenetére

    Szerintem ez végig hardverhiba volt, azért jó a legújabb alaplappal minden kernel. Lehet az egyel régebbi alaplap már megbízhatatlanul működött, ami LTS kernelnél nem jött ki, mert az mondjuk nem rakott rá olyan terhelést, nem tartalmazott valami olyan optimalizációt, ütemezőt érintő módosítást, ami kiütköztette volna a hibát.

    Ilyen Windows esetében is láttam, hogy halódó hardveren még jól ment az XP (vagy talán még a Win7 is), de mondjuk az újabb windowsok nem, mert azok jobban meghajtják, és kiütközik a hiba. Sőt, ugyanez tuningnál is előfordul, hogy mikor már olyan magasra vannak húzva az órajelek, akkor félstabil állapotba kerül, és régebbi Windows verziók alatt, vagy 32 bit alatt stabilnak látszik, újabb 64 bites verziókkal újraindulgat, kékhalálozik. Ugyanez teszteknél, pl. Cinebench még lefut, de pl. a Prime95 már behasal rajta, de még GPU-nál is láttunk ilyet, hogy 3D Mariska, meg Unigine teszt rendben lement rajta, meg néhány játék, míg a FurMark teszt, meg néhány még újabb játék meg már hibát produkált vele. Ez ilyen műfaj, hardverek tudnak ilyen borderline hibát produkálni, miközben halódnak szép fokozatosan megfelé.

  • Frawly

    veterán

    válasz Archttila #7136 üzenetére

    Próbálj mindenképp vagy UUID-t, vagy PARTUUID-t használni. Pont nem az elegancia miatt van kitalálva, hanem azon esetek elkerülésére, ami most nálad is előfordul, hogy rádugsz egy SSD-t, és eltolódnak a /dev/sda eszköznevek.

    A különbözőféle UUID-ket a blkid paranccsal tudod megnézni.

  • Frawly

    veterán

    válasz Archttila #7134 üzenetére

    Ja, ha RPi-on használod, akkor neked kell a vc4 ahhoz, hogy legyen hardveres gyorsítás. Egyébként a Wayland jó dolog, a legtöbb esetben még gyorsabb, pattogósabb is, mint a X.org, mivel egy sokkal egyszerűbb protokoll, nem akar hálózaton transzparens lenni (emiatt nem apró objektumrajzoló utasításokból építi fel a grafikus képet, hanem egészében kezeli az egészet, pixelalapon), meg nem kell visszafelé kompatibilisnak lennie sok évtizedes ősi megoldásokkal (X1-X10). Eleve úgy van megtervezve, hogy minimalista legyen, a legtöbb grafikus dolgot a futó programokra bízza, hogy azok rajzolják a saját ablakukat.

    Plusz azt vettem észre, hogy mivel egyszerűbb a Wayland, ezért kevésbé is törik el, sok olyan gépen, ahol a X.org meg a X.org driver, vagy kompozitor szórakozik, bugzik a mesa-val, a Wayland hiba nélkül megy. Ami hátránya van még, hogy egyelőre kevés a választék wayland-es WM-ekből (csak a Sway és a Weston kiforrott) és DE-kből (lényegében csak KDE5, Gnome3), meg egyelőre kevés az olyan szoftver, ami natívan is tudja használni a Waylandet, és nem támaszkodik XWayland X.org emulációra. Wayland alatt tovább alapból nincs tearing, jobban kezeli a v-syncet (ami X.org alatt utángondolás, és a kompozitorok nehezen birkóznak meg vele), nincs az, hogy egy teljes képernyő játékba bekeverne a kompozitálás, rontaná a futási teljesítményét, lagoltatná, illetve Sway alatt már a FreeSync is támogatott.

    Egy dologgal még számolni kell, hogy mikor X.org-ot használó alkalmazásból valamit vágólapra teszel, azt nem lehet beilleszteni waylandes alkalmazásban és fordítva. De szokott lenni rá megoldás, hogy terminálban, meg a vonatkozó progiknál átállítani a vágólap nevét. Állítólag van rá kész megoldás, clipman-nak hívják, még nem próbáltam.

  • Frawly

    veterán

    Előbb nem írtam, de ahogy i3wm alá is, Sway alá is kell egy indítómenü, ez lehet a dmenu, rofi, fzf, akármi. Illetve az alkalmazásváltás problémáját, ami engem és téged is zavar, meg lehet úgy kerülni, hogy ha előre tudod, hogy egy alkalmazás vagy floating vagy full screen módban fog menni, azt külön munkaasztalra nyitod, így el lehet róla váltani, át másik alkalmazásra. De mint írtam, ez utóbbi nem i3wm vagy Sway-pecifikus korlát, hanem a tiling WM-ek közül egyik se tudja.

  • Frawly

    veterán

    válasz Archttila #7131 üzenetére

    Magának a Swaynek nem kell a xwayland, mármint ahhoz, hogy önmagában fusson, azért nem húzza be függőségnek. De neked, mint X.org-os programokat is futtatni akaró felhasználónak kell, mert anélkül nem fognak menni.

    Azt se felejtsd el, hogy a Sway-jel egyidőben fel kell rakni a swaybg, swayidle, swaylock csomagokat és az AUR-ból a swaybar-t. Ezek megint nem futási követelmények, de enélkül nem lesz háttérképed, paneled, zárolód, képernyőleoltós megoldásod. Pl. az swaylock, swaybar teljesen úgy működik, úgy néz ki, úgy konfigurálható, mint az i3lock, i3bar.

    A másik oldala a Waylandnek, hogy nem jók a közvetlen X.org szervert birizgáló toolok, pl. xrand, de ez nem is kell, mert ennek a funkcionalitása be van építve a Sway-be. Meg pl. X.org-os redshift helyett az AUR-os redshift-wayland-git csomag kell, i3lock sem fog menni, azért kell helyette az azonos funkcionalitást nyújtó swaylock. Ami még nem fog menni, az még a X-es képernyőlopók, de ott van helyette a grim. De ezek a nem mennek dolgok, hangsúlyozom, hogy csak az X szerveres toolokra vonatkoznak, mivel a Wayland egész más protokoll, másképp működik. Viszont az X kliens programok, azaz a X.org-os progik 99,99%-a simán megy, miután feltetted az xwaylandet.

    Böngésző azon kevés műfajok egyike, ahol a bloatot nem lehet megúszni, mindenképpen vagy a Gtk, vagy a Qt kelleni fog, akár Firefox/PaleMoon, akár Chrome/Chromium, akár Opera/Vivaldi, akár Brave mellett döntesz. Ezek a surf, qutebrowser, Falkon, stb., csak másodlagos böngészőnek jók, egy csomó oldalt nem tudnak normálisan megjeleníteni.

  • Frawly

    veterán

    válasz BoB #7129 üzenetére

    A próféta szóljon belőled. Ennek ellenére nem teszem vissza. Nem durcizásból, hanem már tényleg nem először volt qB-tel problémám. Igaz nem is túl sűrűn, kb. 3 évente egyszer, de nem akarok gikszert legközelebb. Egy ideje már a minimalizmus jegyében váltani akartam qB-ről, de mindig halogattam, hogy egyelőre még jó lesz, majd máskor váltok, elfér még, és végül ez az utolsó probléma adta meg a lökést, hogy a váltást komolyan vegyem, ne halogassam.

    Egyébként meg a Testing tároló nem gáz, ez az első problémám vele, pedig már majd 2 éve engedélyeztem. Eddig még nem tört el ezen kívül semmit. Vagy csak nem futottam bele, mert nem használtam azokat a csomagokat, amik eltörtek másnál. Igaz nem is sok csomag van benne, meg ha valami el is törik, az szerintem a sok függőséggel rendelkező, komplex/bloat rendszerek csomagjainál van, tipikusan Gtk-s, Qt-s alklamazások és DE-k, DE komponensek, amiket nem használok. De abban igazad van, hogy a Testing pont erre való, hogy ezeket a problémákat megfogja. Amit nem értek, hogy mi tartott eddig, mire javították, több hét telt el.

    Windowsra viszont még mindig ajánlom, mert a uTorrentet fizetőssé tették, az ingyenes verziót telenyomták reklámokkal és bitcoin miner szeméttel. Így ezen a platformon a qBittorrent a legjobb, meg nem szokott vele baj lenni, mert többen használják, és nagyon alaposan tesztelt binárisokat kap ez a platform, hozzá vannak csomagolva a szükséges függőségek is, dll-ek formájában, így nincs az, hogy a függőség törik el. Windowson amúgy sincs értelme a minimalizmusnak, mert per definitionem az egész platform bloat.

    Bár nekem az a legnagyobb szívfájdalmam, hogy az rTorrentet már régóta nem fejlesztik, szerintem végleg magára hagyták. Az lenne a legminimalistább, tényleg csak pár dolog hiányozna belőle, hogy az megfeleljen (torrentek sortartása, áttekinthetőbb CLI felület).

  • Frawly

    veterán

    válasz Siriusb #7126 üzenetére

    Nem keserítesz el senkit, sőt, jó is, hogy írod, mert ebbe bele fognak futni páran. Egyelőre még csak én futottam bele, de ahogy az új libtorrent-rasterbar verzió lecsorog a stable tárolóba, más disztrókon is, nem árt tudni erről a problémáról. Elhiszem, hogy azóta megoldották a qB-fejlsztők, de hány hét is telt el? Mondjuk lehet csak disztrószinten fordították újra a libtorrent-rasterbart, és nem a qB-fejlesztők oldották meg, de akkor is. Ez így élből komolytalan. Én annyiból valóban sajnálom, hogy ha a fejlesztők nem lennének ilyen nemtörődöm hozzáállásúak, akkor simán a legjobb opensource torrentkliens lenne. De ahogy nézem, a torrent egyfajta rétegigénnyé süllyedt vissza, most majdnem minden fejlesztő hanyagolgatja a témát, lásd transmission-cli-nak sem megy a régi TUI kliense. Tényleg összeszedhetnék magukat, mert ez a torrent egy elég régi protokoll, nagy újítás nem érkezik bele, a klienseknek mostanra már ultrakiforrottnak kéne lennie. Ha valami új dolog lenne, akkor elfogadnám, hogy még csak kísérleteznek vele, nem ért még be az egész.

    Azzal viszont maximálisan egyetértek, hogy ilyen SMB-s szopások helyett sokkal egyszerűbb egy FTP szervert beröffenteni, általában minden támogatja szerver és kliens szintjén is, és ugyan semmivel nem biztonságosabb protokoll, de legalább ransomware-támadásoknak nem esik áldozatul, és tényleg multiplatform, és baromi egyszerű működésre bírni, én is ezt szoktam preferálni gépek közötti megosztásnál LAN-on. Nagyon gyorsan be lehet konfigurálni egy FTP-t, míg az SMB-vel, meg NFS-sel elég sokat lehet szívni, amire általában az esetek 99%-ában nincs idő.

  • Frawly

    veterán

    válasz Archttila #7122 üzenetére

    Bizony, ezt írtam már többször, hogy a tilingnak nem az a lényege igazából, hogy felosztod a képernyőt, hanem hogy billentyűvezérlet, ami a legtöbb esetben hatékonyabb, mivel egy meghatározott billkombóra közvetlenül elérsz minden funkciót, minden bedrótozott progit, nem kell asztali ikonokkal meg dokkal és mindenféle panellel szórakozni, nem kell menüben 100 mélységig kattintgatni. Egy gyenge gépen is száguldani fog, olyan minimalista, RAM igénye majdnem 0. Mivel az egész egyetlen text alapú konfigfájlt használ, azért az egész konfigja egy mozdulattal elmenthető, a mentés visszahúzható, emiatt egyszer kell bekonfigolnod, és utána egy életre le van tudva a konfigurálással bajlódás. Sőt, mivel egyszerűbb, kevesebb függősége van, ezért kisebb eséllyel törik el frissítéskor, meg minden disztró tárolójában megtalálható, ha nem, akkor is könnyen és gyorsan lefordítható a kis kódméret okán forráskódból. Ez nem csak az i3-ra, Swayre, dwm-re igaz, hanem az összesre, Xmonad, awesome, bspwm, Openbox, *box, IceWM, JWM, stb..

    Ezzel szemben egy hagyományos desktopos bloat DE-t minden újratelepítéskor konfigurálhatsz elölről, lehet mindenféle menüben kattintani, meg beállításokat keresgetni, ami elég fárasztó, plusz mivel nagy, bonyolult kódméret, függősége sok van, ezért frissítéskor szeret eltörni, nehéz forráskódból kipörgetni, meg ki vagy szolgáltatva a fejlesztők kénye-kedvének, hogy egyszer csak kivesznek az új verzióból funkciókat, meg átrendezik a GUI-t az akaratod ellenére, lásd ahogy egyre inkább kinyírták a Gnome3-ban a funkciókat, lényegében hagyományos desktop helyett tabletfelületet csináltak belőle, azt is porig butítva, még asztali ikonokat sem lehet kitenni, mindenféle web extension-nel kell szenvedni. Ugyanez volt a helyzet a KDE4-ről váltásnál, mikor a KDE5-öt teljesen újraírták, és félkészen adták ki, vagy pl. most is volt egy csomó gikszer, mikor az Xfce váltott Gtk2 alapról Gtk3-ra, vagy az LXDE (ami még nem is bloat) váltott Gtk-ról, Qt-re (LXQt, igaz ez egy másik projekt, de már csak ezt gondozzák). Tiling WM-nél ilyen nincs, hogy átállnak másik alapra, meg elvesznek funkciókat, meg egyszer csak azon kapod magad, hogy Gtk2 helyett Gtk3-as vagy Qt-s lett, meg ilyen-olyan hülye trendek mentén rákényszerítenének olyan funkciót az emberre, amit nem szeretne, és lehet az egészet újra megszokni. A tilingot meg a minimalista stacking WM-et egyszer bekonfigolod, és biztos lehetsz benne, hogy egy apró konfigfájlt visszahúzva simán használható 10+ évig is ugyanúgy, megszokott működéssel és kinézettel, mindig lehet rá számítani. Vagyis inkább 2-3 konfigfájl, mert a panelnak, meg indítóalkalmazásnak is van konfigja általában, de a lényeg, hogy könnyen migrálható a beállítás néhány apró konfigfájl visszamásolásával.

    A Sway teljesen jó, 1+ éve használom már. Egy gondom van csak vele, hogy mivel systemd/elogind függősége van, ezért nem systemd-s disztrókon (meg pl. BSD-ken) bukta, hacsak nem telepítem az elogind-t, de akkor meg a systemd-s disztró értelme veszik oda, hogy hiába megy másik initrendszerrel, ha a systemd modulja (elogind) továbbra is fut a háttérben, akkor az ember csak magát áltatja, hogy nem systemd-t használ, közben pedig de.

    Egy dolog van, amit nem szeretek a tiling WM-ekben, az a teljes képernyős vagy floating ablakok primitív kezelése, pl. azonos munkaasztalon nem tudsz egyikben sem full screen vagy floating ablakot alkalmazásról elváltani másikra, vagyis a váltás megtörténik, de az előtérben lévő alkalmazás előtérben marad és kitakarja azt, amire váltottál. Csak akkor lehet váltani normálisan, ha kiteszed őket külön munkaasztalra és az asztalok között váltogatsz, de ez meg workaround, nem valódi megoldás. De ez megint csak nem az i3wm meg a Sway hibája, az összes tiling WM-re igaz..

  • Frawly

    veterán

    válasz Gelmi #7117 üzenetére

    Sajnos ez ilyen műfaj. Pont ez lenne a lényege annak, hogy szabad/nyílt szoftverre érdemes támaszkodni, saját NAS-t építve felhúzol rá egy free + opensource megoldást. Persze, időrabló, meg tanulni kell hozzá, de ha megoldod magadnak, akkor egyrészt olcsóbban kijön, másrészt nem vagy gyártó kénye-kedvének kiszolgáltatva, hogy meddig támogatja az eszközöd, kiad-e rá új firmware-t, ha nem, akkor ott állsz, mint Rozi a moziban, megvetted a NAS-megoldásukat és az volt érte a hála, hogy cserben hagytak.

    Persze kidobni még nem kell, a net szerint elfut ezen a Zyxel NSA310-en az OpenWrt, Openmediavault, meg Debiant is lehet állítólag rátenni. Nem tudom, sose volt Zyxelem, nem ismerem ezt a modellt. Ha nem is tudsz rátenni semmi nyílt rendszert, akkor is egyelőre használd így SMB1 megosztással, míg nem upgrade-eled.

  • Frawly

    veterán

    válasz Archttila #7120 üzenetére

    Mert a qBittorrent NOX sem megy, még mindig nem javították ki az új libtorrent-rasterbar library-vel való inkompatibilitást. Én meg nem várok tovább, míg méltóztatnak. Természetesen a qB is jó lenne pedig, akár csak ilyen nox-webes formában, ha menne. De nem megy.

  • Frawly

    veterán

    Na, sajnos a Transmission se jó. A saját cli-kliensük nem tud a saját transmission-daemon-jukhoz kapcsolódni, azt írja, hogy:
    Unsupported Transmission version: 3.00 (bb6b5a062e) -- RPC protocol version: 16
    Please install Transmission version 2.84 or lower.

    Ez azért azért gáz önmagában, amit tovább súlyosbít, hogy több mint egy éve ismert hiba, és nem hozták még helyre. Mindegy, egyelőre azért tesztelem a Transmissiont, mert a webkliens megy böngészőben. Plusz a CLI kliens problémáját megoldja a tremc-git AUR csomag, ami Python3-alapú CLI klienst nyújt, ami lényegében ugyanaz, mint a régi kliens, csak más nyelven írva. Bár nem tudom, hogy menyire van értelme a CLI kliensnek, mert az teljesen jó böngészőben, bloatabb ugyan a webes megoldás, de úgyis csak addig megy, amíg a futó torrenteket abajgatom, utána bezárom, és nem foglal, így teljesen mindegy, hogy a CLI kliens vagy a webkliens nem foglal.

  • Frawly

    veterán

    válasz vargalex #7110 üzenetére

    Ez igaz, az SBC-k nem érték még utol a desktop platformot. Meg talán sose fogják, mivel úgy vannak kitalálva, hogy 1/10-ed annyit fogyasszanak.

    Az i3 egy elég széles skálán mozgó proci egyébként. Nagyon nem mindegy, hogy mobil vagy dekstop, és hogy hányadik generáció. Pl. az i3-10100 egy elég combos proci, simán ver egy pár generációval előtte lévő asztali i5-i7-et! Ugyanis dupla annyi cache van benne, és dupla annyi mag/szál, mint a korai i3-akban, IPC is jócskán nőtt, meg megkapott egy csomó utasításkiegészítést, ami előtte nem volt i3-akon elérhető. De mondjuk egy i3-330M vagy i3-4120U az nem lesz valami combos, azzal sanszos nem lesz kihajtva még több magon sem a gigabites net, talán a 4120U az határeset lehet.

    Itt azt kell érteni, hogy bár megfizethető, a világviszonylatban a gigabit luxus. Bár megfizethetővé tette a Digi, meg a gigabites hálókártyák sem drágák már, de még sok ember UTP kábelinfrastruktúrája, routere, gépe nincs rá felkészülve, sem LAN-on, sem WAN-on.

    (#7109) Shyciii: még nem próbáltam ki a transmission-cli-t. Hétvégén sem volt rá időm. Fel van telepítve, de nincs bekonfigolva, nem röffentettem még be, igaz torrentet sem kellett letöltenem azóta. Lehet majd ezen a héten, mert vagy szabin vagy influenza miatti betegszabin leszek valószínű, így lesz elég időm és türelmem, hogy beállítsam, és megtanuljam használni.

    Mondom, nekem a qB-vel nem az a bajom, hogy Qt-s meg bloat, persze ezek hátrányai azért, hanem hogy a fejlesztők a libtorrent-rasterbar mögött kullognak rendszeresen, ez már rendszeres, hogy eltörik, és képtelenek időben kijavítani. Mert én vagyok a bloat legnagyobb ellensége, de ha valami tényleges átütő előnyt ad, azért néha használok én is bloat dolgokat, nyilván a minimumra szorítva, a legindokoltabb esetben. Ez utóbbi esetkörbe a qB eddig nálam belefért, de nem kap több esélyt.

    De ezen a ponton az bizonyosodott be, amit előre tudtam, meg ide a PH-ra is sokat írtam, hogy a minimalizmusnak pont az a lényege, hogy a minimalista/CLI programoknak nem nagyon van függősége, egyszerű a kódbázisa, így nincsen mi eltörjön rajtuk, nem függenek mindenféle más kódtól, és nincs az, hogy a sok függőség közül eltörik valami. Meg emiatt kódból forgatni is könnyebb, könnyebb frissen tartani ezeket a progikat, akkor is, ha nincsenek benne egy adott disztró tárolójában. Az már csak hab a tortán, hogy nagyon villámgyorsan is futnak, töltődnek be, és alig esznek memóriát.

  • Frawly

    veterán

    válasz vargalex #7107 üzenetére

    Ez van, a gigabit luxus, kihajtani csak extrákkal lehet, UTP6 kábel, gigabites router, erős proci, stb.. Nálam eleve csak egy magon is elég erős x86_64 procik futnak, és gigabites netem sincs, mindig 50 Mbit alatt, így nem érint, hogy mi hány magot használ. Ennek ellenére én is pozitívnak tartom, ha egy alkalmazás fel van készítve a több mag használatára, úgy a kernel szabadabban pakolgatja az erőforrásait, mégis csak segíthet a futásának az olajozottságán.

  • Frawly

    veterán

    válasz Shyciii #7103 üzenetére

    Régen, míg nagy seedállományom volt, és nagy tételben csapattam a témát, 300+ torrent seedelése ment 24/7-ben, 50+ GB feltöltés/nap, addig szükségem volt olyan funkciókra, mint különböző sebességlimitek, napi feltöltéslimitek, finom szemcsés prioritás fájloknál, torrentek közötti sortartás és prioritás kezelése, napi, heti, havi statisztikák, stb.. Akkor sok minden kellett egy torrentkliensből, csak az uTorrent meg qBittorrent jött szóba, a többi akkor a nyomába se ért ennek a kettőnek featureset-ben. Ma már alig torrentezek, azon belül is előfizettem inkább, így nem kell seedelnem annyit, ezért elég egy alap szintű torrentkliens is, annyi, hogy a torrentek közötti sortartást kezelje, meg hogy milyen fájlokat töltsön le a torrentből, mivel néha sorozatmegapakkokat töltök, de egyszerre csak 1-2 évadot belőle. Nagyon másra nincs igényem, alap szintű lett a torrentezésem.

    Ez a qBittorrent ilyen régi szokásként maradt meg nálam, még azokból az időkből, mikor full featured bloat DE-t használtam, azon belül is KDE-t, meg Qt-s progikat. Azóta persze már rég nem ez a helyzet, ahogy egyre jobban elmentem a minimalizmus felé, de a qB egy olyan progi volt, ami túlélt eddig. Béke poraira. A végén már csak a Wine, Steam, Firefox, terminál marad a gépemen, ami GUI-s program, a többi mind CLI-s lesz. Esetleg a Thunderbird van még fent, ha a neomutt nem boldogulna valami e-maillel.

  • Frawly

    veterán

    válasz Archttila #7099 üzenetére

    Érdekes, ezt már több helyről olvasom, nem csak te írod, hogy lényegesen lassabb a Transmission. Remélem nálam ez nem fog számítani, mert amúgy is csak olyan gyér netem van, amivel 1,5 MiB/sec-kel jön a cucc. Majd lemérem mit megy az rtorrenthez képest.

  • Frawly

    veterán

    válasz Shyciii #7094 üzenetére

    Azt elfelejtettem írni az előbb, hogy most a transmission-cli-t fogom kipróbálni. Már régóta látom linuxos videókon ajánlva, de még nem használtam. Sok évvel ezelőtt használtam a transmission-gtk-t, de az kifejezetten nem tetszett, mert fapados volt, akkor meg én nagyon benne voltam a nagy szabású seedben, bonyolult grafikus kliensekben. Most viszont nem ez a helyzet, adok neki esélyt.

    A transmission-cli nem csak CLI-ként használható, hanem böngészős webklienssel is. Azt sem próbáltam még.

  • Frawly

    veterán

    válasz vargalex #7093 üzenetére

    Az szívás. Jó is, hogy szóba került, a Zyxelt kerülni fogom a jövőben. Nem is gondolkozok NAS-ban, mert nem kell, de ha kelleni is fog, inkább összerakok valami sajátot. Az ilyen zárt hegesztésű fw-es csodákban egyébként sem bíztam soha.

  • Frawly

    veterán

    válasz Shyciii #7094 üzenetére

    Nekem nem kéne GUI-s, de a qBittorrent eddig olyan jó volt, és annyira bevált, annyira a legfunkciógazdagabb linuxos kliens, hogy ezzel kivételt tettem. Egészen mostanáig. Ma viszont repült a gépről, mert még mindig nem javították ki a hibát, ennyi nap után sem, ami azt jelenti, hogy a belátható közeljövőben sem fogják. Tudtam egyébként, hogy nem szabad kivételt tenni, most meg is bántam. Töröltem, mert már másodszor fordult elő, hogy nem bírják időben lekövetni a libtorrent-rasterbar frissülését, ilyen banda szoftverét meg nem használom.

    Nálam nem tett fel extrát a qBittorrent, mert a Qt-s dolgokat a Goldendict felrakta, igaz azt is dobni fogom majd, ha találok helyette jobbat.

    rTorrentből nekem az hiányzik, hogy be lehessen állítani, hogy egyszerre csak x darab torrent töltődjön, a többi álljon sorba. Egyébként más vonatkozásban megfelelne, fapados, de használható.

  • Frawly

    veterán

    válasz Gelmi #7091 üzenetére

    Ezt csak vészmegoldásnak használd. A NT1-et nem véletlenül kapcsolták ki Win10-en, ransomwaretámadások miatt. Azt ne akard beszívni. Inkább állítsd át a NAS-on is az SMB2 megosztást. Épp úgy fog menni, csak a hálózati helyek felderítése nem megy, mert az SMB1 specifikus feature, de megint jót tesz a biztonságnak, hogy nincs.

    Az SMB1 egy 1992-es protokoll, már rég elavult, biztonságilag rég 0, de egészen a WannaCry ransomware támadáshullámig mindenki azt használta, különböző Windows-verziók, és alternatív OS-ek közötti kompatibilitás miatt. Most viszont 2020-ban, modern OS-ek között nem kéne erőltetni.

    És mielőtt mondanád, hogy NAS-ról és Linuxról van szó, csak mondanám, hogy a ransomware azokat a megosztásokat is támadja, egy szép napon arra ébredhetsz, hogy a megosztásban az összes fájl le van titkosítva. Azért, mert maga a protokoll sérülékeny, nem a Windows OS, így az, hogy Linuxot használsz, nem véd meg. Persze maga a ransomware Windowson fut csak le (Wine nem elég kompatibilis neki), de ahhoz bőven elég, ha valami windowsos gépre is fel van véve a megosztás, írási joggal, már kész a baj.

  • Frawly

    veterán

    válasz vargalex #7068 üzenetére

    Amit viszont a fejlesztőknek nyomon kell követni, ha arra dependelik a szutykukat. Meg az is hozzátartozik, hogy a libtorrent-rasterbar az nem így hirtelen hozta ki az új verziót, hogy csak mindenki szívinfarktust kapott, hanem általában a kijövő új verzió pár hónappal előtte már folyamatában tesztelhető git-dev ágban, pont azért, hogy előre lehessen vele tesztelni, és ne megjelenés után érjen mindenkit meglepetésként, hogy jé, nem megy.

    Ezt csak azért írom, hogy ha vannak itt fejlesztésben laikusok is, akkor értsék, hogy ez nem úgy megy, hogy kijön valami új komponens, és akkor mindenki megijedve gyorsan lesöpri a fejlesztőasztalt, hogy jé, nem megy, milyen váratlan, gyorsan, hama-hama, reszeljünk rajta. Egy rendes fejlesztő mindig előre tesztel, még béta komponensekkel is, előre tart platformonként többféle dev/debug buildet, amikben már a következő komponensekkel teszteli a következő verziót. Itt az van, hogy a qB fejlesztők lusták, még kb. fél éve kihozták a stabil 4.2.5-öt, és kényelmesen hátra dőltek, az alkotás kész, a gép forog, az alkotó pihen, COVID nyári szünet, most jó, hozzá ne nyúlj, míg megy, még ránézni sem szabad, mert szemlenyomatos lesz. Most pofonként éri őket, hogy nem lett volna szabad pihengetni, fejleszteni folyamatosan kell, főleg a mai verzióhajhász/rolling világban. Aki pihenni, meg hátra dőlni akar, az keressen másik hobbit/munkát. Ilyen opensource multiplatformos fejlesztő majd csak akkor pihen, ha nyugdíjba megy, vagy épp szívinfarktus miatt tolják be a mentőbe, de ott is csak addig pihenhet, amíg töltődik a defibrillátor. Persze ennyire nincs kiélezve, egy ilyen nagyobb projekten, mint a qBittorrent is, több fejlesztő dolgozik párhuzamosan, fejlesztést megosztva. Ilyen projektnél eleve szokott lenni erre külön felelős (néha több ember), aki csak azzal foglalkozik, hogy jövőbeli dev verziókkal és komponensekkel tesztel, egyengeti az utat a többieknek. Míg megint egy másik emberke a jelenlegi stable előtti, de még támogatott stable verzióba szokta visszaportolni a jelenlegi verzió hibajavításait és feature-eit. Megint másik csak buildet csomagok meg ír alá, egy megint másik emberke a weboldalt igazgatja, megint másik a dokumentációt tartja karban, stb.. Tehát nem egy embernek kell az összes feladattal örlődni, nem is tudna, mert fizetés nélkül csinálják, abszolúte hobbiból, meg szakmai érdeklődésből, fejlődésből.

    Nyilván erre az Arch csomagfenntartó is figyel, nem véletlen, hogy az 1.2.10-es libtorrent-rasterbar nem került még be az Arch stable tárolóba, csak a testingben próbálgatják egyelőre, bár erre isten igazából a staging lenne való, csak azt a lépcsőt szeretik átugrani. Én viszont bekapcsolom a testinget, mert vannak benne frissebb csomagok, és szökőévente szokott probléma lenni belőle, így nagy hátrány nem ér miatta, cserébe gyorsabban kapom meg az új feature-öket, optimalizációkat.

  • Frawly

    veterán

    válasz vargalex #7065 üzenetére

    Kösz az infót, erre már nem emlékeztem, hogy az a testingből van. Kipróbáltam a nox-ot is, az is ugyanazzal a hibával hasal el. Nem fogom ennek ellenére a libtorrent rasterbart downgrade-elni, mert 1) semmi baja, 2) ez a qbittorrentesek bénasága, 3) dobni fogom a qbittorrentet egészében, amit már rég tervezek meglépni, azért is tesztelem már mellette egy ideje az rtorrentet.

    Kár érte, mert a qBittorrent azon kevés programok közül való volt, amiből még GUI-sat használok, ezzel hogy ez kiesik, már csak a Termite, Goldendict, Firefox lesz az, ami GUI-s és rendszeresen használom, persze a Wine, Steam, játékok is GUI-sak, de azokat ritkán futtatom. A többi progi mind CLI-s. De annyira jó és feature-gazdag volt az qB, hogy azt eddig nem tudtam elengedni, de úgy néz ki, ennek is eljött az ideje.

  • Frawly

    veterán

    válasz Archttila #7062 üzenetére

    Látod ez jó ötlet, ez nem jutott eszembe, kipróbálom azt.

    Siriusb: qbittorrent 4.2.5-1, libtorrent-rasterbar 1.2.10-1, amik fent vannak jelenleg. Az még hozzátartozik, hogy Archon Testing tárolókat is használok, de a vonatkozó csomagok mint a stable-ből vannak, a Testingben alig van csomag, onnan csak kernel (most 5.8.8-arch1-1) meg 1-2 dolog jön lényegében.

  • Frawly

    veterán

    válasz Nagytoll #7059 üzenetére

    Hasonló probléma merült fel most Archon a qBittorrenttel. Mindenhol crashel az új verzió, mert ebben már a qBittorrentet és a libtorrent-rasterbar-t is C++14-gyes beállítással fordították, de ez meg nem fér össze valami Python-gyökérséggel, ezért qbittorrent: symbol lookup error: qbittorrent: undefined symbol hibával elhasal az egész, nem indul. Állítólag várni kell, Arch és qBittorrent bugtrackeren is jelentve van már a hiba, dolgoznak rajta a fejlesztők.

    Még mielőbb jönne valaki ubuntus, hogy ×4rarolling, eltörtmegint, csaxólok, hogy ez specifikusan a qBittorrentes fejlesztők hibája, valószínű Ubuntun is eltört, ha már itt tartanak verzióban. Utoljára egyébként 3+ éve tört el a qBittorrent Archon, akkor is megint a qB fejlesztőinek a hibája volt, régi libtorrent-rasterbarra dependeltek, Archon meg egy újabb verzió volt.

    Egyébként meg ezért sem szeretem a komplex, bloatabb GUI-s programokat. Bonyásak, sok függőségük van, pl. ennek a qBittorrentnek Qt5, libtorrent-rasterbar, Python meg egyebek. Az ilyen komplexitási fok gyorsan törik el, mivel több modul válhat egymással inkompatibilissé.

    Ezzel szemben egy CLI-s rtorrent simán megy, nem törik el soha, mert olyan szög egyszerű, annyira kevés kód fut egymagában, hogy nincsen nagyon, ami eltörhetne rajta. Cserében grafikus felület nélkül is fut, headless szerveren meg konzolban.

  • Frawly

    veterán

    válasz Xenophobermn #7054 üzenetére

    Na, úgy néz ki, hogy rájöttem mi a bajod. Az alaplapi UEFI BIOS szivat téged, mert lecsatlakoztatod a SATA-t. Néhány BIOS ugyanis úgy van megírva, ha egy BIOS vagy UEFI bootopció mögül kiesik ténylegesen a drive, amire mutatna, akkor törlődik maga a bootbejegyzés is. Kevés BIOS csinálja ezt, de ezek szerint a te gépeden ez történik, és ez nem a Linux, vagy nem az Arch hibája, hanem a BIOS-é. Kétféle megoldás közül tudsz választani:
    1) soha nem húzod le a szóban forgó SATA meghajtót. Soha.
    2) Vagy az EFI bootpartíciót átteszed valami olyan belső meghajtóra, amit sose csatlakoztatsz le.

  • Frawly

    veterán

    válasz Xenophobermn #7049 üzenetére

    Ha jól értem, végül nem telepítetted a Windowst, mert már a telepítőt sem jól írtad ki. Szerintem csak induláskor hozd elő a BIOS bootmenüjét, és ott válaszd ki azt a meghajtót, amire az Archot telepítetted. Esetleg még azt tudom elképzelni, hogy az Arch a bootpartíciót valami másik meghajtóra tette, te lehúztad a kábelről, mikor a másik meghajtót dugtad rá, de végül nem ugyanoda dugtad vissza, ezért megkeveredett a meghajtók SATA sorszáma, nem jó sorrendben keresi a bootmeghajtókat a BIOS. Vagy csak az UEFI boot módot állítottad át BIOS bootra, vagy fordítva, és nem látja az Arch telepítést, ami másik bootmódban lett telepítve, ez ellen az orvosság, ha vegyes bootot állítasz be a BIOS-ba, CSM Legacy + UEFI, néha Mixed, vagy Both vagy hasonlónak nevezik.

    Bár azt se ártana tudni, hogy ezt a reboot and select proper boot device fleiratot mi írja ki pontosan, a BIOS vagy már az Arch bootmanagere?

  • Frawly

    veterán

    válasz Siriusb #7040 üzenetére

    Nálam nincs az illető fájlban ilyen, nem is tudom mi ez a tally, életemben nem hallottam még róla. Utánanézhetnék, de lusta vagyok hozzá. Nekem nem tört el semmi. Bár azt régóta tudom, hogy valamit nagyon rosszul csinálok, mert Archon nem szokott semmi eltörni. Utoljára Gentoo-n törtek el, kísérleti RC kerneles, meg -9999 verziós tesztcsomagok, de az utóbbiba is inkább az én tudatlanságom játszott bele, meg én kerestem a bajt, hogy ilyen ultrafriss csomagokkal próbálkoztam, ha már lúd, legyen kövér alapon.

    Abban viszont igazad van, hogy ennek kint kéne lennie az archlinux.org főoldalán, mert több embert érinthet, hogy akinek ilyen van benne ez a tally, szedje ki. Ezt sose értettem, pont erre lenne a főoldaluk hírszekciója, eleve fizetnek a szerverért, és nem használják ki, hogy van.

  • Frawly

    veterán

    válasz Laszlo733 #7009 üzenetére

    Akkor ezek szerint kernelfrissítés okozta, nem fordítottak bele valami modult, amit külön modulként kellett telepítened. Ez simán lehetséges, mint írtam, a dokkokhoz nem értek, sose használtam dokkot. Engem már az is meglep, hogy akármilyen driver meg kernelmodul kell nekik, hiszen ezeknek lényegében csak port replicatoroknak kéne lenniük, kivezetve azokat a portokat, amiket a gép elve dokk nélkül is támogat.

  • Frawly

    veterán

    válasz Laszlo733 #7007 üzenetére

    Mármint mi működik USB3-on?

    dmesg nekem sem mond semmit, de azt úgy kéne megpróbálni, hogy bebootolsz dokk nélkül, vársz egy kicsit, majd menet közben teszed a gépet a dokkra, és akkor megfigyelni miket irkál bele.

  • Frawly

    veterán

    válasz Laszlo733 #7004 üzenetére

    Ez a nem működik ez mit takar pontosabban? Nincs kép a két monitoron, vagy a dokkon semmi más sem működik? Milyen grafikus felület? xrandr látja a monitorokat? dmesg ír valamit kimenetben, mikor csatlakoztatod a dokkra?

  • Frawly

    veterán

    válasz #63718632 #6999 üzenetére

    Az installerek egyszerűen nem bírnak el túl sok telepítési opciót, ezért limitáltak, amit tudnak. A beállítási-telepítési lehetőségek száma végtelen, ha a kombinációkat nézed, lehetetlen mindent lefedni, még ilyen lehetőségszétágaztatós módszerrel sem. Egyébként vanilla Archban, mindenféle telepítő nélkül még jobban szét van dobva a rendszer konfigurálhatósága, Gentoo-ban még jobban, LFS-ben még jobban. Ez ilyen műfaj, pont ezért is találták ki ezeket.

    Ezek az installerek kezdőknek valók, akik egyébként nem tudnák a rendszert feltelepíteni, meg azt se tudják, hogy milyen csomagok léteznek. Meg esetleg olyanoknak, akiknek nagyon sebtével kell telepíteni valamit, pl. egy Ubuntu alapú GUI installeres disztró SSD-s modern gépen fent van 2-5 perc alatt, arra pl. jó, hogy egy alkalom erejéig, egy nap, egy projekt, tesztelés kedvéért ha fel kell húzni valamit, akkor legyen mihez nyúlni és ne menjen el rá sok idő.

  • Frawly

    veterán

    válasz csixy #6992 üzenetére

    Az se mindig jó, ha minden szart feltelepít, mind a 20-40 ezer csomagot. Ja, akkor fent lesz minden, senkinek nem hiányzik semmi, de 40 GB lesz a telepítés, és mikor frissül a rendszer, akkor sok giga frissítést húz le.

    (#6995) Shyciii (#6996) májkimiki: ezek szerint van ilyen. Ennek ellenére, aki ilyen szintig akar döntéseket hozni, az vanilla Archot telepítsen installer nélkül. Akkor mindent eldönthet saját maga. Pont ezért nincs az Archnak telepítője, nem azért, hogy a noobokat távol tartsák, vagy mert lusták lennének írni egyet.

  • Frawly

    veterán

    válasz Shyciii #6990 üzenetére

    Ezeket egyik telepítőben sem lehet választani, mármint azokat, amiket írtál. Pont ezért nincs az Archnak eredetileg telepítője, hogy te építsd fel a rendszert, ha nem akarsz GRUB-ot vagy display managert, akkor nem telepítesz. Ez a rossz ezekben az előre gyártott installerekben, kicsi a mozgástered, hogy mit akarsz telepíteni, a particionáláson kívüli dolgokba általában nem tudsz beleszólni.

  • Frawly

    veterán

    válasz zumike #6987 üzenetére

    Ez konkrétan LUKS partíción van az LVM vagy LVM-en van a LUKS? Melyik? Az Arch Wikit kéne követni. Nem kell semmilyen udev, meg systemctl. Azt kell pontosan csinálni, ami az Arch Wikiben van, tökéletesen működik, évekig LUKS-on lévő LVM-mel használtam az Archot, ezt csak akkor szüntettem meg, mikor SSD-kre tértem át, amik tudnak hardveres öntitkosítást.

    Mindenképp UUID-t használj, az mkinitcpio HOOKS-ok között az encrypt és az lvm is szerepeljen.

  • Frawly

    veterán

    válasz vargalex #6983 üzenetére

    Szerintem is ez a baj, nem futtatott mkinitcpio -p linux parancsot. Nem elég a konfigba a HOOKS-okat hozzáadni, újra is kell generálni az initramfs-t. Azért gondolom, hogy csak ez hiányzott, mert amúgy mindent jól csinál a leírása alapján.

  • Frawly

    veterán

    válasz Archttila #6979 üzenetére

    Böngészőből Firefox-szal megy, egyelőre csak Wayland alatt, vagyis ment, de nálam szintén Intel GPU-n (HD3000) eltört pár hete. De nemsokára kijön az új FF, két főverzió múlva, ami már X.org alatt is tudni fogja. Egy időben tudta a Chrome is, de állítólag ez a funkció eltört benne.

    Természetesen nem a Linux meg a driverek hibája, mert azok tudnák, a böngészőfejlesztők lustasága.

  • Frawly

    veterán

    válasz Archttila #6977 üzenetére

    Minden esély megvan rá. Semmi különleges nem kell, a kernelben lévő i915 kernel modesetting driver és az Arch alatt általában fent lévő mesa csomag (OpenGL, ezt behúzza függőségnek mindenféle grafikus környezet, mikor telepíted, a mesa meg behúzza a linux-firmware csomagot is) simán kezeli az összes integrált Intel GPU-t. Esetleg az intel-vulkan-t csomagot kell feltenned, ha kell Vulkan támogatás. A hardveres médiadekódoláshoz meg az intel-media-driver vagy libva-intel-driver csomagot kell feltenned, és az is fog működni (kivéve egyelőre alapból nem működik böngészőkkel, de ez hamarosan változni fog).

    Semmilyen hekkelés, konfigolás, meg ilyen komoly DKMS modulos forráskódos pörgetős hackelés és kínlódás nem kell hozzá.

  • Frawly

    veterán

    válasz Lathronos #6960 üzenetére

    Már mi nem lenne a te szinted? Ha az Archot fel bírtad rakni, akkor ez semmivel nem nehezebb. A ~/.config/polybar/config nevű configfáljban szerepelteted a override-redirect = false sort. Nagy valószínűséggel már benne is van, de ki van kommentelve.

    Ez ilyen, az ember mindig fejlődik. Már fejlődtél azzal, hogy Ubunturól Archra váltottál, aztán DE-ről Openbox-ra, Tint2-ről a még haladóbb polybar-ra. Ez ilyen fejlődési folyamat, minden lépcsőben fejlődsz valamit, bővül a tudásod, fokozatosan érted meg hogy működnek dolgok.

    Bár én azért nem értem, mert egy hónappal ezelőttig majdnem fél éven át Void Linuxot használtam, pont Openbox-szal és polybar-ral, és nálam még ez a override-redirect = false és wm-restack = sor sem, ki volt kommentelve konfigfájlban, anélkül sem volt gondom, a polybar nem volt látható teljes képernyőn.

    Egyébként meg ezek az advanced toolok, mint a polybar, ilyenek, nagyon hosszan és bonyolultan lehet konfigolni a konfigfájlban, lényegében annyira összetettek, mintha külön programozási nyelvek lennének. Cserében viszont nagyon rugalmasan testreszabhatók, és bővíthető a tudásuk, olyan szintig, amiről Tint2-nél nem is álmodhatsz.

  • Frawly

    veterán

    válasz Shyciii #6956 üzenetére

    De, minden OS ugyanúgy HDD-nek kezeli az SSD-t, mintha LBA szektorok lennének rajta. A Flash Translation Layer (FLT), wear leveling, garbage collection, meg egyéb belső működést az SSD aktív vezérlője végzi, és ennek a működési részét kitakarja mind a felhasználó, mind az OS felé, nem is enged ebbe belenyúlást, belehekkelést, részben garanciális, részben biztonsági/adatvédelmi okból.

    Az SD kártya, pendrive pont ettől más, annak nincs aktív vezérlője. Ezért azok profitálhatnak az F2FS-ből. Lényegében az F2FS egyfajta Flash-vezérlést hajt végre, de ez SSD-nél lehetetlenségbe ütközik.

    Sokakat az zavar meg, hogy az SSD is Flash NAND alapú memóriát használ, de a vezérlése egész más!

    Az F2FS nincs túltolva, kevesen is használják. Csak 1-2 elvakult fan akarja túlszépítve eladni. Mondom, próbáld ki, nem romlik el tőle az SSD, meg az Arch is bootol, de meg fogod látni, hogy nem hogy semmiben nem gyorsabb, mint egy ext4, hanem lesznek dolgok, amikben egyenesen lassabbnak is érzed. Nem szabad az ilyen benchmarkolós tesztoldalak hülyeségének bedőlni. Ezt viszont nem kell elhinni nekem, tapasztald meg te magad.

  • Frawly

    veterán

    válasz Shyciii #6954 üzenetére

    Oké, az SQLite indulását leszámítva ez az egy mérés valóban nem szintetikus teszt, hanem valós felhasználás. Bár még ez is kicsit szintetikusan lett kivitelezve a tesztben, mert a háttérben egyéb intenzív I/O benchmark futott szándékosan. Ez a valós felhasználásnál nem annyira jellemző, hacsak már nincs annyira határra tolva a gép, hogy nem maradt szabad erőforrás a háttérben.

    Meg mondom, sok mérés kamu benne, mert az ext4 és btrfs nem ilyen 5× meg 10× lassabb, a komának a rendszerével volt valami gebasz. Az f2fs-nél még a btrfs is gyorsabb tapasztalatom szerint, ha nem kapcsolsz be btrfs extra feature-öket, bár ha ezeket meg nem kapcsolod be, akkor meg a btrfs-nek nincs értelme és lehetne helyette annyi erővel ext4-et is használni.

    De erre már hívtam fel 1-2 éve is többször a figyelmet, hogy ez a Phronixos phószer mocsok elfogult a F2FS felé, én is az ő hatására próbáltam ki, de meg is bántam gyorsan. Mondom, ha nem hiszed el, tőlem kipróbálhatod, átformázod rá a partícióid f2fs-re, visszamásolod az adatokat, fstab-ban az UUID-ket kiigazítod, initramfs-ben az f2fs tool hook-ot beállítod, és teszteld vele a rendszert, vagy húzz fel egy másik rendszert f2fs-re, majd várlak vissza jelenteni, hogy nekem volt igazam.

    Meg ez az F2FS nem a legjobb egyébként sem SSD-re. Azért, mert az SSD vezérlője úgyis HDD-s működést amulál az OS felé, meg NTFS fájlrendszerre van optimalizálva. Ez az F2FS olyan „buta” Flash eszközökhöz való, amelyeken nincs aktív vezérlés (SSD-n van, meg sem lehet kerülni), pl. pendrive, SD-kártya, azon valóban gyorsabbak lehetnek F2FS-sel, mint más fájlrendszerrel, főleg random I/O-ban, szekvenciálisban már nincs nagy különbség szerintem. De HDD-n meg SSD-n kb. 0 értelme van az F2FS-nek.

  • Frawly

    veterán

    válasz Shyciii #6950 üzenetére

    Még egy gondolat a cikkhez: ezek szintetikus benchmarkeredmények. Nem valós általános felhasználás tesztjei. Utóbbiak pont azok lennének, amiket már írtam, bootidő, fsck lefutása, kis és nagy fájlok másolása, alkalmazásindítási idő, rendszer leállási ideje.

  • Frawly

    veterán

    válasz Shyciii #6950 üzenetére

    Ezt én is akartam linkelni a Linux OFF topikba, mert egy vicc. A Phoronix mindig az F2FS-t hozza ki győztesnek, de az én tapasztalatom szerint a leglassabb fájlrendszer, legalábbis nálam SSD-n, Archon. A leglassabb trimelésű, a leglassabb, mikor bootkor a fájlrendszer ellenőrzi a rendszer, a leglassabb, mikor alkalmazások indításáról van szó.

    Nálam az ext4 vált be, villámgyors. Nem tud sokat, de azt rettenet széptempóban. Egész partíció szabad helyének trimmelése néháyn másodperc. Bootkori fájlrendszerellenőrzés <1 mp. Progik villámgyorsan indulnak vele, lényegében azonnal a képernyőre vágódnak.

    Mondjuk ezt a NILFS2-t nem ismerem milyen, nem hallottam róla, nem próbáltam még soha.

  • Frawly

    veterán

    válasz Bici #6944 üzenetére

    Ez szerintem csak uninstallállással lehetséges. De nyugodtan uninstallálhatod, a beállításokat az nem törli alapesetben. Tehát csak egy yay -R csomagnév alapján leszeded, majd pacman -Sy csomagnév alapján felteszed. Nem fog elveszni semmilyen beállítás, rendszert sem kell újraindítani.

  • Frawly

    veterán

    válasz Shyciii #6938 üzenetére

    Olyat még nem láttam, hogy egy GPU a BIOS-ban nem volt letiltható. Bár én azért használnám, ha játszol is, mert játékok alatt a teljesítménye gyaníthatóan jobb, mint egy CPU-ba integrált megoldásnak, kivéve, ha nem nagyon modern prociról van szó.

    Annyi, hogy ha mégis használod, akkor fel kell rakni a zárt NV drivert, az Arch hivatalos tárolójából a legújabb 440-es driverágat, nvidia és nvidia-dkms azt hiszem a neve. NV-ben nem vagyok otthon, utoljára még a korai XP-korszakban volt a kezem ügyében NV kártya (MX440, FX5200), azóta vagy csak ATi (9600, 9800) vagy AMD (HD2400, RX570), vagy integrált Intel (GMA3600, GMA950, X3100, HD2000, HD3000, HD4000), Linuxon is csak ilyeneket használtam. ATi-t is utoljára még Ubuntu 10.04 alatt talán.

    Ha annyira le akarod tiltani, akkor talán a hozzá való csomagok eltávolításán túl le kell tiltani a hozzá tartozó kernelmodult, blacklist-ben, és akkor eleve már detektálni sem fogja a kernel, és a X.org sem.

  • Frawly

    veterán

    válasz Shyciii #6936 üzenetére

    Talán másfél éve használtam F2FS-t, körülbelül. A tesztek már 5 éve gyorsabbnak hozzák ki akárminél, ennek a bullshitnek ne dőlj be. Tőlem felteheted, a mentő nem fog elvinni, de ne mondd, hogy nem szóltam előre. Persze nagy károkat sem okoz, egyszerűen csak lassabb, főleg ilyen betöltési időkben, fájlrendszer-ellenőrzéskor, trimkor. Egyértelműen érezni, hogy az ext4 fürgébb. Szekvenciális értékek meg nálam nem fontosak, mivel nagy másolásokat és fájlírásokat ritkán művelek.

    Az az MX130 valóban nem egy nagy szám GPU, de egyes prociba integrált GPU-knál jobb lehet, kb. Vega8 szint. Erősen függ, hogy milyen Intel IGP-vel hasonlítjuk össze, mert azok is fejlődtek elég sokat generációról generációra. Bár ezt a „sokat” relatív fogalomként kell kezelni, mert egy kicsit is normálisabb dedikált asztali GPU-hoz képest így sincsenek fasorban sem. A mostani legújabb Intel GPU, az Iris UHD 630 kb. a GTX8800 szintjén van, ami egy 14 !!!!!! éves kártya. Az integrált AMD GPU-k kicsit erősebbek, kb. 2-3×-os a különbség, egy mostani AMD Vega 7 integrált laptop GPU kb. GT 740 szint, annál kicsit erősebb, ez már felzárkózás a 6 évvel ezelőtti szintre (bár erősebb asztali GTX kártyáknál inkább 8 évvel ezelőtti szint), 14 évvel ezelőtti szint helyett. Elvileg a Vega 11 egy kicsit erősebb, amit az asztali procikba integrálnak, kb. 1,5×, ezt elég nehéz belőni, hogy asztali GPU-ként minek felel meg. Főleg azért, mert benchmarkonként, játékonként, DX/OpenGL/Vulkan verziónként változik, hogy hol egyik kártya erősebb ebben-abban, hol a másik, vannak játékok, ahol egy átlagban egyenlő erejű kártya nagyon elhúz, driveroptimalizációk, játékoptimalzáció, több VRAM, gyorsabb fajta VRAM, vagy valami egyéb optimalizáció miatt nagyon fekszik neki, ezért nehéz a szinteket belőni.

    Egyébként ez a Xorg-os példád is azt bizonyítja, amit írtam. Ilyen Zen installereket mellőzni kell. Olyanoknak készültek, akiknek nincs meg a tudása az Arch telepítésére. Neked megvan, fel tudod tenni kézzel. Kicsit hosszabb, kicsit lassabb, bár nagy rutinnal nem valami nagy idő.

    Az viszont nem logikus, hogy leszedett driver mellett miért fogyasztott többet. Lehet valami mesa sw-render LLVMpipe drivert töltött be helyette, vagy nem tudom. Ilyet még nem láttam, hogy egy leszedett csomag nagyobb fogyasztást okozzon. De ezért is jó, hogy kézzel nekiállsz ezeket kikísérletezni, mert ezekből tanulsz, ezekből lesz rutinod, hogy milyen hardverhez milyen driverek, csomagok kellenek, így már kézzel is csukott szemmel fog menni a telepítés, csak felhúzod a csomagokat, és nem leszel semmilyen idiótáknak összeállított installerre rászorulva.

  • Frawly

    veterán

    válasz Shyciii #6933 üzenetére

    Én használtam fél-egy évig F2FS-t SSD-n. Ne ülj fel a teszteknek, borzalmasan lassú. Érezhetően lassabb, mint ext4-gyel. Ráadásul mikor én próbáltam, az fstrim is bugos volt vele, igaz ezt javították.

    Ha annyira akarod, próbáld ki, de csak akkor, ha mazohista hajlamaid vannak, és ne mondd, hogy nem szóltam előre.

    (#6934) Bici: lehetni biztos lehet, valami AUR helpert lefordítani Debianon és ott futtatni, az meg tudja csinálni a forgatást, meg megcsinálja a csomagot, legfeljebb olyan paraméterrel hívod, hogy a kész csomagot ne próbálja pacmannal telepíteni.

    Az Arch Wiki meg írja, hogy hogyan kell saját repót létrehozni.

  • Frawly

    veterán

    válasz Shyciii #6929 üzenetére

    A 214 alap memóriafoglalás kicsit sok. Igaz nem irreálisan. Ha fent van az udiskie, nm-applet (ez feltételezi, hogy megy a NetworkManager is), akkor simán lehet a közelében. Nálam az Openbox minden ilyen nélkül kb. 170 MB közelében volt, csak az Openbox, polybar, picom kompozitor, feh háttérkép futott (még téma sem volt az ablakokon), meg a háttérben a wpa_supplicant és dhcpcd (Wi-Fi-hoz, ennek egy hátránya van, hogy megszakad kapcsolatnál nem kapcsolódik magától újra), meg ezt én systemd-mentes disztrón mértem (Void), semmi systemd, semmi homed, semmi loginmanager, semmi.

    A másik, hogy ezek a task-manager típusú programok összevissza jelzik ki a szabad memóriát. Ezért én csak a free -m parancsot tartom hitelesnek, ez biztosan a kerneltől kérdezi le. Igazából még ebből is le kéne vonni a terminál és a free parancs fogyasztását, de ez elhanyagolható szokott lenni. De a htop is ugyanezt mutatja, csak az összeadja az used+share oszlopokat a free parancs táblázataiból. De a sima top, lxtask, gnome-system-monitor, stb. teljesen hülyeségeket szokott mérni. htop-ban a hres oszlop számít meg kicsit a shared, nem a mem%.

    Nálam most Arch, SwayWM Wayland, swaybg, swaybar eszik összesen szintén 171 MB-ot. Igaz 201-ről indul, de miután leült a dhcpcd meg valamelyik systemd service futása, onnantól 171-re süllyed tartósan.

    Nem csak a memóriafoglalás számít, hanem a betöltési sebesség is, igaz a kettő korrelál. Az, hogy most 30-40 MB plusz ide vagy oda, nem sokat határoz meg, lehet betöltési és bootidőben egy SSD-s gépen dob +2ms-ot. A lényeg, hogy nem olyan full DE-t futtatsz, ami indulásból bekajál fél-egy giga memóriát és vagy 9-10 mp-ig tölt bootkor, mire mindenféle service-t meg grafikus library hegyeket töltöget befelé.

    Ezek a scriptek meg veszélyesek, mert egyrészt változik mindig az Arch telepítése, valamit mindig variálnak, amiről a script nem fog tudni. Meg rugalmatlan, mert mindig ugyanazokat telepíti, én pl. mindig egy kicsit máshogy telepítek, bár ez változóban van, mert ahogy megyek az egyre nagyobb minimalizmus felé, úgy már nincs nagyon alternatív dolog, amit variálhatnék, erősen szűkülnek a lehetőségek 1-2 programra. Ugyanezért nem szoktam régi rendszert visszaklónozni, mert a felhasználói szokásaim, alkalmazáskínálat is változni szokott, nem megyek semmire egy olyan rendszerrel, ami a fél-egy évvel ezelőtti szokásaimhoz volt kialakítva.

    Az a baj, hogy így is kerül fel bloat a gépemre, AUR csomag telepítésekor, meg játékok, Steam is feltesznek egy csomó sallangot sajnos. Wine is bloat, meg az összes mainstream böngésző. Igaz ezek nem indulnak a rendszerrel meg ritkán is indítom őket a böngésző kivételével.

  • Frawly

    veterán

    válasz Shyciii #6918 üzenetére

    Azt is kalkuláld bele, hogy legutóbb a base csomagcsoportból kivettek egy csomó csomagot, ami nem települ default. Emiatt kevesebb csomagod lesz.

    Olyan nincs, hogy +30 megával több memóriafogyasztás, de a htop nem mutatja. Kapcsold be a rendszerfolyamatok mutatását is rajta. Linux kernel is hízik verzióról verzióra, systemd-nek is egyre több modulja fut, meg egyre több service-t futtat. Akár még X.org, kompozitor is ehet többet.

    Én ilyen Zen installereket és scripteket nem alkalmazok. Nagyobb munka ezeket megírni, mint kézzel telepíteni. Úgyse telepítek gyakran, meg legalább így telepítéskor rá vagyok szorítva, hogy újra és újra elolvassam az Arch Wiki-t, így látom, ha valamiben változás volt.

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

Hirdetés