- One mobilszolgáltatások
- Milyen okostelefont vegyek?
- Amazfit Active 2 NFC - jó kör
- Fotók, videók mobillal
- Samsung Galaxy A36 5G - a középső testvér
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Apple iPhone 15 - a bevált módszer
- Android alkalmazások - szoftver kibeszélő topik
- Három Pixel 9 jött Magyarországra
- Xiaomi Mi 11 Ultra - Circus Maximus
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
growler
#7798
üzenetére
Még nem használtam debtap-et, de én ha .deb csomag kell, akkor eddig vagy Double Commanderrel bontottam ki, vagy az "ar -xv" paranccsal, és az úgy nyert tar.xz-t pedig szintén kézzel, tar-ral, vagy Double Commanderrel, mc-vel, vifm-mel, stb. és kézzel másolom be a szükséges mappákba.
De az is igaz, hogy nem ez a megfelelő mód rá, mármint ahogy én csinálom. A debtap-ot szokták javasolni hozzá, vagy az AUR-ból felrakható dpkg csomagot. Én csak azért csinálom így, mert nem akarok hozzá plusz szutykot telepíteni, hanem megoldom azzal, ami épp a rendszeren fel van téve.
-
Frawly
veterán
válasz
szuszinho
#7796
üzenetére
Szerintem az illető kernelmodulnak túl új a mostani 5.10.14-es kerneled, még egy régebbi verzió a függősége. Esetleg próbáld meg a linux-headers csomagot is telepíteni, hátha az megoldja. Kötve hiszem, de egy próbát megér. Ha nem megy, addig nem tudsz kernelt upgrade-elni.
-
Frawly
veterán
Nem olyan. A PPA egy külső tároló, amiben már lefordított binárisok vannak. A fejlesztő git-es tárolóján maga a program forráskódja van, és ebből lehet több ág, jelenlegi legfrissebb (általában napi aktuális, master, current, dev), kiadás (release), kiadásra jelölt (RC), stb.. A -git végű AUR-os scriptek a legfrisebb kiadást töltik le a forráskódból és azt forgatják. Ennek egyébként még van egy olyan hátránya, hogy a -git végű hamarabb frissül, így ha gyakran ráeresztesz AUR-os frissítést, akkor állandóan frissülni akar, meg újrafordítani. A sima, nem-git-es változat csak tényleg verzióugráskor, kiadáskor frissül, fordítódik újra.
#7789 _Dumber_: nem baj, egy próbát megért. Nem volt felesleges, mert így megtudtuk, hogy nem a kompozitor felelős érte, így vagy az a modul, ami kiteszi ezt a menüt, vagy a KWin ablakkezelő bugja.
-
Frawly
veterán
Abból a nem-git-es verzió általában a fejlesztő által stabilnak titulált kiadás (release), míg a git-es változat meg közvetlenül a fejlesztő git tárolójának aktuális ágából lehúzott, épp az aznap aktuális legfrisebb dev verzió. Ezt azért nem bétának nevezik, mert a béta is kiadásalapon menne, ez meg ilyen folyamatos snapshot-szerű valami. Ilyenkor megéri általában a git-eset felrakni, és a nem-git-est csak akkor, ha a git-essel baj lenne. A git-es általában frissebb, több feature lehet benne, de cserébe a bugok esélye is megnő, ezért is töltenek fel az AUR-ban két változatot, hogy ha eltörne egyik, akkor a másikban egy stabil verzió még használható maradjon.
-
Frawly
veterán
válasz
_Dumber_
#7783
üzenetére
Ez mindenképp bugnak tűnik. Tesztképpen kapcsold ki a kompozitort. Akkor csinálja-e.
Egyébként meg screenshotot is tudsz lőni, állítsd be PrnScr-re, hogy ne a képlopó alkalmazás induljon, hanem egyben már a screenshotot is lője bele egy előre bekészített mappába. Akkor csak egy gombnyomás.
-
Frawly
veterán
válasz
Archttila
#7778
üzenetére
Ez ilyen műfaj. A Wayland-támogatás a Chrome-alapú böngészőkben a legkísérletibb, és ez a böngészőcsalád áll a legrosszabbul ezekkel a gyorsításokkal. Mondom, attól, hogy waylandes WM-et használsz, még nem muszáj mindenből a Wayland only megoldásokat erőltetni. Nyilván, ha van valamire natív waylandes alternatíva, érdemes azt használni, mivel soványabb lesz, nem kell a rendszernek hozzá XWaylandet betöltenie, de utóbbit sokszor nem úszod még meg. Ez még sajnos odébb van, hogy minden Wayland-kompatibilis lesz és minden megy vele. Megy persze így is, XWayland-es pótlással, meg kisebb-nagyobb workaroundokat alkalmazandó, teljesen használható a hétköznapokban, csak tökéletességet nem szabad még elvárni. Ez mindig ilyen, ha korai technológiát adoptál az ember, vannak vele extra lépések. Bár még mindig inkább ez, hogy korai adopterként huszárkodni, mint ókonzervatívként elavult technológiákkal küzdeni (ilyen ősrégi protokollok és verziók használata, MBR-hez és legacy BIOS boothoz ragaszkodás, mikor nem kéne, XP-s Matyik, 2.6-os kerneles CentOS-ses népek, Gtk/Gtk+, Qt3-4 libeken rekedt programok, 32 bites libekkel és 32 bites rendszerrel, PAE-vel szenvedés, stb.).
-
Frawly
veterán
Az szopás, akkor csak az marad, hogy arra a /boot/EFI/Microsoft/Boot/bootmgfw.efi fájlként másolod oda a grubx64.efi-t. Bár azt nem értem, hogy először akkor hogyan bootolt a Grub, mikor frissen telepítetted először. Mert ha ez a gond, már legelső esetben sem kellett volna bootolnia semmilyen általad most hiányolt „szép” bootmenünek, hiszen a grubx64.efi nem tudott volna elindulni.
Az efibootmgr kimenetedből nekem az jön le, hogy véletlenül MBR-rel particionáltad az adott meghajtót, vagy tévedésből egy másik, MBR-es meghajtód partíciójára hivatkozol (mert rosszat adsz meg az efibootmgr-nek).
Nagyon fontos lenne az efibootmgr kiadása előtt lsblk-val és fdisk -l segítségével (írja a partíciós tábla típusát) is tisztázni, hogy hogyan paraméterezed fel az efibootmgr kimenetét:
sudo efibootmgr --disk /dev/sdX --part Y --create --loader /EFI/GRUB/grubx64.efi --label "GRUB" --verboseItt X a meghajtó betűjele (esetleg ha NVMe meghajtó, akkor lehet a neve /dev/nvmeWnZ, ahol W, Z számok), az Y partíció száma, 1-től indítva. A --label "GRUB” helyett megadhatsz akármilyen címkét, pl. --label "Bla-bla", csak tudjad, hogy melyik bootbejegyzés melyik. Nem lényeges hogyan hívod, még akár lehet két különböző bootbejegyzésnek is egyaránt "GRUB" a címkéje, csak akkor hajlamos leszel összekeverni, mikor a Boot menüben választasz 1. GRUB, 2. GRUB, 3. akármi között, hogy akkor most melyik-melyik.
Nagyon könnyű összekeverni, hogy ha azt hiszed, hogy a /dev/sda meghajtóról van pl. szó, és közben meg épp másik betűjelet kapott, mert pl. valami külső meghajtó lett a gépen felejtve (pendrive, USB-s HDD), vagy egy Live rendszer vagy másik disztró alól próbálkozol. Kétszer is nézd meg, hogy jó meghajtót adsz-e meg neki, és hogy az valóban GPT partíciótáblás.
Tudom, baromi nyűg, nem felhasználóbarát, de ez a része még Windows alatt sem felhasználóbarátabb semmivel, ha nem bootol, akkor Windowsnál is a telepítőjét be kell bootolnod, ott elő kell szedned a Javítókonzolt, és ott a diskpart progival épp úgy ilyen elvont "sel disk akárhány", meg "sel vol akárhány" és bootrec parancsokat, meg mágikus szavakat kell a fejére olvasni. Tényleg nem könnyebb az sem semmivel, nem a Linux iránti elfogultság mondatja velem, végigcsináltam már ezt Windowson is, mikor egy régi HDD-ről egy új SSD-re klónoztam a rendszert, és nem bootolt UEFI-vel többé, elhasalt hibaüzeneteken. Sikerrel megjavítottam, de egy dekával sem volt könnyebb, mint a linuxos fdiskezés, meg efibootmgr-ezés. Sőt, még annyival rosszabb is a Windows megoldása, hogy nem ad annyi visszajelzést meg kimenetet.
-
Frawly
veterán
válasz
vargalex
#7760
üzenetére
Video accceleration nincs, de OpenGL vagy WebGL renderelésnek kellene lennie, és nála az sincs. Ami baj, mert így minden kirajzolandó elemet a proci számol, hangsúlyozom nem videóról van szó, hanem mindenféle weboldalelemről, kép, font, átlátszóság, stb.. Az is lehet, hogy a Chromiumnak nem tetszik a RPi4 GPU drivere, vagy csak az a része, amit a Wayland hajt.
A video acceleration az más, akkor a GPU nem a kirajzolást gyorsítja, hanem a videókodeket dekódolja ki (vagy encode-olja), hogy ne a procinak kelljen.
-
Frawly
veterán
válasz
Archttila
#7757
üzenetére
Ennyire azért még ne örülj, lesz még szükséged az XWaylandre, hiszen a legtöbb GUI-s program X-es, és használja, nálam a Wine, Steam, Goldendict, Thunderbird (a neomuttot nem szereti a Google, hiába álíltom be, hogy kapjon jogosultságot a mailjeimhez, állandóan elfelejti a rendszerük), meg 1-2 apróság és a játékok, akkor is, ha a FF-ot Waylandre állítom. Hiába 99%-ban terminálos TUI/CLI alkalmazásokat használok, sajnos abban az 1%-ban elkerülhetetlen, hogy X-es alkalmazást futtass. Persze, idővel egyre inkább nőni fog azon alkalmazások száma, amik natívan waylandesek, de még jó ideig nem tudod valós felhasználásnál mellőzni az Xwaylandet. Valós felhasználáson azt értve, hogy mindennapos desktop felhasználásnál. Ha valami speciális ipari, meg céges felhasználás, pl. egy progi fut rajta kiosk-módban, arra elég lehet a natív Wayland.
-
Frawly
veterán
válasz
vargalex
#7755
üzenetére
Oké, akkor elsiklottam felette. De örülök, hogy ennyire képben vannak, mert ez sok embernek okoz gondot, nem csak Archon, hanem mindenféle Linuxon, Deb/Ubuntu és Red Hat/Fedora vonalán is. Sok ember csak emiatt írja le az UEFI bootot, pedig nem is azt tehet róla, hanem a gyártó idiotizmusa. Sőt, még ennél is rosszabb, mert aki teljesen kezdő, és az az első tapasztalata a Linuxszal, hogy mindjárt az első telepítés után nem bootol neki, az meg nem azt fogja levonni tanulságnak, hogy a gyártó tehet róla, meg az UEFI boot, hanem azt hiszi, hogy a Linux ×4r, és pattintja is vissza a Win10-et. Amiben az az irónia, hogy az egész szenvedést a MS okozta karöltve a gyártóval, és visszamenekül azok karjaiba, holott pont ezt akarták elérni.
-
Frawly
veterán
válasz
jimmy399
#7752
üzenetére
Wow, még Dellnél is előfordulhat, igaz nem mindegyiken, mert nekem is volt Dell Latitude-om, és azon nem volt ilyen gond, de ezek szerint csak pont jó termékcsaládot fogtam ki.
Szépen megoldottad, ezt a megoldást felvehetnék az Arch Wiki-be is.
#7753 csixy: szerintem az idősebb kollégák vagy be sem küldik, vagy beküldik, de majd csak valami határidő-hosszabbítsára, hogy találjanak rá valakit. Esetleg valami fiatalabb asszisztens megcsinálhatja nekik, ha van olyanjuk.
-
Frawly
veterán
Nem kell semmilyen GRUB mappát csinálni, annak ott kéne lennie, ahol eddig is volt, csak bootbejegyzés nem mutat rá. Egyedül a grubx64.efi fájlt átnevezed bootmgfw.efi-re, és bemásolod a /boot/EFI/Microsoft/Boot/ mappába, persze miután csinálták kézzel ide mappát. Az UEFI-hez bootbejegyzést nem csak efibootmgr-rel tudsz csinálni, hanem magából az UEFI BIOS-ban is a Boot-opcióknál, vagy még ezt sem, mert ezt a Microsoft-os bejegyzést automatikusan megtalálja.
Csalódtunk benned, a továbbképzésen ki kellett volna követelni, hogy linuxosként a LibreOffice Writerből vagy terminálos sc vagy sc-im progiból akarsz továbbképződni
Azt se gondoltam volna, hogy van még ilyen telefonközpontos képzés, el nem tudom képzelni, hogy mit lehet továbbképződni, főleg, mióta gépek csinálják leginkább, de ha még oda is tesznek embert, akkor is csak pár gombot kell neki megmutatni, hogy milyen bejövő hívást hova hogyan kapcsolhat, és hogy kezelje a prioritásokat. Nagyon nagy tudománya ennek már nincs. De még régen, az analóg időkben is sokszor meg tudta csinálni egy helyben betanított portás, meg 0 műszaki érzékkel bíró Titkárságiné Mancika. -
Frawly
veterán
válasz
Archttila
#7746
üzenetére
Tipikusan a ~/.bashrc fájlban érdemes, beilleszted valahová ezt a sort:
EDITOR='micro'Ezt nagyon ajánlott beletenni, nem csak annak okán, amit írtam, hanem visudo, sudoedit, vifm, AUR helperek, meg egy csomó minden használja az EDITOR változót, hogy megtudják mi a felhasználó default text editora. Elvileg még grafikus felületű text editort is meg lehet adni, de az nem valami ideális.
-
Frawly
veterán
Nem értem pontosan a problémát. Mi az a szép sor? Ezt kéne tisztázni, utána talán meg tudom mondani, hogy hogyan kell felparaméterezni az efibootmgr progit.
A pontos leírás után mindjárt beközölhetsz egy teljes efibootmgr -v kimenetet is, annyival előrébb leszünk.
Ami a HP-t és az UEFI bootot illeti, ez egy ismert tény, ezt már többször leírtam ubyegonnak is, hogy miért nem bootol neki a Mint Cinnamonja, nem azért, mert az UEFI bootolás szar, hanem a HP az UEFI BIOS-ban lefixálta, hogy csak mindenképp a \EFI\Microsoft\Boot\bootmgfw.efi fájlból bootoljon, akkor is, ha van máshova mutató bootbejegyzés. Ez a HP görénysége, el akarták lehetetleníteni mindennek a bootolását, ami nem Microsoft Windows.
Erre, ahogy az Arch Wiki vonatkozó cikke is írja, két megoldás van. Az első, hogy a “Customized Boot” opciót át kell állítani még bootolás előtt a grafikus UEFI-ben erre:
\EFI\grub\grubx64.efiDe ez a módszer csak a legfrissebb HP UEFI-knél működik, BIOS-t kell hozzá frissíteni. Helyesebben pongyolán továbbra is BIOS frissítésnek hívja ezt mindenki, de valójában UEFI firmware frissítés lenne a szakszerű neve, a modern gépeken jó régóta nincs BIOS, ha az UEFI támogat is legacy BIOS módot, már azt is csak emulációval, nem valódi BIOS formájában.
A másik módszer meg elérhetővé tenni a GRUB (vagy a kernel, vagy egyéb linuxos bootmanager) indítóját azon a néven, amit a HP UEFI-je fixen tartalmaz, így a HP azt fogja hinni, hogy Windowst indítasz. Ehhez ezeket az utasításokat kell kiadni GRUB-hoz:
mkdir -p $MOUNTPOINT/EFI/Microsoft/Boot
cp $MOUNTPOINT/EFI/grub/grubx64.efi $MOUNTPOINT/EFI/Microsoft/Boot/bootmgfw.efiA $MOUNTPOINT változót előtte ellenőrizni kell, hogy a megfelelő helyre mutasson (pl. /boot), vagy egyből átjavítani a jó elérési útra. Ezzel a második, más néven átmásolós módszerrel mindenképp lehet bootolni, egy hátránya van, ha Windows dualbootot akarsz, akkor azt ellehetetleníti.
Azt is meg kell jegyezni, hogy ezt nem csak a HP csinálja, a HUP-on két user is jelezte ugyanezt a problémát, az egyik egy Acer Aspire netbookon, a másik valami noname x86-os táblagépen, már nem emlékszem a márkára, csak hogy valami ismeretlen márka volt. Persze attól még hogy többen is csinálják, nem kéne a gyártóknak ezzel kavarni, mert így a usereknek nem lesz bizadalma az UEFI bootásnál, és örök világvégéig fogják erőltetni az MBR legacy BIOS bootolást, aminek semmi értelme.
Egy fontos dolog: az efibootmgr paranccsal óvatosan szabad csak vitézkedni. Ugyanis előfordulhat, hogy ha rosszul van megadva egy kapcsoló, akkor az összes meglévő bootbejegyzést törli az UEFI NVRAM-ból vagy csak az aktuális bejegyzést teszi bele, ha az meg nem jó, akkor bootolhatatlan lesz a gép, és előfordulhat, hogy még egy USB-s pendrive-ról se fog bootolni, ha nincs az EUFI menüjében egy Restore Defaults opció a bootrésznél. Erre nagyon kell figyelni, mert nagyot lehet vele szopni, általában mindig van rá megoldás, de lehet nehéz tető alá hozni. Én ebbe a régi ThinkPad-emen belefutottam, mákom volt, hogy volt Restore Defaults opció, ha nem lett volna, akkor is meg tudtam volna oldani valami kényszerített firmware-frissítéssel, de oltári szívás lett volna.
-
Frawly
veterán
válasz
Archttila
#7742
üzenetére
A zip-es módszerre egy script is írható, amit a kedvenc fájlkezelődből hívogatsz, hogy ha .odt vagy docx formátumot nyitnál meg, akkor a scripttel nyitja, ami kicsomagolja a /tmp-be, onnan behívja rá az $EDITOR változóban lévő text editort (nálad ez elvileg micro), ott szerkeszted, kilépés után folytatódna a script, hogy azonos néven visszacsomagolja, visszamásolja az eredeti helyére.
Arra nagyon jó, ha csak egyszerű módosítások kellenek egy doksin, 1-1 szó beszúrása, törlése. Ami viszont hosszabb, meg több oldalas formázásos művelet, arra nem jó.
Én kifejezetten kerülöm az office-os formátumokat, libreoffice-osakat is. Ahol lehet plaint text-et, plain TeX-et, markdown-t, rtf-et, HTML-t, pdf-et használok doksinak, azok minden platformon bloatmentesen szerkeszthetők, megjeleníthetők, nyomtathatók. Nálam már kb. 2 éve nincs is fent LibreOffice, előtte meg kb. 1 évig fent volt, de csak megszokásból tettem fel, hátha kell alapon, de aztán rájöttem, hogy soha nem használom. De volt idő, mikor én is rendszeresen használtam, még kezdő koromban. Az MS Office-nál határozottan jobb, mára egy csomó mindenben többet tud már a LibreOffice, nincs belekényszerítve a szalagmenüs barmolás, de akkor is bloat.
Ugyanígy, táblázatkezelésre se kell feltenni, arra ott az sc, sc-im, meg a scriptnyelvek, ezeket kiegészítheted gnuplottal, és ugyanott vagy kb., ugyanazt megcsináltad töredék erőforrásból.
Prezentációkészítésre is vannak különböző pehelysúlyú alternatívák, pl. sent, akármilyen fentebb ismertetett szöveges formátum a kedvenc dokumentumnyelven (HTML, XML, TeX, stb.) amit pdf-re konvertálsz (de minden megjelenő prezentációs menüpont az külön oldalra generálódik le), LaTeX Beamer csomag, de már láttam olyan vagányt is, aki vim-mel ASCII art-ban (figlet, toilet, boxes, cowsay, ponysay, lolcat parancsokat ötletesen kombinálva) nyomatta a prezentációt, az már hardcore.
Adatbázis-kezelésre se kell feltételen MS Access meg LibreOffice Base, meg lehet oldani bármilyen SQL megoldásban, mariadb, mysql, de még minimalistább az sqlite, bár ezekhez kellhet valami minimalista kliens is, ennek nem vagyok szakija, de kulturáltan megoldható ez is különösebb blaot nélkül. Esetleg XML, CVS/flatdatabase plain text alapon.
MS Office meg LibreOffice akkor kell, ha olyan cégnél vagy, ahol tényleg kötelező mindent abban szállítani, de akkor meg fizetnek érte, hogy ezt lenyeld. Régen még hivatalok meg iskolák ragaszkodtak hozzá, mindent .doc-ban kell leadni, de ezt kezdik feladni. Egyedül még néhány munkáltató ragaszkodhat hozzá, hogy csak abban várja az önéletrajzokat. Vagy pl. dizájnban, grafikus kiadványokban utazol és muszáj InDesignt használni.
-
Frawly
veterán
válasz
Archttila
#7740
üzenetére
Lehet szerkeszteni vim-ben, Emacs-ben és Micro-ban, átnevezed az odt-t, docx-et zip-re, kicsomagolod, benne egy sztenderd XML fájl van, ami plain text-ként szerkeszthető. Pandoc tudja még konvertálni különböző formátumokra oda-vissza. Esetleg webes LibreOffice, MS Office, Google Docs, stb. tudja szerkeszteni, hangsúlyozom az online/webes verzióról beszélek, amihez semmit nem kell felrakni. Ha viszont rendszeresen szükséged lenne a szerkesztésére, akkor muszáj feltenni, hiába bloat, egyébként csak magadat szivatod meg. Pandoc se kicsi, igaz az nem is fut egyben, az egy tool-gyűjtemény, amiben számos CLI konverter van.
Az meg nem lep meg, hogy az újraindítás megoldotta. Ezért szajkózom az OFF topikban is, hogy a gépet érdemes minél többször újraindítani, főleg ha az ember rollingot használ és sokat frissít. Mert kékluficet büszkén mutogatta, hogy a Gentoo-ját gyakran frissíti, de már hónapok óta nem volt újraindítva. Nem hitték el, hogy ez így önszivatás, meg cirkuszi mutatványozás.
Én kb. naponta frissítek, és újra is indítok min. 1×, valamint a nap végeztével is kikapcsolom a gépet. Nincs értelme a sleepnek, hibernációnak, gyors gépek, SSD-vel, pár mp. alatt bootolnak komplett grafikus környezettel, nem látom értelmét a hosszú uptime-os kavarásnak.
Nem véletlen, hogy az összes supportos ügyfélszolgálat is úgy szokta kezdeni, hogy kapcsolja ki-be, indítsa újra, stb.. Ez az első hibakizáró lépés mindenhol.
-
Frawly
veterán
válasz
Archttila
#7729
üzenetére
Akkor esetedben maradj a feh-nél. Nálam az imv nem tett fel ennyi mindent, de ez azért van, mert nálam már fent volt az mpv, imagemagick, ffmpeg, meg hasonló csomagok, és azok az általad listázott csomagoknak a nagy részét már feltették, így az imv alig húzott le plusz 2-3 függőséget.
Meg ezeknek a függőségeknek a nagy része tényleg hasznos, nem bloat, pl. glu kell ahhoz, hogy hardveres gyorsítást használjon a progi, heic, raw, exr megint hasznos extra képformátumok és feature-ök támogatásánál, tehát nem olyan bloatsági függősége, mint pl. ha lenne egy rakat Qt/Gtk, meg mindenféle icon library függőség, ahogy a valódi bloat programoknál.
Egyébként én most fogom dobni a feh-t, xsetroot-ot használok majd háttérképnek, és kikapcsolom a picom kompozitort, mivel elhagyom az átlátszóságot, cserébe a X.org konfigba teszem be a tearfree meg DRI opciókat, így már nem fog bugzani az xsetroot. Nekem feh mindig is csak a háttérkép miatt volt fent, akkor is csak olyan X-es WM-eknél, amik saját maguk nem támogatták a háttérképet (pl. dwm, Openbox, bspwm, i3wm). Pl. IceWM támogatja, meg waylandes felületeknek is van saját háttérképmegjelenítője (Sway-nek swaybg).
-
Frawly
veterán
válasz
Shyciii
#7727
üzenetére
Ez igaz, hogy felesleges csak ehhez feltenni még egy programot, de az imagemagick hasznos egyébként is, mivel nem csak képforgatásra lehet használni, hanem bármilyen tömeges átméretezésre, konvertálásra, képmegjelenítésre, fontok megjelenítésére is, akár még pdf-et is konvertál, tehát egy elég univerzális eszköz, szinte bármit visz, ami nem hang vagy nem videó. Így én mindig felteszem, nyilván ez nem kötelező, egyéni döntés eredménye.
@sati: próbáld így:
for_window [title="feh"] floating enableEzt a swayimg-t még nem próbáltam, de egy elég szög egyszerű valaminek tűnik. Igényfüggő, hogy elég-e valakinek, már így ránézésre leszűröm ezt.
Rég nem swayeztem, már pár hónapja, mert az új gépre még nem tettem fel. Most újra X.org-os WM-eket próbálok, amiket régen nem próbáltam. De lehet visszatérek Sway-re, mivel az jobban bevált, de a Waylanddel az a baj, hogy kevés használható WM van rá, Sway, Weston, és kifújt. Vannak még waylandes WM-ek, de azok nagyon kísérleti, proof of concept állapotban vannak, és nem sok mindenre használhatók. Míg X.org-ra van egy rakat érdekes WM.
-
Frawly
veterán
válasz
Archttila
#7720
üzenetére
Igen, ez a videója elég láma lett. Bár nála megértem, hogy ódzkodik a Waylandtől, mivel OBS-t, meg egy csomó X.org-függő toolt használ a videói elállításához. Amúgy meg pechje volt, hogy pont egy szar swayes disztrót próbált ki, ami még nagyon kísérleti állapotban van, ebből meg levonta azt a téves következtetést, hogy a Sway meg a Wayland szar, és alfa, közben meg egyáltalán nem, mert használtam én is 1 évig, és semmi baj nem volt vele. Az se segített az ügyén, hogy rosszul beállított, hardveres gyorsítás nélküli virtuális gépen próbálta, nem fizikai gépen. Meg őnála a Sway eleve hátrányból indul, mivel i3wm klón, az i3 meg manuális tiler, és DT a dinamikus tiling WM-eket szereti. Szóval nála ez teljes istenkáromlás, hogy valami i3-szerű is legyen, meg Wayland is, ez túl nagy lelki törés. Amúgy persze nincs igaza, egy jó dolog, már most használható napi szinten, nem kell 5-10 évet várni vele, ahogy jósolja.
-
Frawly
veterán
válasz
Shyciii
#7719
üzenetére
Igen, én ezt értem, de képnéző szinten ez még mindig pinduri. Majd nézd meg mit foglal egy XnView, Gwenview, meg a többi, legalább egy 0 lesz még mögötte, és még esetleg megduplázhatod, megtriplázhatod még rá, ott lesz 100-300 MB környékén. Ahhoz képest eléggé pinduri, mivel nem használ semmilyen grafikus libet.
Tilingnál valóban kevésbé lényeges a háttérkép, de vannak emberek, akiknél vannak rések a csempék között, vagy mint nálam, hogy átlátszóság a terminálon, ami alatt átüt a háttérkép, meg hangulat miatt, míg el nem indítom az első alkalmazást, látok valami hátteret, kinéz az egész desktop valahogy, esetleg virtuális desktopoknál is jól jöhet. Most az a pár MB még nekem se tétel, amibe egy háttérkép kerül, bootidőben sem kimutatható. De azzal sincs baj, ha te nem használsz, mert tényleg nincs sok szerepe tilingnál, és ez is egyfajta minimalizmusos spórolás. Lehet még én is kipróbálom, tervben van véve, hogy csak egyszínű háttér legyen, meg a kompozitort és átlátszóságot is dobom, helyette tearfree opciót használok a X.org konfigban, és nem lesz átlátszóság sehol, úgyse használok transzparenciát a polybaron és terminálon kívül.
Képeket lehetőleg ne ffmpeg-gel konvertálj, hanem imagemagick csomag convert parancsa a legjobb rá.
-
Frawly
veterán
válasz
Shyciii
#7717
üzenetére
Ezt jó tudni, ez nekem is jól jön, mármint ez a Vifm-ből megnyitás, eddig imv %f %d illetve imv %f * beállítást használtam. Egyébként ha neked elég a feh, akkor maradhatsz annál is. De az imv többet tud. Ez a kétszer annyi erőforrás is relatív, mert a feh olyan pinduri, hogy annak a kétszerese is nudli, főleg, ha nagyobb képnézőkkel összehasonlítod. Nem akarlak egyikről sem a másikra átbeszélni, a feh-nek valóban megvan az az előnye, hogy kicsi, és ha már fent van háttérképmegjelenítésnek, akkor akár használható képnézésére is, miért ne. Nekem a feh túl fapad, de ha neked elég, akkor nincs azzal baj.
-
Frawly
veterán
Egyetértek, az imv az jobb, de a feh azért népszerű, mert X-es háttérképmegjelenítőnek használják. Amire persze megint lenne egyszerűbb, imagemagick display, vagy xsetroot, de azok (mint írtam) bugzanak egyes kompozitorokkal, míg a feh nem.
De ha csak képnézégető kell, akkor én is az imv-t preferálom, nem túl fapados, de mégis tudja a szükséges dolgokat, anélkül, hogy bloat lenne, még a vi/vim-billentyűket is támogatja. Plusz támogat X mellett Waylandet is. Az sxiv és feh túl fapados, a nagyobb képnézők meg túl bloatak imo.
Nálam ezek az imv, mpv, ffmpeg, imagemagick, sox alap toolok lettek, igazi svájcibicskák, sok mindenre jók. Lefednek majdnem minden kép/hang-nézési, szerkesztési, lejátszási, konvertálási igényt, ezek elsők között vannak, amiket felteszek minden rendszerre. Alig kell mellettük mást használni (nagyon ritkán használok persze flac, lame, oggenc, opusenc, qaac/neroaac enkódereket, de csak audio-nál teszek kivételt).
Az imagemagick-et kevesen ismerik, pedig az is jó, képmegjelenítésre, konvertálásra, font viewernek, stb.. zathura szintén, nem csak pdf-nézőnek, de ps, djvu, e-könyvformátumok nézésére is. vim (most már részemről neovim, de adott esetben Emacs, Micro, stb.) is elég univerzális, nem csak szövegszerkesztőnek, hanem IDE-nek, git-kliensnek, diff-ek nézésére, hexeditornak, dokumentumkonvertálónak (unix/win sorvégek, különböző kódlapok között váltás), terminál-multiplexernek, less-alternatívának, mindenesnek.
Terminálos fájlkezelők is ilyenek, jók doksinézőnek, tömörítő/mount felületnek, archiválónak, takarítónak, fájlkeresőnek, stb..
Ez a jó ezekben a minimalista CLI toolokban, hogy nem felhasználóbarátak, mivel nincs GUI-s interface-ük, ezért a kapcsolóikat, billentyűiket fejben kell tartani, meg kell tanulni, de ha valaki abszolválja, akkor utána mindent visznek, mint Kamaz a kereszteződésben. Többé nem kell vergődni, hogy jajjistenem, xy konvertálásához, szerkesztéséhez, nézéséhez mit tegyek fel. Igazából itt tud duplán kamatozni a vi/vim-tudás is, hogy annak a billentyűit általában minden ilyen tool ismeri, vagyis a legtöbb támogatja valamilyen szinten. Ez megint olyan, hogy kínkeserv megtanulni, de aztán nagyon hosszú távon kamatozik. Én ezért irigylem azt, aki még a 70-es években megtanulta a Unixot, C-t, vi-t, grep-et, sed-et, shellt, stb.-t, annak már 5. évtizede kamatozik mindaz a tudás, ami sokaknak a mai napig újdonság, meg megtanulhatatlan advanced tool, nem kell nekik állandóan X évente újat tanulni, mint ahogy anno a CP/M usereknek meg kellett tanulni a DOS-t, DOS után a Windowst, Windowson belül is jöttek-mentek a hülyeségek, Silverlight, .NET, PowerShell, Visual Basic, MS C, C#, stb., állandóan újat tanulni, most az web/electron-hájp, állandóan csak a fetrengés.
-
Frawly
veterán
válasz
Shyciii
#7710
üzenetére
De, a feh GUI-s progi, ha elindítod magában, akkor is működik, feltéve, hogy az adott mappában van képfájl. Nem sok az a 4-5 menü, de grafikus. Nyilván ez nem olyan nagy baj, de akkor sem tisztán CLI-s. mpv sem, de még mindig a legjobb lejátszó. Megjegyzem, hogy a CLI nem fontos azoknál a programoknál, amik úgyis grafikus képet nyitogatnak, pl. pdf/kép/videónéző/szerkesztő, stb.. VLC-vel nem az a baj, hogy GUI-s, hanem hogy rohadt bloat. És ezt nem csak függőségekre és memóriafoglalásra írom, hanem bugosságra, és tényleges prociigényre is, gyenge gépeken az a videó, ami mpv-ben folyamatos lejátszású, VLC-ben durván akad.
A webes Transmissionnek az a lényege, hogy böngésző minden gépen van, mindig fut jó esetben, semmi pluszt nem kell hozzá nyitogatni. Míg ha a legminimálisabb CLI klienst is használod hozzá, az többet foglal, mint a már eleve fent lévő böngésző. Meg webes interface-nél szét van választva a szerver-kliens, ezért távoli gépről is tudod irányítani, amit nem webes megoldásnál nem tudsz megtenni.
Nekem hiányzik a qBittorrent, mert a legjobb torrentkliens, még a bloatságát is elnéztem, de a fejlesztői töketlenkednek sorban, új verziókor nem követik le a libtorrent-rasterbar lib változásait. Merő lustaságból, és ebből elegem lett, így dobtam.
-
Frawly
veterán
válasz
Shyciii
#7708
üzenetére
Nem is fontos a mixer, az csak példa volt, hogy még olyan apróságokat is lehet optimalizálni. Én egyébként nem hangerő-szabályozásra használom, mert arra tényleg ott a billentyűzeten a hangerő fel/le gombok (meg némítás ki/be, és mikrofonnémítás ki/be), meg a polybar hangerőszabályozója, hanem kimenetek között választani, egyszerre több kimenet hangerejét szabályozni. Amúgy ritkán használok mixert én is, de akkor nagyon kell.
Transmission-ből fel tudsz tenni cli-s változatot és azt webes vagy terminálos tremc-klienssel használni. Bár azok sem esznek kevesebbek, mint a gtk-s változat.
A feh nem cli-s, de határeset, mert cli-s kapcsolókkal is működik. Nálánál minimalistább lenne az imagemagick display vagy a xsetroot, de azok bugzanak a picom kompozitorral, de egyéb WM/DE kompozitorával is összeakadhatnak.
A böngésző viszont tényleg az, amit nem lehet kiváltani minimalistábbra, abból muszáj GUI-s bloatot használni, ezt nem lehet megkerülni.
-
Frawly
veterán
válasz
Blasius
#7700
üzenetére
Net és BT amúgy elérhető a rendszeren, csak ikonja nincs? Konkrétan biztos megoldást nem tudok, de én úgy indulnék neki a megoldásnak, hogy terminálban a sudo pacman -S xfce kiadásával újratelepíteném az Xfce-t, de nem azért, mert ez konkrétan segít, hanem a telepítés végén a pacman kiírja az opcionális függőségeket, és ott sorolja, hogy mi van feltéve, mi nincs, hátha említi azokat a csomagokat, amik nálad a hiányzó tálcaappletekre vonatkoznak.
A hálózati Xfce tálcaikont egyébként az nm-applet nevű csomag adja, a BT-t már nem tudom, ezekre kéne ránézni, hogy telepítve vannak-e. Ha telepítve vannak, akkor kézzel kéne őket terminálból indítani, ha nem is indulnak, ott látszani fog a kimenetben a hibaüzenet, hogy miért nem indulnak.
-
Frawly
veterán
válasz
Shyciii
#7705
üzenetére
Egyrészt függ attól is, hogy az adott disztrón belefordították-e az xz és zstd csomagba a párhuzamos működést, Archnál belefordították, de magától nem megy, kapcsolókat (-T akármennyiszál) kell megadni hozzá, hogy több szálat használjon, és mint írtam, akkor sem skálázódik tökéletesen. Azzal egyetértek, hogy a Linux ebben lemaradásban van, mivel a Unix-filozófia miatt még mindig a tar + tömörítő CLI megoldásokat erőltetik, mivel a Unix-filozófia betartása, tar-ral való kompatibilitás, és a scriptekben való automatizálhatóság a fő cél, nem a GUI-s felhasználóbarátság.
A többiben egyetértek, az Arch valahol unalmas, minden megy rajta, nem nagyon törik el semmi, az ember már egy idő után nem tud mit optimalizálni, annyira minimalista és optimalizált a rendszere, hogy minden 0,00001 mp. alatt indul és megy, boot villámgyors, rendszer sovány. Ilyenkor mennek át az unatkozók Gentoo-ra, hogy azzal szenvedjenek egy kört. Bár optimalizálni mindig van mit, te is optimalizáltad a KDE-t Openboxra, majd azt bspwm-re, fájlkezelőt vifm-re, erre most a tömörítést zip-ről zstd-re, a rendszeren mindig lehet valamit optimalizálni. Én pl. nemrég a pavumixert és ncmixert váltottam át pulsemixer-re, a vim-et nvim-re, az automata csatolást saját scripktekre, az xz-t zstd-re, stb.. Ezért nem szoktam elmenteni a rendszeremet sem, hogy baj esetén visszahúzzam, mivel úgyis mindig változik a rendszerem, egy régi mentés visszahúzásával nem sokra mennék, mire azt átállítgatom újra, annyi erővel feltelepítek egy új rendszert is.
-
Frawly
veterán
Én a részemről a zstd-t használom, általános használatnál 19-es fokozaton, ha gyors tömörítés kell, akkor 3-as fokozaton, ha a tömörítési fok nem számít, csak a sebesség, pl. kernelimage, akkor az 1-es fokozatot preferálnám (de a kernel konfigban ezt nem lehet megadni, de gondolom 1-3-as fokozat valamelyikét használja).
A 22-es fokozat a maximum zstd-nél, de az nagyon lassú, lassabb, mint az xz maximum fokozata. 19-es fokozaton 2,5× gyorsabb az xz-nél, és csak 1-2%-kal tömörít rosszabbul, mint a maximum tömörítéses xz. A legideálisabb a 15-ös tömörítési fokozat nálam, az 8× gyorsabban tömörít a maximális zx-nél, de 12%-kal rosszabbul. De nem rossz a default 3-as tömörítési fok se, az 120× (!!!) tömörít be gyorsabban, de 25%-kal rosszabbul. A leggyorsabb, 1-es zsdt fokozat 167× tömörít gyorsabban, de 31%-kal rosszabbul. Ezek átlagos számok, egy 560 megás angol szótár tömörítésével tesztelve. Természetesen a „sima” linuxos zip-et veri keresztben-hosszában, tömörítési sebességre és tömörítési fokban is.
Párhuzamosításra viszont nem a legideálisabb, mivel hiába adom meg, hogy 8 szálon tömörítsen, jellemzően 4-5 szálat használ, a tömörítés vége felé már csak 2 szálat, majd 1-et. A 2 legfelsőbb ultra tömörítési fokozaton már csak 2 szálat használ, a tömörítés vége felé már csak 1-et. De a 7-zip is ugyanígy viselkedik, nem mértem le, de feltehetőleg az xz is. Tehát azt nem lehet elvárni egyik linuxos tömörítőtől sem, hogy állandóan kitekerik az összes prociszálat. Igaz ez a gcc-re is, ott is hiába adjuk meg a make-nek, hogy hány job-ot toljon párhuzamosan, még nagy projekteknél is fellép egyfajta limit, mikor nincs annyi párhuzamos fordítani való, hogy pl. 64+ szálat kihajtson. Igaz ez átlag konzumer szinten nem nagy korlát, mert az átlag konzumer proci kb. 4 szálat tud nagy átlagban. Mondom átlagban, van, akinek 16-ot, van, akinek csak 2-őt, a 4 az egy erős átlag, ami figyelembe veszi a még használatban lévő, de nem teljesen irreleváns procikat (régi Core 2 Duo/Quad vagy régi genes Core i, vagy Phenom / A / FX).
De flac-nál pl. a default 5-ös tömörítési fokot használom, mert nagyon gyors, és csak alig pár százalékkal tömörít rosszabbul, mint a sokszorosan lassú 8-as fokozat. Az is igaz, hogy a flac csak egy szálat tud használni maximum.
Az is igaz, hogy baromi ritkán tömörítek befelé, inkább csak kifelé, utóbbit is inkább vifm-et használva, ami meg fuse modulokat használ kibontásra. Mondjuk ma véletlenül többször is, mivel egy 96 kHz-es lossless flac albumot benyomtam 48 kHz-es 512 kbps-os opus-ba, meg most a zstd-t, xz-t, zip-et méregettem sebességre, tömörítési fokra, de ilyesmik szökőévente egyszer fordulnak elő.
-
Frawly
veterán
válasz
Shyciii
#7701
üzenetére
Ez a tar közbeiktatása a Unix-filózófia miatt, hogy egy tömörítő csak egy dolgot tudjon, csak tömöríteni, és ne kelljen tudnia fájlrendszerfüggő, és jogosultságkezelő megoldásokat lekezelnie, a tar ezeket a feladatokat leveszi a tömörítő válláról. Amúgy most nézem, hogy nem csak az xz, hanem a zsdt is tud már több szálon dolgozni, nem kell parallel változatot feltenni, -T0 kapcsolóval megpróbálják az összes magot használni. Az xz LZMA tömörítést használ (mint a 7-zip), emiatt jobban tömörít, de lassabb. A zstd kevésbé tömörít jól (ez a Facebook által kifejlesztett Zstardard tömörítést használja), de iszonyat gyors, és a kevésbé tömörít jól kitételt úgy kell érteni, hogy alig marad el néha az xz-s tömörítési foktól. Szóval így tömöríts:
tar -I 'xz -T0' -cvf tömörítvénynév.tar.xz forrásmappa
tar -I 'zstd -T0' -cvf tömörítvénynév.tar.zst forrásmappaHa nem akarsz ilyen hosszút fejben tartani, akkor lehet rá Bash-aliast csinálni, a ~/.bashrc-be:
alias tomorit="tar -I 'zstd -T0' -cvf"Ha annyira nem akarod ezt a tar-os megközelítést, akkor tényleg az marad, hogy vagy a zip (zip csomag) vagy 7z (p7zip csomag) valamelyikével tömörítesz, de egyik sem kezeli rendesen a linuxos jogosultságokat és attribútumokat, így rendes archiválásra nem jók, viszont nem igénylik a tar-t. Ezen felül a zip elég gyengén tömörít (és nem támogat több szálat), gzip-nek felel meg (igazából opensource pkzip-klón), a 7z már jobban, és az tud többszálúságot (igaz csak 2-4 szálat tud kezelni) és solid archivumot, mikor egy fájlként tömöríti, de ilyenkor lényegében ugyanúgy működik, mint a tar+egyéb tömörítő megoldás, elveszted azt az előnyét, hogy windowsos logika mentén működik.
Ott van még a rar, de annál megint ugyanaz az elakadt lemez forog: windowsos logika, de nem kezeli a linuxos jogosultságokat, így archiválni nem jó, plusz proprietary formátum, plusz tud solid tömörítést, aminél megint elveszik az előnye a nem-tar-os megoldásokhoz képest.
A példáimban egyszeres idézőjelben meg tudsz adni a tömörítőnek más kapcsolókat is a -T0 mellé, pl. tömörítési fok, ennek a mikéntjét a man tömörítő kimenetéből tudod meg. Bár a default tömörítési fokot éri meg legjobban használni, mert annak van a legjobb tömörítési fok / tömörítési idő arányszáma, a nagyon erős tömörítése fokozatok gyakran aránytalanul lassúak, és a gyakorlatban nem tömörítenek annyival jobban, hogy számítson. Régen, mikor kisfloppyra meg CD-re kellett mindent rányomorgatni, meg netsávszélt kell kímélni, akkor fontos lehet a legjobb tömörítési fok, de sima archiválásnál nincs nagy jelentősége, ez nem csak az álltalános tömörítőknél van így, hanem pl. a lossless audiotömörítőknél is, pl. flac. A legextrémebben tömörít a PAQ8 vagy ZPAQ aktuálisan legújabb variánsa, de ezek maximum fokozaton több órán, több napon keresztül tömörítik sok giga memóriát felhasználva azt, amit a normál tömörítők perceken belül betömörítenek, és cserébe csak néhány százalékkal tömörítenek jobban, ergo nem éri meg, mert csak a saját idejét őrli fel vele az ember, csak ilyen elméleti versenyekre jók. Épp ezért favorit most a legtöbb embernél a zsdt, erre áll át minden disztró majd, mert ugyan pár %-kal rosszabbul tömörít, de olyan villámgyors, mintha tömörítetlen adattal dolgozna.
A példáimban csak betömörítést írtam, de kitömöríteni is így kell, csak a c kapcsoló helyett x kapcsoló kell.
-
Frawly
veterán
válasz
Shyciii
#7697
üzenetére
Igen, van rá módszer, de nem általános, amivel minden tömörítő egy csapásra használ minden magot, hanem a különböző tömörítőkből vannak parallel nevű verziók, amik tudnak több szálon ki/betömöríteni, gzip helyett pigz, zstd helyett pzsdt. xz az pont kivétel, abba be van építve a több szál támogatása, de ott is CLI kapcsolót kell beveretni hozzá. Tar-ból nincs parallel, mert annak a működési elve lineáris, tape (TAR = Tape ARchive) folyamot csinál az adatokból, ezt nem tudod párhuzamosítani, de cserébe nem igényel procit/memóriát, csak lemez I/O-t.
De ha mindezeken túl vagy, akkor is van egy olyan rossz hírem, hogy még ezek a parallel változatok sem tökéletesek, mivel egy fájl per egy szál alapon dolgoznak, és ha egy archívumban vagy mappában kevesebb fájl van, mint amennyi CPU-szál, akkor néhány szál mindenképp kihasználatlan marad.
De Linuxon és unixlike rendszereken mindig is ilyen elmaradott volt a tömörítés, eleve a legtöbb tömörítő csak egy fájlt tud tömöríteni, azért kell tar-ozni, mert előbb tar-ba bemásolja az összes fájlt/mappát, majd ezt egy nagy fájlként kezelve tömöríti be, ezért van, hogy Linux alatt nem használnak .zip, .gz, .lmza, .zst formátumot, hanem csak tar.gz, tar.bz, tar.xz, tar.lzma, tar.zst, tar.akármi. Van azért ez alól is kivétel, pl. 7-zip, nanozip, Rar, stb., de azok meg sokszor a linuxos jogosultságokat és metaadatokat nem tudják kezelni, eldobják tömörítéskor, míg a tar-os megoldás megőrzi ezeket is.
-
Frawly
veterán
válasz
jimmy399
#7685
üzenetére
100 megás EFI partíciónak elégnek kéne lennie, volt, hogy nekem is akkorán voltak a Win10 indítófájlai és az Arch kernele, initramfs-e, fallback initramfs-e, és még hely is maradt rajta valamennyi. Egyébként át lehetne méretezni, vagy egy másik FAT32 partíciót létrehozni a többi mögé, kicsit kéne csak az Archon szerkesztgetni hozzá, de a Windows garantáltan nem bootolna, persze lehet meg lehetne javítani Windows telepítőből indított javítókonzollal, de nem biztosan. De maradhat így is, hogy a fallbacket letiltottad, nekem még 5 év archozás során egyszer se volt rá szükségem, hogy fallbacket bootoljak be.
Egyébként megint itt jön, amit mondtam. Hogy egy telepítő ne döntse el az ember helyett, hogy neki mekkora EFI partíció kell, mert 640 KB meg 100 mega mindenkinek elégnek kéne lennie. Pont ezért nincs az Archnak telepítője, hogy ne hozzanak meg a user helyett ilyen kontár döntéseket, hanem az ember a saját rendszerét építhesse. Nem azért nincs a telepítő, hogy a kezdőket tartsák távol, meg szopassák a konzolban parancsok begépelésével, meg Wiki-ben írt litániákkal és technoblablával, és magukat elitistának tüntessék fel.
-
Frawly
veterán
válasz
Shyciii
#7682
üzenetére
Ez szerintem fordítva van. Az vanilla Arch és vanilla származékai (telepítő nélkül), azért rakják a user-t a userneve csoportba külön, ha felelőtlen csoportjogokat osztogat a fájlrendszeren, akkor még mindig nincs baj, mert ő a saját csoportjának a tagja, és másnak nem adott hozzáférést. Míg ha egy általános csoportba tartozik, akkor egy hibás döntésével több embernek is adhat hozzáférést, ami biztonsági kockázat. Nekem, mint írtam, mindegy.
Ez sokszor ízlés kérdése is, hogy ki milyen csoportba szereti tenni a felhasználót, meg milyen szoftvereket használ.
-
Frawly
veterán
válasz
vargalex
#7672
üzenetére
Igen, nálam is így hozza létre az useradd -m parancs, amit mindig az Arch Wiki alapján csinálok. Az megint más, hogy én utána usermod-dal berakom a felhasználóm a video, storage, disk, audio, wheel csoportba is, néhány szoftvernek meg a sudo-nak szüksége van ezekre. De ez sem úgy történik, hogy így hozódik létre telepítéskor, hanem én futtatom tudatosan ezeket a user/group parancsokat, semmilyen automata installer nem dönti el ezt helyettem. Ez a jó az Archban, csak a systemd és az initramfs van eldöntve az ember helyett, minden mást saját maga állíthat, telepíthet.
Engem egyébként nem érdekelne, hogy a userem tagja-e a userem nevű csoportnak, vagy csak a users-nek. Teljesen mindegy. Ha annyira zavar valakit, később egy darab usermod paranccsal át tudja ezt szabni magának, csak akkor lehet a fájlrendszeren a user fájljainál át kell szabni a csoportjogosulságokat is chmod-dal.
Egyébként míg nem lesz jó a Gentoo-m, addig feldobok egy Archot az Artix helyére. Oka: Artixon nem tudtam megoldani a lassú mirrorokat, és a rendszer idle memóriafogyasztása elszállt 300 MB-ra, ami nálam sok. Archon 140-170 körül tartottam, pedig ott systemd is van.
-
Frawly
veterán
válasz
#63718632
#7668
üzenetére
Archon nincs telepítéskor létrehozva semmi. Pont ez a lényege az egész Archnak, pont azért nincs telepítője sem. Alapból csak egy root felhasználó van, be nem állított jelszóval. Nincs létrehozva semmilyen más user telepítéskor, te hozod létre, és az meg úgy jön létre, amilyen kapcsolókkal beveretted az useradd parancsot (Installation Guide vagy Arch Wiki alapján).
#7673 sati: én is akartam venni ilyen K400-at, de letettem róla, rossz latency, meg ez az Fn mizéria, kellene lennie a billentyűzeten FnLock-nak, de nincs. Csak windowsos szoftverrel lehet megoldani, ha van is rá valami linuxos progi, az tuti X.org-alapú, és Waylanden nem fog menni. Persze nem lehetetlen, hogy létre lehet hozni egy egyedi X.org-kiosztást, amit utána meg lehet adni a Sway beállításainál, de ilyet még nem csináltam, fogalmam sincs hogyan kell.
Az új laptopom is ilyen, gyárilag Fn-t kell nyomkodni a funkcióbillentyűkhöz, szerencsére van a billentyűzeten FnLock, meg az UEFI BIOS-ban egy opció, ami automatice bekapcsolja induláskor, így nem kellett szenvednem ilyennel. Jó lenne, ha a billgyártók ezt a Fn+ dizájnt dobnák, marha nagy balfékség, semmire nem jó kavarás.
-
Frawly
veterán
válasz
vargalex
#7667
üzenetére
Igen, ezt megerősítem, ha valaki az Arch Wiki user and groups cikkét követi, akkor ott a legelején említett useradd -m blabla sor felhasználónév felhasználót default a felhasználónév csoportba létrehozva teszi be, Archon és Artixon is. Bár nem is értem mit kever a kolléga, ez neki miért fontos, mert ha nincs is saját csoportban, akkor is épp úgy kéne működjön minden. Szerintem valami kókler install scripttel telepítette, vagy rosszul másolt ki valami parancsot.
Egyébként meg úgy kell felhasználót hozzáadni, ahogy Chuck Norris csinálja, systemd-homed-vel, akkor a gid/uid lesz a legkisebb probléma
-
Frawly
veterán
Elég régi eszközeid lehetnek, én már routereken sem látom soros portot elég régóta, legalább a lakossági, konzumer eszközökön nem. Céges/ipari routernél, switchnél, stb. még van. Soros port ugyanolyan jól megy Linux alatt is, csak valami biztonsági alap szabály tiltja alapból a hozzáférést, külön jogosultságadással kell engedélyt adni, onnan megy. Egyedül műholdvevőnél lehet problémás a soros port, nem a soros porti mivolta miatt, hanem mert általában valami Windows only segédprogramot is igényel a firmware feltöltése, ami a hardverközeli matatás miatt jó eséllyel nem megy Wine-ban, de sajnos műholdvevőn ez a firmware-cserélgetés, meg kódolásmatatás mindig szopóroller, még Windowson is, max. csak pár lelkes műkedvelő szokott vele szórakozni.
Outlook-os mailszolgáltatást nem ismerem, de ha viszi a Thunderbird, akkor a kérdést meg is válaszoltad saját magad.
Ezt a képkivágást, képbetömörítést simán viszi a GIMP is, de talán még valami linuxos Paint klón is (Paint.NET, MyPaint, stb.). Ezeknek az Irfan/XnView progiknak inkább csak tömeges konvertálásnál van értelme, de arra meg ugyanolyan jó az imagemagick convert, csak ki kell tapasztalni a felparaméterezését, terminálba bevereted:
pacman -S imagemagick
cd képek_mappája
convert újméretxújméret+eltolás+eltolás -quality blabla% *.akármi *.jpgDe csak most a te kedvedért kipróbáltam, feltettem Artixra az XnView MP-t AUR-ból. Csak egy apróbb függősége volt, probléma nélkül felment pár másodpercen belül. Teljesen jól működik, tudja azt, amit keresel, megnyitom a képet, kijelölöm azt a részét, amit ki akarok vágni, majd Crop (Shift+X), végül File - Export menü (Crtl+Alt+S) és ott be lehet állítani, hogy jpg-be mentsen, hány százalékos tömörítéssel, milyen beállításokkal, mikor megvagy, Export... gomb, ott rákérdez hová mented, milyen néven, és kész.
Nyilván a felülete kicsit fapadosabb, mint az IrfanView, meg kevesebbet is tud az XnView MultiPlatform változata (a multiplatform miatt), de azért használható. Ezért is írom, hogy a megszokás nagy úr, a gépek nagy részén a mai napig azért van Windows, mert a user azt szokta meg, ergo az áll neki kézre. Ha majd annyira megszokod a Linuxot meg a linuxos ökoszisztémát, az fog kézre állni, és a Windows nem fog többé.
Bár még az IrfanView nem olyan nagy érvágás Wine-ben, mivel egy kisebb méretű szoftver, nem használ túl sok windows-specifikus hívást, sem hardverközeli mókolást, sem DRM-et, nem telepít szutyok kémszoftvereket és service-eket, a képfeldolgozás-tömörítés a mai prociknak nem tétel egy átlag szintig, ergo az emulációs overheadje se magas. De! Elvi kérdés, hogy ha van rá használható natív alternatíva, akkor lehetőleg annál érdemes maradni. Ha mindenre ilyen megszokásból Wine-t használsz, akkor kb. nem sok értelme volt Linuxra váltani. Félre ne érts, okés a Wine, olyan programoknál, amiknek nincs tényleg linuxos alternatívája (néhány játék, és legacy program, pl. nálam a Scriptum GIB szótár kezelőprogija, Apple QAAC encoder, stb., de ez utóbbit nem nagyon használom, eleve natív oggenc-et és Goldendictet használok pl., inkább csak a Steam miatt van fent a Wine). Akkor valóban jobb Wine-ozni, mint Windowsra átbootolni, meg a gépen NTFS partíciókat tartani, stb.. De nem szabad túlzásba sem esni, a minimumon tartani a Wine-os alkalmazások számát. Így tisztább, gyorsabb, meg így fogsz csak Linux terén fejlődni.
-
Frawly
veterán
Nem, nincs harag, nem is azért írtam, hogy megbántsalak. Csak furákat írsz, mint most is a windowson levelezést szereted. Az pl. pont az a műfaj Windowson, hogy egyik (pl. Outlook akármelyik verziója) mailkliens C4rabb, mint a másik (pl. The Bat), egy normális van, a Thunderbird, de az meg natívan megy Linux alatt is. Elég sokan csak böngészőből leveleznek webes felületről, arra meg megint csak jó ugyanaz a Firefox, Chrome, akármi, ami Linux alá is van.
Párhuzamos portot is van 15 éve nem használtam (akkor is utoljára retró gépeken), az utoljára nagyon régi nyomtatóknak, ősi szkennereknek, ZIP drive-oknak kellett, meg két DOS-os gép összekötésére, ha nem volt bennük hálókártya, de mégis fájlokat akart megosztani az ember, gyorsabban, mint a soros port lehetővé tette. Már vagy 10+ éve egy új gépre se teszik rá ezt a portot.
A soros portnak lehet még haszna, egyes eszközökön (szerver, hálózati eszköz, műholdvevő, ipari gépek, stb.) az admin port / konzol még mindig soros port, de ezt meg USB-RS232 adapterrel szokták megoldani, meg ez megint már nem home user kategória, amit az itteni PH-s topikokban én azért titkon feltételezek.
XnView-ból mi hiányzik, ami az Irfanban benne van?
-
Frawly
veterán
Nem megkövezés, de windowsos program hiába megy, azért szuboptimális Linux alatt, lassabb, emulációs többletterhelés, nem kezeli a linuxos jogosultságokat és attribútumokat. Az XnView 99,999%-ban helyettesíti az IrfanView-t, ami nem véletlen egybeesés, hanem szándékosan annak a klónja. Bár én még az XnView-t, meg ezeket a full extrás képnézőket, és képszerkesztőket sem szeretem már, igazából olyan mindenesek, bloatok, de cserébe egyik területen sem kiemelkedőek. Egy képnéző nézzen képet, legyen minél egyszerűbb és ennyi (az imv, svix, és hasonló csak ezt tudja). Egy képszerkesztő meg tudjon szerkeszteni, ala Gimp, Darktable. Egy konvertáló meg tudjon konvertálni, legyen abban jó (imagemagick convert, ffmpeg, sox, stb.). Egy mindenből kicsit módszerrel Fradi-levest kapunk.
Ezt a GPT vs. MBR-t sem értem. Mindegy melyik, egyiktől sem lesz gyorsabb a gép. Az UEFI boot elegánsabb és gyorsabb lehet, de csak azért, mert nem kell hozzá egy csomó BIOS-os detektálás, meg mindenféle extra bootmanager, ez viszont nem minden gépen hoz ténylegesen gyorsabb bootot, inkább sokszor csak a dual/multiboot elegánsabb vele, kiváltja a GRUB-ot, az egyes OS-ek nem írják felül egymás bootmanagerét az MBR-ben. A Core i platform akármilyen régi, azok mind támogatják az UEFI bootot,, nem csak a 9 évesek, hanem a 11 évesek is. Amelyek meg ettől régebbiek, azok meg úgyse, azokon mindenképp a Legacy boot marad MBR-rel. A GPT csak akkor kötelező, ha NVMe-t használsz, vagy 2 teránál nagyobb lemezt, vagy Windows kell UEFI boottal (pl. eGPU-hoz).
Sokszor az informatika meg egy program használata és kiváltása egy másikkal leginkább csak hozzáállás és szemlélet kérdése. Azért, mert az IrfanView-t szoktad meg, meg lehet szokni mást is. Tényleg csak tanulási hajlandóság, hozzáállás. Volt idő, mikor én is ragaszkodtam ezekhez, foobar2000, Total Commander, Notepad++, stb., de gyorsan rájöttem, hogy nem éri meg, és váltottam végül olyan progikra, amik igazából sokkal jobbak, csak máshogy kell őket használni, át kellett alakítsam a felhasználási szokásaimat, de így hatékonyabb is, már semmi pénzért nem cserélném őket vissza a hagyományos windowsos megoldásra, óriási visszalépésnek érezném, mintha Commodore 64-et kéne használni. Ez a Linuxban a legfőbb lényeg, hogy teljesen más, mint a Windows, más programok, azok másképp is működnek már alapjaiban, máshogy használod velük a gépet. Ezeknek a windowsos programoknak a klónjai is csak azért léteznek, hogy amolyan pótkerékként segítsék a Linuxra most frissen átálló kezdőket, hogy ne legyen nekik nagy lelki törés a Linux. De végül ez csak illúzió, mert teljesen el kell rugaszkodni attól, hogy mi volt Windowson, mert amíg azt szoktad meg, addig az tűnik majd a legjobbnak, pont erre épít a MS is, hogy azt szokták meg az emberek és nem tudják elengedni, utána minden más szarnak fog tűnni. Én is tapasztaltam magamon, hogy nehéz olyan szokásokat elengedni, ami 20+ évig vele volt az emberrel, és már annyira természetes és ösztönből jön, mint pl. a jobbkezesség, hogy nem tudja elképzelni máshogy, pedig lehetséges.
-
Frawly
veterán
Ezt nem értem, mi ezen a jó. Ez még mindig nem natív linuxos XnView, hanem még mindig windowsos-Wine-os IrfanView. Így nincs értelme Linuxot használni. Pedig Linuxra is van számos jó képnéző és editor, feh, ImageMagick csomag display parancsa, GwenView, XnView, stb. Én régen még KDE-s korszakomban XnView-t és GwenView-t használtam, most jelenleg imv-t használok képnézésre, és ImageMagick csomag convert parancsát terminálból felparaméterezve képkonvertálásokra, az ImageMagick display parancsát fontok megjelenítésére. De az ImageMagick display még háttérképkezelőnek is jó, ha épp nem bugzik vele a kompozitor.
Így nem fogsz fejlődni, ha állandóan leragadsz a windowsos gondolkodásmódnál és windowsos programoknál. Pedig utóbbiaknak is szokott lenni mindig natív linuxos klónja, Notepad++-nak notepadqq, Winamp-nak QMMP vagy Audacious, foobar2000 helyett deadbeef, Total Commander helyett Double Commander, stb.. Gyakran segítenek ezek megtalálásában az alternativeto.net és hasonló oldalak, PH Linux programok topik, stb..
-
Frawly
veterán
válasz
Siriusb
#7632
üzenetére
Az a baj, hogy nagyon pontatlanul írod mit akarsz, és csak találgatni tudunk. A képernyőkímélő nem egyértelmű, mert nem tudom, hogy a kijelző energiatakarékos kikapcsolását érted alatta (ami igazából DPMS blank time) vagy tényleg a kalsszikus DOS/Win képernyővédőt (ún. screensaver, amikor a képernyőt nem kapcsolja ki, hanem mozgó grafikát jelenít meg).
Épp így a Lock screen / suspend esetében sem egyértelmű, hogy mire gondolsz.
Egyébként meg pont itt jön elő, amit írtam. Nálam ez e beállítás pálcika WM-en annyi, hogy egy autostart nevű Bash script fájlba beteszem a xset dpms 0 0 630 & tartalmú sort, és kikapcsol a screensaver és a screen blank is 10 perc 30 másodperc múlva. Nem kell vergődni, hogy melyik ikon, melyik menüjébe rejtették ezt a nyomorult beállítást.
Épp így a screensaver is így indul nálam, autostart fájlban újabb sor: xss-lock ~/scripts/screensaver-script & és ennyi. De épp ilyen egyszerűen definiálom a billkombókat, touchpad apró beállításait, tálca beállításait, szintén ebből a fájlból, 1-1 sor. Nem kell keresgetnem grafikus felületen, meg 500 kattintásból állítgatnom, hogy mi hol van, egyszer megírtam, 10+ évig működni fog, nem lesz az, hogy a KDE4, 5, 6 máshogy kezeli Qt4, Qt5, Qt6 alapokon, vagy máshogy kezelné a Gnome2 meg a Gnome3.x-4x. Nem mindig az a legfelhasználóbarátabb megoldás, ami annak látszik. Ráadásul ez az autostart megoldás memóriát sem foglal annyit, és rendszerújrahúzáskor csak visszamásolom, legtöbb X.org alatt futó pálcika WM eszi, de ha xinitrc-be behúzom, akkor az összes. Waylandes grafikus felület csak annyiban más, hogy ott az autostart részt be kell emelni a WM konfigfájljába, meg némileg módosítani, pl. SwayWM-nél:
exec swayidle timeout 600 '~/scripts/screensaver-script' timeout 660 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"'
Ez már bonyolultabb, de ezt is csak egyszer kellett kigugliznom és megírnom, soha többé nem kell keresgetnem semmit rajta, 10 perc múlva elindítja a screensavert (ami egy terminálban futó asciiquarium), +1 percre rá a képernyőt elsötétíti. Viszont ha újra gép elé ülök, akkor feloldódik a képernyősötétítés, de az i3lock és az alatta futó asciiquarium továbbra is fut, be kell írnom a jelszót, és akkor a screen lock is feloldódik. A +1 perces időeltolódás azért van, hogy ha véletlenül mégis a gép előtt lennék, és látom, hogy kilőtte a képernyőt, még gyorsan nyomok valamit, hogy ne zárolja a grafikus felületet, van egy kis plusz időm.Egyébként az óránkénti négy-ötszöri képernyőkikapcsolás nem árt a kijelzőnek. Az 1-10 másodpercenkéntnyi talán, a 12-15 percenkénti nem. Azt meg nagyon erősen ajánlom, hogy a képernyőt x inaktivitási idő miatt zárold, ha nem vagy gépnél. Igen, kényelmetlen a jelszót állandóan begépelgetni, de majd megszokod, és a te biztonságod szolgálja, és nem függeszt fel semmilyen futó folyamatot. Nagyon ajánlom akkor is, ha egyedül használod a gépet, vagy egyedül élsz, ha hirtelen ott kell hagyd a gépet, és valaki illetéktelen behatoló is jut be a gép közelébe, akkor sem tud a gépbe belematatni.
-
Frawly
veterán
Ez ilyen, ha nem vagy hajlandó utánanézni, és ilyen könnyen feladod, akkor tényleg nem tudsz a Mint-en átmozdulni. Ilyet még nem láttam, hogy másfél fehér cetlinyi. Mi nem volt jó, felbontás, nem volt háttérkép, nem volt ablaktéma, nem volt panel, vagy mi nem volt? Ezen a szinten, hogy csak „nem megy”, nem lehet mit kezdeni egy problémával.
Ne felejtsd el, hogy ez nem csak Archra igaz, pl. Fedorára meg Debianra felpattintasz egy Cinnamon full metacsomagot, akkor sem települ olyan fullosra, mint egy Mint. Hiszen lesznek dolgok, amiket neked kell telepítés után bekonfigurálni, kiegészítőleg telepíteni. A Mintet nem csak úgy csinálják, hogy fognak egy Ubuntut, és kiadják Cinnamont rátelepítve, hanem egy csomó konfigurációs, témaintegrálós, segédprogramot és scriptet, systemd service-t integrálós munkát tesznek bele, hogy teljesen laikusoknak is készre csiszolják, egy márkává. Ezek a grafikus felületek meg integrált alkalmazások egy nagyon komplex egységet alkotnak, sok apró elemből állnak, amit össze kell konfigurálni, témázni, reszelni. Nem csak Cinnamonnál, hanem minden más DE-nél és WM-nél. Nem véletlenül esznek ezek 500-1000 MB-tot kapásból a memóriából. A WM meg hiába eszik kevesebbet, azt még jobban össze kell konfigurálni, hogy egységes ökoszisztémát nyerj belőle.
Gnome-nál talán annyival jobb a helyzet, hogy kevésbé komplex egy Cinnamonhoz és KDE-hez képest, emiatt alap stock telepítésben is alig különbözik egy szénné reszelt formájától. Egyébként a KDE-vel is ez volt a gond, mindig is, deafult telepítésben sok embernek csúnya, kényelmetlen, sok reszelést és integrációt igényel, ami nem kis munka, de ezt kevés ember tanulta meg abszolválni, a legtöbb KDE-t is szállító disztrónak se szokott menni, alig 1-2 olyan disztró van, ami tényleg teljesre gyúrja a KDE élményt, valódi többletet tesz hozzá, nem csak egy stock default, alig konfigurált KDE-t húz fel (pl. Neon, Kubuntu, Manjaro KDE jobb KDE-élményt nyújt).
Arco-nál még azt is el tudom képzelni, hogy valami olyan postinstall scripttel húztad fel a Cinnamont, ami nem a teljes Cinnamon-infrastruktúrát telepíti, hanem csak a főbb Cinnamon egységeket. Ez KDE-nél is megint így van, hogy csak a kde metacsomagot/csomagcsoportot nem elég telepteni, kell hozzá a plasma-meta, plasma-desktop, plasma-wayland-session, kde-applications, stb. és még ezeket feltelepítve is még mindig ott vagy, hogy nem lesz olyan, mint egy Kubuntu, mert még neked kell panelt beállítani, témát feltenni, stb..
-
Frawly
veterán
Nem kötelező, meg ha már a Rebornt sikerült megcsinálnod magadnak, akkor használd azt, de ha legközelebb úgyis újratelepítenél, akkor adhatsz az ArcoD-nek egy esélyt. Magyarch-hoz hasonló, de nem magyar, és sokkal tisztább Arch. Le lehet tölteni sokféle grafikus felülettel, a full DE-s változatok a B-sek, a minimalistábbak a D-s lemezképek, utóbbiak általában soványabb WM-mel jönnek, de annak keretén belül használhatóra meg vannak csinálva, de még sincs mindenféle szemét előre beleintegrálva a rendszerbe, csak alaprendszert ad, észszerű alapbeállításokkal.
A nagyon fullosra összekészített disztrókkal meg általában ez a baj. Fent van rajtuk tenger sok csomag, amikre nincs szükséged, meg beleerőltetik a rendszerbe a saját hülyeségeiket, mint egy a Flatpak, Snap store, és társai, amiket úgy kell külön letiltogatni, meg kivakarni belőlük. Ugyananez Timeshift-re, Gnome-Seahorse kulcstartó, és egyéb baromságok. Ezeket „nem összerakott” disztróknál kapásból elkerülöd, nem utólag kell az ilyen szutykokat a rendszerből kigyomlálgatni. És az Arch itt jön a képbe, mert egy ilyen sincs, és idővel megtanulod ezeket kihagyni a rendszerből, rájössz, hogy ezek nélkül is meg lehet lenni, meg lehet lenni pl. GRUB nélkül is, nem hogy GRUB téma nélkül, LightDM és más login manager nélkül, sok minden egyéb nélkül, stb.. Ez az egésznek a lényege, nem az önszivatás, meg a terminálban gépeltetés, hanem érdemi pozitív hozadéka lesz, soványabb rendszer, nagyobb a kontrollod is felette.
-
Frawly
veterán
válasz
Archttila
#7594
üzenetére
Most is tetszik, egyedül a színek számát csökkenteném egy kicsit. De amúgy jól néz ki. Ezt az F2 + Space megoldást nem ismertem eddig htop-ban, nem hiába, minden nap tanul valamit az ember. Múltkor meg pl. a vim-ben a Ctrl+W-vel az egész szavanként visszatörlést mutatták egy videón, azelőtt meg hogy az imagemagick csomagban lévő display paranccsal lehet fontpreview-ra is használni. Mindig vannak trükkök, amiket nem ismert az ember, még akkor se, ha az adott csomagot évek óta használja.
-
Frawly
veterán
Az Archnak pont az a lényege, hogy nincs összeszerelve, mert eleve azzal a céllal készül, hogy te szereled össze magadnak, és nem próbálják előre kitalálni az igényeidet, meg eldönteni helyetted, hogy mi legyen feltelepítve, meg hogyan legyen konfigurálva. Ha valakinek arra van igénye, akkor Mint, Ubuntu, Fedora, stb., ott minden fel van telepítve, legcsilivilibbra bekonfigurálva, de magával hoz ez egy nagy rakás felesleges csomagot, és bloatot is.
Ha WM-mel telepíted, akkor persze, hogy nehezebb, de ez megint nem az Arch miatt van, hanem a WM-ek önmagukban minimalistábbak, csak ablakkezelést tudnak, se asztali ikon, se tálca (ritka), se témát nem tartalmaznak, se launcher, se háttérképkezelés, stb.. Ott mindenről neked kell gondoskodni, ez Archtól független, így van egy Debian minimal installnál is.
De mint mondtam, egy tiszta Archot feltenni nem nagy szám, ha csak sima titkosítatlan partíciókra teszed fel GRUB-bal, meg egy olyan fullos WM-mel, mint a Cinnamon. Igaz még ekkor sem lesz minden bekonfigurálva, csak olyan 99,99%-ra, néhány extra témát, magyar nyelvi csomagokat, tálcaappletet neked kell kézzel tölteni meg beállítani, de az már nem olyan nagy munka, ha már tudod mit akarsz, ismered mi kell neked.
Mindenki máshogy használja a gépet. Ez az eltérő felhasználás meg más csomagokat igényel, más konfigokat. Te pl. magyarul használod a rendszert, meg fullos DE, csak GUI-s programok, stb.. Én meg pl. eleve nem magyarítom a rendszer, default en_US.UTF-8-cal használom, ez sokkal célszerűbb, nem kell magyar nyelvi csomagozni, nem maradnak lefordítatlan, félig fordított, félrefordított részek, plusz a magyarítás le szokott maradni ütemben a legújabb verziókhoz képest. Meg ha angolul használod a rendszert, és valami probléma, hibaüzenet van, akkor könnyebb utánakeresni a neten, hogy mi a megoldás, magyar hibaüzenetre kb. milliószor kevesebb találat lesz. Tudom, erre azt mondod, hogy angol a rendszer is angol. Igen, az, de ez nem probléma, mert úgyis készségszinten használod a rendszert, ikonokra, menükre kattintasz reflexből, megszokásból, és nem olvasod el, hogy mi van kiírva, meg az angol nyelvű menük és üzenetek elsöprő része nem igényel hú de magas szintű angolt, most azon, hogy File, Edit, Print, Search, Install, couldn't download package, beazonosítani egy Firefox, Chrome ikont csak meg lehet érteni a legprimitívebb, turistszintű angollal is, nem kell hozzá felsőfokú, meg társalgási szintű királynői angol. Nagyrészt meg lehet ezeket fejteni pár másodperc alatt, akkor is, ha valaki németes meg oroszos volt iskolában, és alapból idegen nyelvi antitalentum. Egyszerűen csak némi megszokást igényel. Sőt, még olyan előnye is van az angol hibaüzeneteknek, hogy mivel nehezebben olvasod, csökken az esélye, hogy könnyelműen kattintgatsz a next-next-ok-finish-re, hanem figyelmesebben elolvasod az üzenetet, jobban meggondolod, hogy mit reagálsz rá, ez sokszor még kamatozhat is. És attól, hogy a rendszer angol, attól még a billkiosztás beállítható alapértelmezetten magyarra, az UTF-8 beállítás miatt a magyar ékezetes és speciális karakterek is hibátlanul megjelennek alapból, átátllítható a dátum/időformátum magyarosabbra, tizedesvessző a tizedespont helyett, stb.. A weben is minden továbbra is magyarul fog „előjönni”, IP-d alapján, meg a böngészőben és egyéb progikban is be lehet lőni a magyar helyesírás-ellenőrzést, stb.. Tehát még a magyarságot se kell feladni hozzá, csupán a rendszerben és szoftverekben az ikoncímkék, menük, üzenetek nem lesznek magyarok, ennyi csupán, simán megszokható, de sok gondtól kapásból megkímél.
Ugyanez van ilyen WM-es rendszereknél is. Ja, nehezebb beállítani, mindenféle konfigfájlt szerkeszteni, csomagot kézzel feltenni. De! Ezt csak egyszer kell megcsinálni, ha kész van, akkor el lehet menteni ezeket a .conf fájlokat, meg a csomaglistát, és legközelebbi újratelepítéskor csak átadod a csomagkezelőnek a csomaglistát, felhúzza a csomagokat, meg az új home mappádba visszamásolod a configfájokat, és nem kell semmit állítgatni grafikus felületen mindenféle beállítóablakban, minden egyes installkor. Tehát ami elbuksz az egyszeri nehezebb telepítésen, azt később kamatostól visszanyered.
-
Frawly
veterán
válasz
Archttila
#7586
üzenetére
BUÉK mindenkibe!
Nekem kicsit túl színes, de összességében jól néz ki. htopban ezt a digitális szegmenses-betűtípusos dátum/időkijelzést hogy állítottad be?
Egyébként az se annyira rossz rendszer, amit a másik screenshoton mutatsz, Awesome + Geany, végül is komplett rendszer, futó programmal, mindössze 282 MB fogyasztás. Nem olyan rossz az. Jó, annyira nem haladó, de már egy nem is annyira kezdő, bloattenger valami, egész használható.
Azért 3 hónap alatt sok fejlődés, de nem lehet siettetni, ez egy fokozatos folyamat, megy előre magától majd a további hónapokkal, évekkel, és formálja a szemléleted és a készségeid. Ezt nem értették sokan az OFF topikban, hogy ehhez a minimalizmusos, ultrahaladós témába senki nem született bele, mindenki fokozatosan jut el oda.
#7591 csixy: Rebornhoz nem értek. Próbáld meg legközelebb az Arco Linuxot, abból is valami D-s változatot, az sokkal közelebb van a tiszta Archhoz, nem használ elvileg saját tárolót. De a tiszta Archot se egy nagy szám feltelepíteni, ha nem bonyolítod, nem kell LVM, LUKS, RAID, SELinux meg hasonló huszárkodások, akkor elég könnyű megtanulni. Főleg, ha komplett asztali környezettel telepíted, ami minden szükséges dolgot behúz függőségnek.
GRUB témát én a /boot/grub.cfg-ben keresném, hogy mi a neve.
-
Frawly
veterán
válasz
Archttila
#7578
üzenetére
Hardcore-ban toljátok a disztróhűséget
Persze ilyen btw I use Arch szerelést csak úgy szabad felvenni, hogy lenyiratkoztok kopaszra, mint Luke Smith vagy Derek DistroTube / Dubya for y'all Taylor Meg ubyegonnak nem szabad mutatni, mert akkor nekiáll ő is minteset rendelni, vagy elküld gólyafészket nézni. -
Frawly
veterán
válasz
Archttila
#7559
üzenetére
Megint csak azt tudom írni, hogy ez van. Nem kinőtted, hanem a Pi nem erre való, hogy gigabites netet kihajtva egyszerre három 120 gigás torrentet húzgálj, meg desktopnak is használd, meg Chrome/Brave zabálja le az erőforrásait. Azért mindenképp próbáld meg 64 bitessel. Valószínű azon több minden le fog fordulni eleve, de szerintem desktopnak, meg nagy ívű torrentezésre az se lesz jó. Az ARM mobil proci, nem dekstop. A buszai is úgy lettek kitalálva, hogy USB-alapúak és lassúak. Ez a Pi is mikroszervernek és mikrokontrollernek lett kitalálva, nem rendes, nagy sávszélességű letöltőszervernek meg desktopnak.
-
-
Frawly
veterán
válasz
Shyciii
#7551
üzenetére
Ja, lehet így is. De pár gondolat: a csomagtömörítéshez szerintem nem éri meg nyúlni. Mindegy mivel tömöríti a kész csomagot, nem okoz túl nagy többletidőt, és csak egyszer települ a lefordított cucc, mikor újratelepítené az ember, akkor az úgyis frissítéskor lesz, de akkor meg úgyis újra kell forgatni.
Másrészt ez a -j2 meg -kAKÁRMENNYI is elég félmegoldás, mert ezek azokon a csomagokon segítenek, amelyek gcc-vel, g++-szal + make/make scripttel fordulnak, de egy csomó csomag van, ami Ruby, Go-val fordul, vagy C/C++-os ugyan, de ilyen meson, ninja, stb. projektfordítást használ, azok elvileg ezt a make -j kapcsolót nagy ívben figyelmen kívül hagyják.
-
Frawly
veterán
Jön a pacman 6.0-ba a párhuzamos csomagletöltés. Egyelőre alfa, nem tudom mikor jelenik meg. A legenda úgy tartja, hogy ezt a feature-t majd az ubuntusok is megkapják azt apt-ba, majd 2099-ben, addigra corporate grade stabilitású LTS lesz. A zstd csomagtömörítésre nem kell ennyit várni, az 2020-ba érkezett az Archba, Ubuntuba meg 2098-ban.
Ezt már rég mondtam, hogy bevezethetnék, mármint a párhuzamos csomagletöltést. Nagyon ideje volt már.
-
-
Frawly
veterán
A szerver tág kategória, nagyban függ, hogy mit csinál, hány gépet szolgál ki. A 10 GB-os fogyasztás is relatív, mi eszi, milyen formában, mennyi a shared, mennyi a cache/buffer, stb.. Mert pl. a ZFS tudja enni rendesen a memóriát, de általában cache meg stb. formájában.
Laptopnál sincs szükség feltétlenül hibernálásra, lehet menteni is, ha merül az akku. Ez a hibernálás egy régről maradt valami, mikor még lassan bootoltak HDD-ről a gépek, és muszáj volt valami megoldást kitalálni, hogy ne kelljen minden gépindítást végigvárni. Egyébként a hibernálás az egyik nagy gyenge pontja a Linuxnak.
@sati: ejha, bátor vagy, Rpi4-en Chromiumot forgatni. Legcombosabb, 16 magos gépeken is min. fél óra, de átlag régi üzleti notin simán megvan 8-12 óra is. Persze a FF forgatása se sokkal röpkébb, hatalmas, több gigás kódbázisa van ezeknek. Egyszerűen horror bloatak.
-
Frawly
veterán
Igen, ezt jó is hogy írod, ha kell hibernálás, akkor kell swap, és ráadásul akkor a méretének is el kell érnie legalább a fizikai RAM mennyiségét. Ez az egy eset, amikor valóban indokolt a swap, de én nem ajánlom a hibernálást sem, a legtöbb hardveren a legtöbb disztró kernel vagy nem tud visszajönni hibernálásból, vagy csak bugokkal, meg ma már pár másodperc alatt bootoló SSD-kel nincs az egésznek sok haszna. Ezt mindenkinek magának kell eldöntenie, hogy tényleg kell-e hibernálás, és az mekkora plusz áldozatot hajlandó fizetni ezért.
-
Frawly
veterán
válasz
anorche1
#7539
üzenetére
Igen, swapnak mindig is az volt a haszna, ha elfogy a memória, akkor se menjen le hídba a rendszer, hanem kilapozza a memóriát lemezre, és legyen újra valamennyi szabad memória. Nagyban függ attól, hogy jelenleg mennyi memória van a gépedben, meg mi a felhasználásod. Ezt neked kell nézni, gyakran előszedsz egy feladatkezelő-jellegű progit, megnézed, hogy mennyit használ a swap-ból, mennyi szabad a RAM-ból, ha bőven van mindig szabad memóriád, és a swapot vagy nem használja a rendszer, vagy csak kicsit, akkor neked nem fog kelleni. Kb. 4 GB RAM-ig van rá szükség. 8 GB határeset, felhasználásfüggő, pl. a futtatom a Chrome-ot 1000+ füllel és mellette állnak az Electron app hegyek és megnyitott komplett LibreOffice és hasonló bloat dolgok, akkor lehet még 8 gigához is kell. Ha viszont van 12-16 giga RAM-od, vagy csak 8, de minimalistább Linux rendszert használsz (csak egy WM, meg pehelysúlyúbb alkalmazások, mint Firefox, mpv, stb.), akkor átlag felhasználás mellett nem nagyon kell swap. Ezt csak ökölszabálynak írom, nem mindenkire igaz, ezt neked kell ellenőrizni.
Én 8-16 GB RAM-nál már Windowsban is mindig kikapcsoltam. Ja, rinyál, hogy nem kéne, de utána beveszi, és még sose hiányzott. Bár Windowsnál azért kell jobban, mert annak szarabb a memóriakezelése, kevésbé hatékonyan ossza be a memóriát, az jobban töredezik (ki nem használt memórialap tartományok ékelődnek kihasználtak közé), de nem kötelező, ott is meg lehet nélküle lenni. Nagyban függ, hogy ki mennyi programot futtat egyszerre, miket telepít és futtat, mennyire lusta bezárni futó dolgokat, és hogy mire használja a gépet.
-
Frawly
veterán
Olyan nálam vagy már 10 éve nincs, hogy csak egy gép van (jó, 5 éve volt egy átmeneti, pár hónapos időszak, mikor 0-1 gépem volt csak, de ettől tekintsünk el, akkor nem a csomagcache volt amúgy sem a legnagyobb gondom). Kb. 4 éve van vagy három. És mint mondtam, nem volt belőle soha gondom, hogy valami régebbi csomagverzió nem volt meg. Nem is azt mondtam, hogy mindenkinek így kell csinálnia, ahogy én oldottam meg, csak ez is egy alternatíva, ha valaki lusta állandóan cache-t ürítgetni, és nem akarja, hogy beteljen emiatt a root partíció.
Tényleg nálam 99,999999999%-ban teljesen felesleges a csomagcache, nem szokott gondom lenni frissítéssel, most tegyem el az unokáknak a tar.zst csomagokat? Én ugyanúgy kezelem, ahogy a böngészőcache-t is. Csak rövid ideig kell, felesleges felvésni egy non volatile háttértárra. Persze aki csomagmúzeumot akar nyitni, annak hajrá, főleg rollingon van értelme régi csomagverziókat őrizni, mikor úgyis naponta-kétnaponta jön helyette az újabb verzió. Persze azt elismerem, hogy néha segítség lehet, ha mégis megvan egy problémás csomagból az egyel régebbi verzió, de ennek a tényleges gyakorlati haszna annyira ritka, hogy döntse el mindenki maga, hogy neki ez a biztonsági fogodzó a növekvő helyigénnyel megéri-e. Aki mondjuk 2-4 terás háttértárakon használ OS-t, annak lehet valóban mindegy, főleg, ha HDD.
Egyébként sokan a swap-pal is így vannak. Jajj, mert állítóleg kell, mert a disztrókészítők szerint kell. Közben meg valóban kell, szökőévente lehet egyszer, de csinálgassunk neki egy külön partíciót. Nagy büdös lófütyköst, ha majd mégis kell, akkor csinálok magamnak:
dd if=/dev/zero of=/akármi/swapfile bs=xG count=1 && mkswap /akármi/swapfile && sudo swapon segítségével.YouTube videókon is gyakran kuncogok, hogy ott figyel a jómunkásember gépében a 32-64 giga RAM (!), aztán ott motyok, hogy jajj, a swap, mindjárt partíció formájában, az kell, mint egy falat kenyér, merajánlottttötö. Meraszongyákkő. Valakik írták valami 30 éves cikkben, hogy a fizikai memória kétszerese!!!!!!!! De legyen inkább háromszorosa, biztos, ami biztos. Közben meg nekem 8-16 GB RAM-nál sem kellett soha, jó, 8 giga RAM-nál szökőévente ha belenyalt a rendszer a swapba, 16-nál már az se.
-
Frawly
veterán
válasz
Siriusb
#7521
üzenetére
Én meg speciális scripttel frissítek, ami a pacmant úgy hívja meg, hogy tmpfs ramdrive-ra tölti a csomagokat. Így nem gyűlik be a csomagcache, eddig a sok éves archozás alatt egyszer fordult elő, hogy egyel régebbi csomagverziót kellett feltenni. Korábban volt nekem is, hogy majdnem 10 GB-ra hízott a pacman cache. Utána elkezdtem kézzel takarítgatni a pacman -Scc kiadásával, de aztán ráuntam.
-
Frawly
veterán
válasz
anorche1
#7506
üzenetére
Ezzel nem kell foglalkozni. Még 10 évvel ezelőttről benne maradt ez a debug üzenet az mkinitcpio scriptben, és mindenkinek kiírogatja ezt. Ha nem használod ezt a felsorolt 3 hardvert konkrétan, akkor hagyd figyelmen kívül.
#7509 Siriusb: ilyet néha nálam is csinál, mármint nem a KDE, hanem mindenféle disztró, mindenféle felülettel, meg androidos telóval is. Ilyenkor néha a router nem tudja újraépíteni a WAN kapcsolatot, és azért érzi úgy, hogy bejelentkezés kéne. Vagy indítsd újra a routert, vagy a webes felületére lépj be.
-
Frawly
veterán
válasz
Shyciii
#7500
üzenetére
Pedig a Qt-s progik szerintem nem rosszak. Bloatak, de a bloat műfajban szerintem még a legjobbak, legnagyobb tudásúak. KDE-t rég nem használtam. Természetesen ez az előnye egy pálcika WM-nek, szög egyszerű, nincsenek moduljai, függősége, nincs ami eltörjön rajta. Launcher ott is van, de egy dmenu vagy Rofi nagyságrendekkel egyszerűbb, mint egy Krunner. Megint, kevesebb függőség, kisebb és átláthatóbb kód, gyorsabban fut, frissítéskor is kevesebb csomag frissül miatta. Konfigurálásuk is egyszerűbb, mert csak egy szem .conf fájl, azzal egyszer megküzd az ember, aztán egy olyan 10 évig nem kell hozzányúlni, csak a konfigfájlt visszahúzogatni, és nem kell mindenféle grafikus menükben 100-at kattintgatni minden egyes reinstall után.
-
-
Frawly
veterán
válasz
Archttila
#7487
üzenetére
Ez annyira nem rossz. Jó, egy szem 6,7 gigás torrenthez kicsit sok, de még nem annyira túlzóan, hogy az ember agya a láncot ledobja. Ha ez így jól megy, akkor hagyjad. Egyik torrentkliens sem sovány, mindegyik jól megeszi a memóriát, meg ha gigabiten töltesz le, akkor a CPU-t is, ezzel nem tudsz mit csinálni, minimalizmus ide, nem bloatság oda. Egyszerűen maga a torrent protokoll bloat, főleg ha sok mindenkitől töltesz le sok mindent, megy-jön a sok fájlszelet, ellenőrző összeg, hibajavítás, prioritáskezelés, stb., ez mind viszi a sávszélt, memóriát, procit.
A Chrome-alapú böngészők meg valóban gyorsabbak, mint a FF, de nem a Wayland miatt, mert az FF-on is bekapcsolható, hanem a rendermotorjuk gyorsabb. Cserében viszont a Google hatalma nő általuk, hogy már szinte minden böngészőt a Blink/Chrome motor hajt, másrészt ez a motor a teljesítményre van kihegyezve, de cserébe nem nagyon lehet semmit állítgatni rajta, addon is kevesebb van hozzá. FF-ot sokkal részletesebben testre lehet szabni, több a jó addon hozzá, illetve ha ezt használod, akkor a Google hatalmát csökkented, plusz a FF kevesebb memóriát is eszik, cserébe 1-1 oldal renderelése kicsit lassabb, nem vészes, pár ms.
#7488 Shyciii: nem azt mondom, hogy friss, mert tényleg régi a 83-as, de annyira nem elavult, mintha mondjuk egy 60-70-es verzióról beszélnénk, azért még minden weboldalt meg webalkalmazást lerenderel, meg mindenféle addont támogat. Arra a felhasználásra, ami te írtál elég. Meg Debian- és Ubuntu-vonal alatt azért sem gond, mert ott külső tárolóként hozzá lehet adni a Google-nek a Chrome-tárolóját, vagy kézzel, a Google oldaláról letöltve a .deb csomagot, dpkg -i segítségével telepíteni.
Félre ne érts, én nem támogatom amúgy a régi verziók használatát. Azért is szoktam minden topikban leírni a rolling frissességének mindenhatóságát, és szoktam is javasolni, hogy aki mesa, GPU driver, Steam, Proton, Wine, stb. frissességével küzd, az ne szenvedjen Ubuntu-vonalon, meg LTS-ezzen, hanem tegyen fel normális full rolling disztrót, ha nem tudja telepíteni az Archot, akkor ArcoLinux vagy Manjaro formájában, de azt használja, nem kell többé Obeiöfböff PPA-zni, meg dependency-kkel kínlódni, hogy ne dinoszauruszok korabeli verziókon ragadjon az ember. Persze emiatt le is szoktak tolni, hogy mit képzelek én, túl nagy az Arch-om, meg az Arch instábillll, meg nem server/corporate grade, nem LTS, nincs hozzá rendes support, stb.. Ja, ezek egyike se, de nem kell vele szenvedni, mert minden simán fog rajta menni, a legújabb verziók is, legújabb hardverek, nem kell nonfree tárolókkal vergődni külön, disztrófrissítésekkel kockáztatni, hogy most vagy sikerült, vagy nem, nem ragad az ember régi verziókon.
Ha lenne RPi4-em, akkor sem PiOS-t tennék rá, meg ARM-es Debian, Ubuntu valamelyikét, hanem min. Arch ARM-et, ahogy a fenti kolléga is használja.
-
Frawly
veterán
Igen, megvan, de ettől még baromság, és emberek hajlamosak komolyan venni, hogy így történt. Egyébként kár érte, mert mint írtam, rendezésében, ebben-abban nem lenne pedig rossz, ha nem ilyen ikonikus témát dogoz fel, talán végig is nézem. Mert az pl. hátborzongatóan élethű, ahogy az akkori életet ábrázolja, szocialista panellakótelepek, szoci neomodern dizájnos művházak, ipari létesítmények, még politikai vonulatot is jól mutatja be, mindenféle párbizottság, tanácsülések, szocialista szólamok, szobák dekorációja, berendézes, szoci kárpitos bútorok. Ez mondjuk csak annak tűnik fel, aki van elég idős, és még élt abban a korban. Ha egy mai fiatal nézi, vagy valaki nyugati emberke, aki ebben sose élt, szerintem annak csak szimplán fura és unalmas lesz.
-
Frawly
veterán
válasz
Shyciii
#7480
üzenetére
Általában én vagyok, aki a Debiant ekézni szoktam (az RPiOS is az, egy ARM Debian), meg én vagyok a legfrissességmániásabb a topikban, de szerintem a Chromium 83 még nem olyan elavult. Jó, nem valami friss, azt aláírom, én nem is tennék fel magamak ilyet, minimum Arch ARM-mel próbálkoznék, de ha backportolták benne a security patch-eket, akkor azért használható, főleg ilyen embedded céges vagy ipari környezetben elég, ha csak operátornak annyira kell, hogy kioszk rendszerben egy darab webes alkalmazással tudjon dolgozni a böngészőben.
-
Frawly
veterán
válasz
Archttila
#7479
üzenetére
Nekem ezek a számok nem tűnnek rossznak, szerintem nem annyira brutál memófoglalás. Az is igaz, hogy nem mutattál free -m kimenetet (látszódjon a shared, cache is), meg azt se értem, hogy a htop-ban a RPi4 memóriájából miért csak 3,3 GB látszik, mikor 4-nek kell lennie? Nem 32 bites rendszert futtatsz 64 bites helyett? Mert a 32 bit megmagyarázná a korábbi forráskódból forgatási problémáidat is. Vagy 64 bites az, és az RPi integrált GPU-ja vesz le a rendszermemóriából. Bár memóriád így is van szabadon, a háttérben fut minden, komplett grafikus felület, terminálok, progik, MiniDLNA, torrent, stb., ahhoz képest nem valami sok a 438 MB-os fogalás, majdnem 3 GB szabad memória van, ilyen felállásban én nem sok értelmét látom a swapnak. Bár betehetsz, de akkor arra figyelj, hogy még véletlen se HDD-ről fusson, meg SD kártyáról, meg eMMC tárolóról, hanem rendes SSD legyen alatta. Nem baj, ha csak valami olcsó, SATA3-as szutyok, de rendes desktop vagy M.2 SATA vagy hasonló SSD legyen.
Gigabites net kihajtásának ez az ára egyébként, ha tényleg több szálon van hajtva, akkor meg is van, hogy az rtorrent-nek is miért volt magas a CPU használata. A több szálas gigabites torrent már sokat tud enni egy szabvány windowsos PC-n is, mind memóriából, mind prociból.
Ez a Chernobyl sorozat szerintem nem valami jó, bár azt se értem, hogy egy Trinity-kiadásnak hogyan lehet epizódonként 25 gigás mérete, még 4K-ban sem kéne annyit foglalnia. Én is elkezdtem nézni ezt a Chernobylt (épp így talán Trinity Blu-Ray 1080p-s felbontás), és ugyan pl. a korszak jól van benne ábrázolva, emberek, épületek, ruhák, stb., de az egész történet el van torzítva benne, szakmai helytelenségekkel, meg csak marék szereplővel dolgozik, mintha csak azok vettek volna részt mindenben. Az egész annyira el van rugaszkodva a valóságtól, hogy szerintem időpazarlás megnézni.
A linkeden a faszinak a gondját meg szerintem nem bug okozza, hanem a külső HDD-je haldoklik vagy nem kap elég delejt, mert valami ócska kínai táppal hajtja, vagy nem aggat rá külön tápot, az USB foglalatból meg nem tud elég naftát felvenni.
-
Frawly
veterán
válasz
Archttila
#7468
üzenetére
Kíváncsi vagyok mit fog mondani a fejlesztő. Nálam 1 giga felett evett, csak az rtorrent magában, igaz ebben a cache is benne van, már nem is emlékszem mennyi. De csak 4 torrent volt a kliensben, abból is csak 1 volt aktív, töltött le, alig pár GB terjedelemben. A neten is panaszkodnak, hogy sok memóriát eszik. Nagy procihasználatra nem emlékszem, igaz én anno i5-2520M és i7-2720M-es procikon próbáltam, amik szintén nem erőművek ma már, de egy RPi4-nél azért sokkal erősebbek.
A nagy memófogyasztást nem is annyira rovom fel, mert a qBittorrent sem keveset evett, igaz abba is bele volt számolva a saját lemezcache, meg a nagy memóriahasználatért cserében elég sok funkciót nyújtott. Végül nem is az erőforrás-használata miatt dobtam, hanem már vagy harmadszor fordult elő az évek során, hogy a qB-es fejlesztők képtelenek voltak annak a libtorrent-rasterbar libnek a változásait, fejlesztéseit lekövetni, amire a kliensük épül, ebből lett elegem. Egyszerűen a hozzáállásuk csapnivaló, lusták. Pedig amúgy a legjobb torrentkliens lenne.
Én végül transmission-cli-ra tértem át, ennek memóhasználata jóval kevesebb, rtorrentnél többet tud, procihasználata sincs nagyon. Főleg webes klienssel használom, de néha terminálból is tremc-vel. Nem egy nagy szám, nem tud sokat, de nekem elég.
-
-
Frawly
veterán
válasz
anorche1
#7460
üzenetére
Octopi-t sose használtam. Ha találgatnom kéne, akkor terminálból megkap valami parancssori opciót, amit a dmenu nem nyújt neki, és ennek hiányában nem fut. Terminálból is csak így egymagában hívod meg, egy parancsként, semmi kapcsoló mögötte? Esetleg terminálból indítva a megfelelő jogosultsággal indul, míg dmenu-ből indulva nem.Pamac nem jó helyette? Vagy a terminálos octopi parancsra csinálsz egy gyorsbillentyűt?
Ahogy olvasom, a PCmanFM-qt-ben nem lehet letiltani ezt a smooth scrollt. KDE alatt le lehet, de ebben a fájlkezelőben nem. Ez elég ostoba volt részükről, beletenni egy megkérdőjelezhető feature-t, és nem kikapcsolhatóvá tenni. Pedig nem is azért írtam, mert LXQt alatt bele fogsz futni, erről a smooth scrollingról még a KDE kapcsán tettem csak említést.
Egyébként ha nem ragaszkodsz az egész Qt-ökoszisztémához, akkor lehet az LXQt alapjául szolgáló Openbox-ot is futtatni, picom kompozitorral (és mondjuk tin2 vagy polybar panellel), és Gtk3 alkalmazásokkal, pl. a PCmanFM-nek van Gtk-s változata, abban nincs smooth scrolling.
Eset
-
Frawly
veterán
válasz
anorche1
#7457
üzenetére
Az LXQt sem rossz, esetleg Openbox. Képernyő fényerejét többféleképp is le lehet venni 0-ra, vagy xbacklight vagy hasonló backlight alkalmazással 0 fényerőt megadni paraméternek (lásd man), vagy kiadni a xset dpms force off parancsot, vagy ezt hozzárendelni egy billentyűhöz.
A minimalistább WM-ek csicsásításához pedig picom kompozitort érdemes használni, ami tud vsyncet, átlátszóságot, átlátszó elmosottságot, árnyékokat, ki/behalványodási effektet, ár az LXQt-nek lehet van saját beépített kompozitora, mert az nem csak egy WM, hanem egy komplett DE.
-
Frawly
veterán
válasz
anorche1
#7452
üzenetére
Animációkat javaslom akkor is kivenni, ha szereted a csilivilit, mert lassítják a grafikus felület reakcióidejét. Nem a hardverigény növelése miatt, vagyis nem csak amiatt, hanem mert az animációs időt mindegy milyen kicsi értékre veszed le, valamekkora lagot okozni fog. Egy kis wobbly windows meg leállási anim effekt belefér, de pl. programok megnyitásánál, bezárásánál, váltásánál, meg a dokknál, menüknél, alkalmazásindítóknál nem éri meg használni. Jelenleg az Openbox + picom kompozitor is tudna pl. fade effekteket, de kikapcsoltam, mert mikor hirtelen alkalmazást vagy desktopot váltok, akkor nem volt azonnali a váltás.
Ugyanez a helyzet a simított görgetéssel, néhány progi azt is tudja, hogy ha darabonként görgetsz, akkor is lagot okozva, kicsit tovább, lassítva görgeti a tartalmat, és a darabos görgetési mozgások kiegyenlítődjenek, de ez meg idegesítő, mikor hosszú doksiban pozicionál az ember, és szeretne azonnal a doksi egy adott részére ugrani, és ez a csilivili effekt megnöveli a reakcióidőt.
-
Frawly
veterán
válasz
vargalex
#7442
üzenetére
A queque-d (NCQ) TRIM és annak tiltott állapota nem függ attól, hogy discard vagy fstrim-mel van-e hasznával. Az NCQ vs. nem-NCQ TRIM épp úgy megy mindkét megoldással párosítva. Plusz a kernel ATA quequed TRIM blacklistjén lévő SSD-k elég régiek, már kapni sem lehet nagyon őket, nem valószínű, hogy valaki belefut modern rendszeren.
A Dolphin-ra nem tudok mit mondani, ezek szerint tudja (bár ha fájlokról van szó, nem mappákról, akkor én nem vagyok benne biztos, hogy akkor is menni fog neki), csak locale probléma volt. Nekem eddig ezt a fajta rendezést egyik fájlkezelő se tudta (még a fájlkezelők non plus ultrája, a Total Commander se), egyik OS alatt se. Igaz nagyon korán, még a DOS-os időkben ráálltam, hogy bevezető 0-kkal toldom meg, mert úgy minden alatt működik. Meg szerintem doksiknak, mappáknak nem is a legjobb ilyen "1" és "10" nevet adni, mert visszanézi az ember pár hónap, pár év múlva, hogy az ilyen pöcs nevű fájlokról, mappákról fogalma sem lesz, hogy mi a rákra szolgáltak, egyenként meg kell nyitogatni, vagy valami view-er programmal átmenni rajtuk. Ehelyett célszerű rendes beszédes nevet adni mindennek, rendesen kiírva, ez már nem CP/M, DOS, meg FAT12-16, hogy 2-8 karakteres nevekbe kell beleférni. És a hosszú, beszédes fájlnév, mappanév még akkor se probléma, ha valaki CLI-ből használja a rendszer, terminálból, konzolból, SSH-ból, mert a Tab-os kiegészítés ilyenkor is kiegészíti őket 2-3 karakter bevitele alapján, nem kell az embernek a körmét legépelni.
Fájloknál arra is törekszek, hogy mindig legyen valami értelmes kiterjesztés, akkor is, ha Linuxon nem szokott számítani (nincs is kiterjesztés, az a név része), hogy mi a kiterjesztés. Pl. valaki itt nemrég leszólt, hogy a pain text, nem forráskódos fájloknak .txt kiterjesztést adok, mikor az felesleges, meg windowos berögződés. És ez a két utóbbi érv igaz is, én akkor is szeretem látni a kiterjesztést, mert később, évek múltán is látni fogom külön megnyitogatás nélkül, hogy mi volt benne, és nem tévesztem össze kiterjesztés nélküli shell scriptekkel, binárisokkal. De tőlem lehet .text vagy .doksi vagy .szöveg vagy akármi, csak kiderüljön micsoda, és ne legyen összetéveszthető más tartalommal, pl. plain text fájlnál .doc kiterjesztés nem jó, mert arról azt gondolhatja később valaki, hogy még a docx előtti időkből származó MS Word doksi, és a .tex kiterjesztés is megtévesztő, mert az meg a *TeX/*LaTeX forrásfájlok kiterjesztése.
-
Frawly
veterán
válasz
anorche1
#7423
üzenetére
Beleteheted a discardot, ha akarod. A kolléga félig írta csak jól, Archon van fstrim systemd service, azzal is működőképes (ilyenkor nem kell discard), de figyelni kell, hogy alapból az sincs bekapcsolva, neked kell systemctl enable fstrim segítségével bekapcsolni, részletekért lásd a belinkelt Arch Wiki cikket. Tehát vagy-vagy módszer, rád van bízva melyik szimpatikus, melyiket használod, discard mount opció vagy fstrim service. Az SSD TRIM-ezését bármelyik megcsinálja normálisan. Mindegy melyiket választod, elég annak futnia, nem kell a kettő párhuzamosan.
#7423 anorche1: rossz hírem van, ezt nem tudja. Még a Delphinnél sokkal komolyabb fájlkezelők sem, mint a Double Commander Qt, vagy Krusader vagy hasonló kétpaneles fájlkezelők, amiket mégis élből jobban ajánlok. Ha zavar ez a rendezési mód, át kell nevezned az 1 nevű fájlokat 01-re, a 2-es nevű fájlt 02-re, erre vannak tömeges átnevezési módszerek regexp alaján, szintén lásd pl. Double Commander. Én erre Vifm + vim megoldást használok, de lehetne shell scriptet is írni, ami ls | grep | mv segítségével nevezi át.
-
Frawly
veterán
válasz
anorche1
#7421
üzenetére
Ja, feltűnően gyors, a jóhoz meg könnyű hozzászokni. Meg frissebb is, mint a Manjaro, ez is előnye. Pedig a Manjaro is relatíve új verziós csomagokat használ a disztrók többségéhez képest, meg nem olyan lassú, főleg, ha pl. Debian/Ubuntu-alapú disztrókkal hasonlítod össze. Pl. a pacman már régóta a leggyorsabb csomagkezelő (pl. a függőségi fát is nagyon villámgyorsan állítja össze a többi csomagkezelőhöz képest), de mióta zstd-csomagtömörítésre álltak át, azóta meg valami hihetetlen dimenzióban veri az összes többit. Főleg mikor mutatod Windows usereknek, hogy Archon mennyi egy terminálos pacmanos rendszerfrissítés (átlagos, de nagyobb), kb. 1-2 perc (jó, netsebességtől függ), abból a letöltést leszámítva a tényleges telepítési idő kb. 5-10 mp. SSD-n, nem hiszik el, mert ugyanez Windowson tart SSD-vel is 10-30 percig, mármint egy hasonló kaliberű frissítés.
A pacmant jelenleg csak az inteles Clear Linux csomagkezelője veri sebességben, de az csal, nem egész csomagokat tölt le és telepít, hanem csak a csomagok közötti deltát, különbségeket tölti le, telepíti, így nagyságrenddekkel kevesebb adatot kell megmozgatnia, eleve letölteni is sokkal kevesebb, és ez utóbbi a szűk keresztmetszet.
Pont tegnap este olvastam egy másik fórumot, hogy az userek mint szenvednek egy nem is olyan új Ryzen mobil APU-ba épített AMD IGP driverrel (meg itt ezen a fórumon is egy régi AMD R9 GPU-val), Ubuntu meg Debian alatt, mindenféle PPA-kal, meg backports kernellel vergődnek, Arch-alapú disztrón meg minden alapból van annyira friss, hogy ez nem gond (simán megy DXVK, Proton, stb.), meg a forráskódból pörgetés sem, mert rendelkezésre állnak a legújabb dev csomagot, nem úgy, mint Ubuntun, hogy csak x verzióval előttiek. Főleg akkor sajnálom ezeket a usereket, amikor ilyen Stockholm-szindróma mentén védik a megszokott disztrójukat, amit csak megszokásból használnak, hogy de jó, az ő disztrójuk enterprise grade, meg stabilabb, meg LTS, meg mit tudom én mennyivel hosszabb támogatási idő, meg release party-t is tartottak a legutóbbi kiadás megjelenésekor. Ja, támogatottabb meg stabilabb. Lenne, ha menne rajta az, amit futtatni akarnának, és nem kéne vergődni vele. Közben meg mi tudjuk, hogy a gyakorlatban az Arch-vonal a full rolling létére semmivel nem instabilabb, sőt, még azt is megkockáztatom, hogy kevesebb a probléma vele, mert Ubuntun, Minten előfordul olyan, hogy frissítés után nem bootol a GRUB, meg drivergebasz vagy rossz X.org konfig miatt nem tölt be a grafikus felület, meg disztrófrissítést nem él túl az a nagyon stabil rendszer (pl. mikor 18.04-ről 20.04-re frissítenek), ilyenbe Archon sose futottam bele, hogy egy rendszer frissítés után ilyen teljesen elemi szinten boruljon meg. Volt, hogy 1-2 csomag telepítése-frissítése hibával meghiúsult, meg 1-2 alkalmazás frissebb verziója crashelt vagy kisebb bug fordult elő vele (semmi mission critical), de ezekre is mindig van gyorsan közzétett instant workaround (downgrade, upgrade még frissebb AUR-os gites verzióra, konfigfájl átírása vagy újragenerálása, pacman átparaméterezése, felesleges fájl vagy rossz symlink kézi törlése, jogosultsági probléma kézi kiigazítása), meg nagyon gyorsan jön a javító frissítés is, néha még órák sem telnek el közötte, így aki nem pár óránként frissítőmániás, mint én voltam régen, az javarészt bele sem fut még ezekben sem, mert mire rendszerfrissítést indít el, már a javított csomagok települnek neki, persze ilyen javított csomag is évente olyan kevésszer fordul elő, hogy egy kezén megszámolja ezeket az ember, lásd. archlinux.org News szekciója, és bár ott nem írnak minden ilyenről, de nincs lényegesen több incidens azoknál, amik fel vannak ott tüntetve. Ennyit a nagy instabilitásról.
-
Frawly
veterán
Annyit még hozzátennék, hogy a fontconfignak többféle része van, és grafikus felületfüggő is. KDE-nek van erre beépített megoldása, a vezérlőpultjában kéne megnézni elsőnek. A nagy DE-knek ez a legfőbb előnye, hogy aki nem annyira haladó, azoknak is leszállítanak mindenféle saját grafikus beállítólehetőséget.
Minimalista rendszereken viszont többféle helyen kell szerkeszteni, azon linkek alapján, amit te is betettél. Lényegében ennek a fajta fontkonfignak három eleme van:
1) font config (első Arch Wiki-s link)
2) a fenti megoldás nem támogató X.org-os programoknak a .Xresources fájlban (szintén ugyanannak az Arch Wiki cikknek a vége felé írnak róla)
3) alkalmazásszinten is szükséges lehet állítani (pl. Winetricks-szel Wine-ban)
4) nem negyedik elem, csak megjegyzem, hogy Wayland alatt meg a WM/DE gondoskodik a font simításról, bár a 2)-es pontot kivéve itt is ugyanazok a pontok játszanak.Firefoxhoz nem kötelező a Liberaton fontot feltenni, azt a megoldást is lehet választani, hogy az ember felrakja a saját fontjait (én pl. DejaVu, de ki mire gerjed, fel lehet tenni Ubuntu, Terminus, Droid, Roboto, Opensans, MS fontokat is), és beállítja azt Firefox-ban, a Beállításoknál, hogy a fallback fontokat azzal renderelje, pl. DejaVu Sans.
Egyébként meg ez Archon eleinte szokatlan lesz, hogy ami Manjaro-n alapból ment, meg jó volt, ahhoz Archon varázsolni kell. Ez nem azért van, mert az Arch szar, meg a felhasználókat jól meg akarják szopatni, hanem szándékosan default konfiggal jönnek az alkalmazások, és defaulton nem a disztró saját beállítását értem, hanem az egyes alkalmazások fejlesztőinek a defaultját, ahol lényégében semmi nincs testre szabva, semmi extra nincs feltéve, se feltémázva. Ez azt okozza, hogy nincs semmi beállítva, mert az Arch nem akar találgatni, hogy mi a jó a felhasználónak, arra számítanak, hogy haladó user rakja fel, aki úgyis testre szab magának mindent, és nem akarják kristálygömbbel előre találgatni, hogy milyen beállítás, téma, stb. lesz jó neki. Azért meg nem akarnak egy csomó csomagot feltenni (pl. Octopi), meg csomó konfigot beállítani (pl. pont ez a szóban forgó font config), hogy aztán a felhasználónak azzal kelljen kezdenie az Arch-telepítést, hogy egy csomó csomagot le kell szedjen, meg mindent át kell újra állítgasson.
Sokszor egyébként gépfüggő is a fontbeállítás. ThinkPad X220-amnak elég gyopár HD TN kijelzője van, ami kicsi is (12 col), azon muszáj volt bekacsolni a max. RGB fontsimítást, legerősebb fokozatú Hintinget. Érdekes mód erre az új laptopon nem volt szükség, mert azon már rendes, 15,6 colos FullHD IPS kijelző van, ami a finomabb felbontással, kisebb pixelekkel eleve úgy rendereli a fontokat, hogy nem kell akkora korrekció.
A másik, ami Archon feltűnő lesz, hogy több frissítés lesz, mert nem tartják vissza a verziókat egyel, mint a Manjaro. Ha az ember bekapcsolja Archon a Testing tárolókat, akkor meg még több frissítés lesz.
-
Frawly
veterán
válasz
Archttila
#7409
üzenetére
Egyébként ezzel a minimálosítással is vigyázni kell, nem szabad túl intenzíven erőltetni. Ez egy fejlődési folyamat, fokozatos, több állomással, nem nagyon lehet siettetni, erőltetni. Idő kell, míg megtalálod mindenre a terminálos alternatívát, megtanulod bekonfigolni, megszokod, rááll a kezed. Ez nem megy 5 perc alatt, hogy csettint valaki egyet, és akkor onnan minimalista, annak is vannak fokozatai. Én is fokozatosan haladok, mai napig találok még optimalizálni valót a rendszeren, nemrég dobtam ki a pavumixert, qbittorrentet, csiszoltam egy-két alkalmazásindító scriptemen, stb.. Anno a vim-nek is nagyon sokszor neki kellett futni, pálcika WM-eket is nehezen szoktam meg, nehéz volt bekonfigurálni a neomutt-ot és a hasonló megoldásokat.
-
Frawly
veterán
Ez ilyen, ezért nem szabad egy márka vagy gyártó fanjának lenni, meg termékeket márkamegszokásból venni. Azt kell megvenni gyártói névtől függetlenül, ami épp a jobb vétel. Régen én is főleg Intelt vettem, de nem márkafanságból, hanem vagy mert az volt a jobb vétel akkor, vagy mert a használt gépeim azzal jöttek, főleg, mióta laptopokat használok inkább. De az AMD mindig is szimpatikusabb volt, azonos árban nagyobb teljesítményt tudott, mint az Intel, és általában az újabb generációk is beletehetők ugyanabba a lapba, foglalatba, nem kell generációnként lapot cserélni alatta. De ez régen is így volt, késő 90-es évek, kora 2000-es években, pl. mikor az AMD a K6 sorozattal Pentium Pro, P2 teljesítményt nyújtott Celeron árában, Ahtlon-nal P3 teljesítményt nyújtott Celeron árában, vagy AthlonXP-vel P4 teljesítményt Celeron árában, aztán a P4-eket elkezdte verni az AMD64, a PentiumD-ket az Athlon x2, bár eddig az időszakig egy ponton elvérzett mindig az AMD, a lapok, chipsetek gyengébbek voltak alá. A Phenomok se voltak rosszak, de ott az Intel átvette előbb a Core2-vel a vezetést (Duo, Quad), majd a Core i vonallal, de 2017-től a Ryzen-nel nagyon komolyan visszaküzdötte magát az AMD, most így 2020-ra már mindenben verik az Intelt. De ez még Intel fanoknak is jó, mert ha a Ryzenek nem diktálnának ilyen kemény versenyt és fejlesztési tempót, akkor az Intel még mindig 2 mag 2 szálat adna a Pentiumokkal, 2 mag 4 szálat adna az i3-akkal, 4 mag 4 szálat az i5-ökkel, 4 mag 8 szálat az i7-ekkel. De így szépen elkezdte duplázni a magokat, aztán a szálakat is, meg behozták az i9 vonalat, beindult a verseny. Ennek pedig főleg a végfelhasználó látja előnyét, mindegy melyik márkát veszi, melyik modellt, melyik gent, újat, használtat, az árak a fejlődés miatt fokozatosan mennek le, főleg akkor, ha valaki nem a legújabb gent veszi.
-
Frawly
veterán
válasz
Archttila
#7410
üzenetére
Ez a baj, ha más konfigját veszed át, főleg, ha nem 1:1-ben. Célszerű ezért mindig az alkalmazáshoz szállított default konfigból elindulni, ami általában a /usr/lib/alkalmazásnév/ mappában van, ritkábban a /usr/share/alkalmazásnév vagy /usr/share/doc/alkalmaznév elérhetőségi úton és ezt a default konfigot módosítani saját igény szerint, fel lehet használni más konfigjából is sorokat, de nem 1:1-ben, hanem csak ihlet szintjén.
Konkrétan az rtorrent default konfigja ezen az elérési útkon kéne, hogy legyen, elvileg, mert nálam nincs ott:
/usr/share/doc/rtorrent/rtorrent.rcEz az rtorrent ilyen, nem felhasználóbarát, nehéz konfigolni, könnyű elrontani, elég, ha valahonnan egy / jel vagy idézőjel, zárójel hibádzik, nem lesz jó az egész konfig. Cserében viszont egyszer elég megcsinálni, utána a konfigfájlt elmentve és visszahúzva örökkévalóságig működik.
Az mpd + ncmpcpp nem rossz páros, mert igaz, hogy több függősége van, de többet is tud, mint a moc meg a cmus, és a függőségek közül a legtöbb apró, pár KB-os csomag. Van pár nagyobb, de azok sem baj, ha fent vannak faad2 (ez aac fájlok kezelésére van, nyílt aac kódek), python (sok minden használja ezt az v1-eset is, igaz az újabb progik már a v3.x-es verziót használják), fluidsynth (ez MIDI soundfont támogatáshoz, lejátszáshoz kell elvileg), fftw (ez a viusaliser modulhoz kell). Egyedül három dolgot nem látok indokolnak, libnfs, smbclient, igaz ezek azért vannak ott, hogy hálózati megosztásból is tudjon lejátszani, és a libgme, amiről fogalmam sincs micsoda, pacman -Qi vagy -Si segítségével el lehet olvasni. A lényeg, hogy ezeknek a függőségeknek a 99%-a kell amúgy is multimédiás dolgokhoz.
Ezeknek a csomagoknak a nagy részét bármilyen multimédiás program, lejátszó, konvertáló, kódek behúzza, nálam pl. az ffmpeg, meg az mpv nagyon kell, behúzta ezeknek a nagy részét, amit írsz, pythonon is alapul egy csomó progi, fluidsynth-et kézzel kellett felraknom a Re-Volt játék RVGL natív portjához.
Én egyébként azért nem szeretem annyira az mpd + ncmpcpp párost, mert nekem túl bonyolult, túl nehezen konfigurálható. Ha már így megküzdöttél az rtorrent-tel, nem akarlak elkeseríteni, de a fenti páros konfigja egy nagyságrenddel nehezebb, mert annyival bonyolultabbak, ráadásul két konfig is lesz, egyik az mpd-hez, a másik a klienshez. Rohadt bonyás, nagyon sok billkombót kell fejben tartani, egyszerűen nem bírok hozzászokni. Pedig jó cucc, nagyon sokat tud, jól lehet scriptelni, mindenféle kijelző és távirányítós/hotkey modulokat írni hozzá pálcika WM-ekhez, panelekhez, de cserében nekem túl összetett, majdnem egyetemi tárgyként lehetne oktatni. Ezért szoktam a cmus-nál maradni, alapokat az is tudja, billentyűparancsa kevesebb van, könnyebbem megtanulható a kezelése, könnyebben konfigolható, kisebb, kevesebb függősége van.
-
Frawly
veterán
Az 5-7 mp-es bootidő valóban nem rossz, azt nem tudom, hogy minimalistább megoldással mennyit gyorsulna, nagyon gépfüggő is, és nem csak a procitól függ, hanem SSD-től is. Az i3-9100F szerintem nem olyan rossz proci, simán hozza a korai genes i5-i7-esek szintjét, mert igaz, hogy csak 4 mag, 4 szál, de több cache, magasabb IPC, magasabb órajel, újabb utasításkészletek, PCIe 3.0 sávok és a DDR4 nagyobb sávszélessége, stb.. Szóval az i3 név megtévesztő, desktop Intel prociknál újabb genből, 8-10. gen nem olyan rossz, annyit fejlődtek mára a procik, hogy még egy ilyen alsóbb kategóriás is veri a néhány generációval korábbi felső kategóriásakat. A még újabb i3-10100 pl. a tesztek alapján az i7-7700K szintjén van, igaz az már 4 mag 8 szál, de ez a 9100F is simán hozza szerintem az i5-6600 és i7-4770 szintjét.
Mondjuk az igaz, hogy én i3-at nem vennék, az i3-9100 megjelenése idején már a Ryzen 1600 is elég olcsó volt, az nem csak olcsóbb (lap is olcsóbb alá), de 6 mag, 12 szál, háromszor annyi cache, magasabb frekis RAM-ot is támogat, bár kisebb IPC, kisebb CPU órajel, de a lap is olcsóbb hozzá, meg az AM4-e foglalatot tipikusan később olcsón felbővítheted Ryzen 5800X-ig minimum (ha B450, B550, X470, X570-es chipsetes), a Ryzen 5900-5950X már lapfüggő, hogy mit bír a VRM. Meg átlag felhasználásnál, ami nem használ túl sok magot, nem nagyon érezni a különbséget a Ryzen 1600 vs. i3-9100F, játékoknál is határeset, hogy mivel nézzük, mennyire érzékeny a frekire az adott játék. De a Ryzen mindenképp jövőtállóbb platform.
-
Frawly
veterán
válasz
Shyciii
#7404
üzenetére
Neki már nem lenne sebességben előrelépés az Arch + bspwm, nekem sem az. Már az Arch + Sway is annyira minimalista, hogy annál lényegében már csak az a dwm és a TinyWM minimalistább csak, meg egy Gentoo. A bspwm már nem minimalistább, viszont nagyon rugalmas, mert shxkd-n keresztül futtatott bspwmc-vel be tudsz neki vinni WM-funkciós parancsokat, amik nagyon rugalmassá teszik az albakkezelést. Egyébként ilyet tud az i3wm és a klónja, a Sway is, de ott eléggé meg van bonyolítva a rpc-msg rendszerrel, bspwm-en ez jobban össze van rakva.
#7405 Lenry: a többletsebesség iránti igényt akkor fogod érezni, ha meglátod, hogy ezek a minimalistább megoldások mennyivel gyorsabbak ugyanazon a gépen. Ha nem akarsz hosszan konfigurálgatni, dobj fel egy tartalék meghajtóra egy ArcoLinux dwm-et, azon meglátod, hogy milyen villámgyors. Harmada-negyede boot és lag a progik betöltésénél, háromszor-négyszer olyan gyors leállás, de nem is csoda, mert harmada-negyede RAM foglalás, kevesebb lomot tölt be, nem indít mindenféle extra systemd-service-t, stb.. Kb. annyira repül a gép, mintha csak MS-DOS-t használnál rajta. És félre ne érts, szolgáltatása is kevesebb van egy ilyen fapados megoldásnak, de rájössz, hogy a nagy DE-k funkcionalitása kiváltható, nem lesz akkor szükség mindenféle ikonra, dokkra, asztali ikonkezelésre, indítómenüre, ablakdekorációkra, stb. főleg, ha csak pár terminál fut állandóan, és mindent azokban oldasz meg, meg mindent konfigfájlok közvetlen szerkesztésével állítasz be. Akkor már semmit nem nyújtanak a GUI-s megoldások, meg a sok vizuális élményfokozó, csak egyszerű gimmick, körítés lesznek. Nyilván ez azt is igényli, hogy akkor már máshogy használod a gépet, más workflow, elrugaszkodsz egy Windows-szerű hagyományos dekstop metaforától. Ez nekem is nehéz volt, mert Windowson ezt szoktam meg, hogy van indítómenü, meg asztali ikonok, mindent egérrel csinálok, stb.. Ez annyira mélyen be tud ivódni az emberben, hogy azt hiszi, hogy nem lehet másképp, közben meg nem csak lehet, de sokkal hatékonyabban is.
-
Frawly
veterán
Most a Berry WM-et teszteltem (ez is X.org WM, nem Wayland), ez egy bspwm mintájára működő, minimalista WM, de nem tiling, hanem stacking, de épp úgy a saját command interface-ére épül, meg sxhkd-re. Ehhez képest szerintem még használhatatlan állapotban van. Pl. ha floaing ablakok között egérmutatóval váltanék, akkor a fókuszt kapó ablak sokszor a háttérben marad, nem hozható az előtérbe. Nem kezel taskváltást. Nem lehet neki beállítani, hogy új program indulásánál az ablakot maximális (de nem teljes képernyős) módban indítsa. Ezen a szinten ez még felejtős, nincs készen a hétköznapi használatra, kár érte, mert majdnem ott lenne, 1-2 apróságot leszámítva, de azok még nagyon hiányoznak belőle. A következő nekifutásom bspwm-mel lesz.
-
Frawly
veterán
válasz
Archttila
#7400
üzenetére
Ezt én így oldanám meg, de a külső drive-nak nem tudjuk az elérési útját, így azt /kulso/-ként adom meg:
# Instance layout (base paths)
method.insert = cfg.basedir, private|const|string, (cat,"/kulso/")
method.insert = cfg.download, private|const|string, (cat,(cfg.basedir),"Downloads/")
method.insert = cfg.logs, private|const|string, (cat,"/home/usernev/.log/")
method.insert = cfg.logfile, private|const|string, (cat,(cfg.logs),"rtorrent-",(system.time),".log")
method.insert = cfg.session, private|const|string, (cat,(cfg.basedir),".session/")
method.insert = cfg.watch, private|const|string, (cat,"/home/usernev/watch/")Az user mappájának szándékosan írtam konkrét elérési utat, /home/usernev/ formájában, a ~/ is működne, de ha másik userrel lépsz be, akkor másik mappában fogja ezeket keresni.
A mappákat kézzel érdemes létrehozni az rtorrent használata előtt. Konfigfájlba meg nem érdemes sed-del belebarmolni, mert nem látod mit csinál, mit mire írt rá. Kézzel nagyobb munka, de ott tudod nyomkövetni mi mire lett átírva, mi nem működik.
-
Frawly
veterán
válasz
Archttila
#7397
üzenetére
Ezt akkor múltkor benéztem, és kell a nox-hoz is a qt5. Jó tudni. Nekem az rtorrent-ből csak a sorbaállítás hiányzik, a minimalizmusa tetszene. Az rtorrent-nek kell session mappa mindenképp, vagyis elfut nélküle, de ha úgy lépsz ki belőle, hogy még nincs letöltve a torrent, akkor egyrészt nem fog emlékezni következő induláskor, hogy milyen torrentek futottak, és azon belül melyik hol tartott. Persze ilyenkor is hozzáadogathatod őket, meg leellenőrzni a részlegesen letöltött fájlokat, de lassabb lesz, és lesz néhány le nem töltendő fájltöredék, amit újra lehúz. Nem ajánlom, inkább férjen el egy /home/bla-bla/rtorrent mappában az a 3 almappa, ./session, /.watch /downloads vagy ilyesmi, de még össze is lehet vonni őket egybe, mindháromra ugyanazt a mappát megadni.
Ja, a Dracula színséma nekem is tetszik, használom vim-ben. Bár nekem a kedvencem a kávébarna Bespin-színséma a Mozillától, ezt még Notepad++-ban és Commodo Editben szoktam meg még 2014-ben, és nem találtam ennél jobbat, de a népszerű színsémák mind jók Gruvbox, Solarized, Nord, Zenburn, Desert. Ezek egy jó betűtípussal, egy minimalista WM-ben, ablakkeret nélkül, átlátszó/homályosított terminálban és panellel, szép háttérképpel esztétikailag verik bármilyen DE Gtk3 és Qt5 témáját. Dracula-nak van egy alvariációja, a Darkula. Látom átvetted dt-nek a dizájnjait
Viszont én leszoktam róla, hogy a terminált színsémázzam, nem igénytelenségből, de néhány terminálos és CLI proginek tönkreteszi a megjelenését a saját színséma, amik a sztenderd 16 színre építenének, pl. mc, htop. De ennek ellenére csak a terminál színsémátlan nálam, ahogy elindítok valami terminálos progit, mc, Vifm, vim, stb., azoknak egyből betölt a saját színsémája. Meg azért sem zavaró, hogy a terminálomnak nincs saját színsémája, mert magát a terminált shellel ritkán használom, általában már csak a benne futó progival együtt indítom, abban meg van saját színséma, vagy scriptet futtatok benne, ami csak elindít valami mást, vagy kiír pár sor kimenetet (ilyenkor néha spéci színsémával indítom egy alternatív konfigfájlt megadva) és már zárom is be. Tehát magát a terminált a maga natúrságában nem nagyon látom.
-
Frawly
veterán
válasz
Shyciii
#7394
üzenetére
Arra tudok még gondolni, hogy a memóriafoglalást nem nézed jól. Vagy valami olyan lib fut a háttérben, amihez képest az udisks2 nem foglal már sokat, míg nálam nincs betöltve alapból ilyen, és ha felteszem, akkor sokkal jobban dobja meg a memóriafogyasztást. Mondom, az írásod alapján adtam neki új esélyt, lebőgött újfent. Én erre is emlékeztem, hogy ilyen, csak elbizonytalanítottál, így frissen újra kipróbálva bebizonyosodott, hogy jól emlékeztem. Nálam mindig is sokat evett, ezért a jövőben sem fogom használni.
#7388 sati: gyors keresőzés azt hoztam, hogy azok a systemd-szolgáltatások, amiknek a neve kukac karakterre végződik, azokból több is futhat egyszerre. Ezt jelzi benne a speciális karakter.
A spi-ket illetően valószínűleg igazad van, nem lehet tőlük megszabadulni. Még nekem sem, mert a Firefox, Steam, Wine használ nálam is Gtk3-at, sőt, úgy emlékszek, hogy a redshift-nek is kell D-bus, annak meg függősége ez az spi-nyomorékság is.
Közben meg lehet mégis megtartom az Artix-ot. A mirrorok lassúsága még mindig zavar, de annyira flottul belaktam a rendszert, hogy nincs szívem dobni, főleg, mert amúgy a lassabb csomagletöltésen kívül bajom nincs vele, minden megfelelően működik rajta, semmi nem bugos. Talán az OpenRC lehetne gyorsabb, meg a consolefont betöltődése lehetne következetesebb, csak a tty1-en működik, de majd megoldom. Nem akarom túl korán dobni az Artixot, a Void is kapott anno egy 6+ hónapnyi esélyt.
Azért sem húzom vissza az X220-ról az Archot, mert közben szép fokozatosan csepegnek nálam a rendszerszintű változások, nem csak a pavucontrol-t cseréltem le ncurses-t használó pulsemixerre, de már scripttel csatolok fel, meg a játékindító scriptem is átírtam, illetve vim-ről állok át neovim-re, és elkezdem tesztelni újra a bspwm-et, változott a picom és a polybar konfigja. Én ezért sem mentem el a rendszerem soha, mert kb. pár havonta összejön annyi változás, módosulás, hogy egy régi rendszer visszahúzásával amúgy sem sokra mennék. Mindig találok a rendszeren olyan pontokat, amiket lehet optimalizálni, meg hatékonyabbá lehet tenni. Ezért is szoktam írni, hogy ez egy fejlődési folyamat, nem lehet erőltetni, meg gyorsítani sem, és nem pillanatnyi, hanem fokozatos, lassú folyamat. Senki nem úgy születik, hogy minimalista, hanem szép fokozatosan érik meg rá a szemlélete, ahogy fedezi fel az apróságokat, meg a megoldási módozatokat, és rájön, hogy azok jobbak, hatékonyabbak, mint a hagyományos megoldások.
A qbittorrent-nox-szal nem lenne baj, mert az nem annyira bloat, nem kell neki Qt, meg hasonlók. Én azért dobtam, mert a qBittorrent-fejlesztők rendszeresen nem tudják lekövetni a libtorrent library változásait, amire a kliensük épül. Ez az rtorrent-ps tud torrenteket sorakoztatni, hogy csak x darab tölthet le, és y darab tölthet fel, addig a többi sorakozik? Nekem csak ez az egy funkció hiányzott, de csak sima rtorrentet próbáltam eddig. Jelenleg transmission-cli-t használok, hogy webes interface-szel böngészőből, hol terminálból tremc klienssel. Mikor milyen kedven van.
-
Frawly
veterán
válasz
Archttila
#7390
üzenetére
Ezeket én is most nyomozom, hogy minek a folyamata, hogy lehetne kiszedni. Elvileg a net szerint ezek a dbus-hoz tartoznak, de hogy a dbus-t is igényli, azt rendszerenként lehet megmondani, hogy a WM, panel, valami hálózati szolgáltatás, GPU driver vagy micsoda. Még nekem sem sikerült megfejteni, hogy hogyan lehetne kiszedni ezt a kettőt a rendszerből.
-
Frawly
veterán
válasz
vargalex
#7374
üzenetére
Oké, öntsünk tiszta vizet a pohárba, mert kiforgatjátok amit írok. Annyiból tényleg szakmai tévedést írtam, hogy a bloatságot a gvfs-nek tudtam be, meg hogy nevében keverem az udiskie-t az udisks2-vel. De azt kell érteni, hogy a LÉNYEGBEN igazam volt. Jó, akkor nem a gvfs a bloat, hanem az udisks2, ami magával hoz, és ne hazuttoljatok meg légyszi, itt van a pacman -S gvfs kimenete Artixon:
looking for conflicting packages...Packages (21) argon2-20190702-3 btrfs-progs-5.9-1 cryptsetup-2.3.4-1 device-mapper-2.02.187-3 dmraid-1.0.0.rc16.3-12 dosfstools-4.1-3 gcr-3.38-1
gptfdisk-1.0.5-1 libatasmart-0.19-5 libblockdev-2.24-1 libbytesize-2.4-1 libyaml-0.2.5-1 lvm2-2.02.187-3 mdadm-4.1-2 ndctl-70.1-1
parted-3.3-2 thin-provisioning-tools-0.9.0-1 udisks2-2.9.1-1.1 volume_key-0.3.12-3 xfsprogs-5.8.0-1 gvfs-1.46.1-1Total Installed Size: 54.15 MiB
:: Proceed with installation? [Y/n]
Felrak 54 mega szutykot, közötte az udisks2-őt, ha újraindítom a gépet, ott fut a folyamatok között az udiskd, eszi a rengeteg memóriát. Vagyis ahhoz képest rengeteg, amire az ember használná. Kötve hiszem, hogy ez Artix-on lenne csak így, bizonyíték, hogy Arch-on is így van (kattintsatok a Dependencies-re, majd alul Show more...), és kötve hiszem, hogy pont a Manjaro vagy akár a Debian/Ubuntu-vonal lenne kivétel. Nézzétek át a process listát, ágábrázolásban, mi fut, mi indította, mihez kell. Az a baj, hogy aki megszokta a bloatabb DE-ket, azoknak nehezebb elmagyarázni, mert az hiszik, hogy ezek a rendszer, meg a Linux kernel részei, közben nem.
Az udiskie-t csak én keverem, mert van egy csomó ilyen szutyok, udisks, udisks2, udiskd, udiskie, és annyira hasonló a nevük, hogy simán lehet keverni, bár ez sem teljes tévedés, mert van egymáshoz közük, pl. az udiskie egy frontend az udisks2-höz és udiskd-hez (ami az udisks2 daemonja), és az udisks pedig az elődje, amire az udiskd2 előtt épült. Tehát ha az egyiket felteszitek, rántja magával a többit. Lehet itt vitatkozni, hogy nem az alkohol káros a szervezetre, hanem a májzsugor, amit magával hoz, a lényegen nem fog változtatni.
Fejezzétek be a gvfs leírását, igen, én is tudom, hogy egy virtuális fs driver, ami a userlandban implementál fájlrendszert, hogy ne kelljen a kernelspace-ben a kernel fs drivereket használni, amihez root jog kell, meg olyan fájlrendszer is implemetálva legyen, amihez nincs kerneldriver közvetlenül, pl. hálózati csatolások, egyéb protokollok, NFS, Samba, FTP, MTP, PPT, stb.. Annyiból viszont igenis bloat, mint már írtam, és a kimenet is bizonyítja, hogy hozza magával a bloat szutykokat. Ezeket nem csak hogy felteszi, de a párat a háttérben is futtatni fog szép szorgosan. Gondolom valaki annyira keményen dolgozik érte, le tudta tiltani, hogy ezek a komponensek automatice induljanak, de egyrészt minden frissítéskor vissza fogja őket tenni a vonatkozó csomagok postinstall scriptje, azaz lehet vele fetrengeni minden telepítéskor, frissítéskor, és meg ha tényleg szükség van az általa nyújtott funkcióra, akkor kézzel indítva futtatni őket, oh, de wait, pont az automatikáról volt szó, hogy csatoláshoz ne kelljen semmit külön kézileg indítani, mert akkor az egész értelme ment le a lefolyóba.
Én meg már ötödször leírom, hogy pont ezeket kerülöm, hogy sok felesleges ballaszt azért menjen a háttérben, mert majd egyszer hátha kell. Nagy ritkán. De azért foglaljon folyamatosan. És nem maga az elfoglalt memória, hanem rendszerinduláskor a sok felesleges dolog betöltése. Ezek némelyike nem tűnik nagynak, egy kis 14 MB itt, egy kis 50 MB ott, egy kis 30 MB-os dbusd amott, egy kis SuzukiSwiftd, amott, logind, anámykínyja-spi-bus-launcher, spi2-nyomorékság, és az ember csak pislog, hogy a RAM használat nőtt 300-500-1000 MB-tal, és hiába combos a gép, i9, Ryzen 7-9, Threadripper, azért azoknak is idő induláskor betölteni ezt a sok szutykot, mert igaz, hogy gyorsabban töltik be, meg több mindent párhuzamosítanak, de akkor is idő nekik betölteni, mindegy milyen kevés ms, az az idő ott van, és sok ilyen sallangnál a végén elég meredeken összeadódik. És ha még tényleg annyira megkerülheteten lenne, hogy tényleg minden szoftvernek kéne nonstop, minden percben, arra azt mondanám, hogy nincs mit tenni. De van, mert megkerülhetők ezek. Pont ez a szépsége a Linuxnak, hogy itt nem kötelező a sok bloatot használni. Windows, MacOS alatt kell, mert azok készre drótozott egyenrendszerek, amik le is vannak zárva a felhasználó elől.
Már pedig ha az ember javarészt terminálos programokat futtat, GUI-sat kivéve, akkor meg aztán tényleg hulla felesleges ezeknek a 99%-a, lehet ezek nélkül is meghajtót kényelmesen felcsatolni, hangot csiholni, alkalmazásoknak kommunikálni, stb.. Még a hálózat is megoldható mindenféle netctl, NetworkManager meg egyéb nélkül.
Egyébként meg ez a meghajtócsatolás Linuxon el van maradva sok évvel. Külön halom bloat kell, hogy a jenlegi csatolási körülményesség megkerülhető legyen, mindenféle keretrendszerek és service-ek futtatása. Ennek nem szabadna így lennie. Értem hogy a biztonság miatt van így, hogy korlátozott user ne tudjon mesterséges chroot környezet beröffenteni (mikor is előre preparált fájlrendszereket csatol fel /proc, /etc, stb. helyekre, root jogot szerezve), de ez egy másik véglet. A user mappájába, user joggal, userspace driverrel engedniük kéne akárminek a csatolását, mindenféle szutyok feltétele nélkül, mindenféle root jog nélkül, out of the box, úgy, hogy kényelmesen automatizálható legyen, és ne legyen gebasz a korlátozott user írási jogával sem. Ebben a tekintetben tényleg le van maradva a Linux kb. 20-30 évet. És itt nem arról van szó, hogy aki haladó, ezt ne tudná megoldani, de ez a fetrengés felesleges hozzá, más OS-eken ez egy alap dolog, hogy van egy meghajtó, a user felcsatolja magának. Ami egyébként biztonságilag sem problémás, mert ha ugyanaz a korlátozott user bebootol egy Live rendszert, akkor ott root joggal fogja elérni ezeket a meghajtókat úgyis. Ha meg ez valaki ki akarja védeni, akkor nem elég a felcsatolást megnehezíteni, hanem titkosítás kell. Így erre a linuxos felcsatolási ökoszisztémára nagyon ráférne egy nagy adag modernizáció.
-
Frawly
veterán
válasz
Shyciii
#7371
üzenetére
Elvileg nem több sokkal, mint az én kézi csatolásom. De ezek szerint nem gvfs-sel csatolsz, hanem scripttel, ami használ gvfs-t is. Nagyon nem mindegy.
Xiaomim van nekem is, erről tudsz valami linket mutatni, hogy szabad rootoni? Mert én úgy tudom, hogy nem. A2-esem van, nem-Lite verzió.
Rooltálskor szerencséd volt, ha telót nem dobták vissza. A legtöbb gyártó ilyenkor azt mondja, hogy nem rendeltetésszerű felhasználás. Én még soha nem rootoltam az enyémet, mert vagy gariidőn belül nem mertem, gariidőn túl meg vagy megmurdelt a teló, vagy én törtem ripityára leejtve. A mostanimra még van egy kevés jótállás, valami pár hónap, nem is tudom pontosan mennyi.
-
Frawly
veterán
válasz
Shyciii
#7369
üzenetére
Ja, úgy elhiszem, hogy csak pár megát fogyaszt, ha mindent kihekkeltél belőle, és csak egy udev szabállyal hívogatsz egy scriptet, ami gfvs-t használ. Igen, úgy lehet nem fogyaszt sokat, de akkor előnye sincs azokhoz a megoldásokhoz képest, amiket én használok, vagy amikről én írtam.
Amiről én végig írok, az a szabvány gvfs alaptelepítés, ami udiskie-t meg mindent magával hoz. Na, az fogyaszt sokat, ha csak felteszed, és alap kiszerelésben használod. Nagyon sokat eszik, főleg, hogy csak 1 dologra használja mindenki (automount). És abban sem a gvfs fogyaszt főleg, hanem a többi modulja, udiskie, stb.. Tapasztalatból beszélek, használtam én is régen, míg DE-ket használtam, főleg Gtk-sak alatt, LXDE, Xfce, de használtam egy ideig Openbox alatt is. KDE5 alatt nem, mert annak van saját megoldása erre. De aztán dobtam ezeket, mert láttam milyen bloatok. Nálam nincs értelme, mint írtam, többször kifejtettem miért felesleges, és miért nincs értelme sallangot futtatnom a háttérben. Csak egyetlen darab olyan funkcióért sajnálok 50-100 MB memófoglalást, amit csak ritkán használok. És megint kihangsúlyozom, hogy nem azért, mert 16 GB RAM-ba nem fér bele, hanem elvi bloattalanítás és a betöltési-bootidők minél extrémebb lecsökkentése érdekében soványan tartom a rendszert. Ez segít a rendszer adminisztrálásakor, frissítésekor, egy kevés csomagos, saját scriptes, minimalista rendszert könnyen megjavítani, ha eltörne valami, meg frissítéskor is kevesebb csomagot húz le. Az ilyen Gtk-s bloatok hozzák a függőségeket egész függőségi fával, amiket aztán minden frissítéskor, meg stb. is le kell rántani, és minél komplexebb, nagyobb a kód, minél több függősége van, annál valószínűbb is, hogy egy frissítéskor eltörik.
Egyébként pont most néztem egy programozót a YouTube-on, angol fószer, 3-9 órás programozós videó vannak. Minimalista Debian, JWM telepítést használ. De! A háttérben a vim GVim-ként fut, ami felesleges, terminálból kéne használja. Aztán fut még neki egy kiló felesleges szutyok, Chrome pl. ami helyett használhatna Firefoxot vagy qutebrowsert (ez is elég lenne, mert az esetek többségében csak statikus html-eket néz benne, programozási referenciákat). Aztán OBS meg SimpleScreenRecoderderrel vesz fel, ezek helyett elég lenne az FFmpeg. Amúgy minimalista a rendszere, de felesleges helyeken meghagyott túl sok bloatot, így meg amit megnyert a réven, elbukja a vámon.
Olyan androidos gyártó meg valóban van, aki hivatalosan, garivesztés nélkül engedi a rootot, de csak néhány prémium gyártó néhány prémium készülékükön, azért meg nem fogok 200-300 ezer forintos telefont venni, de még 100 ezreset se, ha egyszer az igényeim egyébként kiszolgálja egy 50-60 ezres is. De a szívesen agyonverném élére fordított szívlapáttal azt, aki a Google-nél ezt kitalálta. Régi Android-verziókon is volt ilyen, de ott ki lehetett kapcsolni, főleg azoknál a telóknál, amelyek még USB Mass Storage módot is tudtak. Aztán behozták, hogy az MTP, PPT (fotókhoz, kamerákhoz) támogatott csak, és az is csak ilyen biztonsági megszorításokkal.
Egyébként az Androidot mindig is utáltam, csak azért tűröm meg, mert nincs alternatívája, iOS még szarabb, Windows Phone még szarabb volt, amíg ki nem halt. A Linux jobb lenne, de azt meg egyelőre kevés modell támogatja (Pine, Ubuntu-s telefonok).
-
Frawly
veterán
válasz
Shyciii
#7367
üzenetére
Igen, ezt én is tudom, hogy a GVFS csak egy keretrendszer, nem csak autocsatolásra jó, működik minden nélkül. De szépen megkérlek, hogy ne terelj, mert itt most az AUTOMATA csatolásról volt mindvégig szó, és ha ilyen szerepkörben használod, akkor de, fogyaszt elég szépen, és ezen nem csak magát a GVFS-t értve, hanem az egész ökoszisztémáját, még lefogadom az udiskie-n kívül is futtat olyan modulokat, amit nem vettél észre. Ha ezeket összeadogatod, elég meredek a fogyasztása. De azért írtam kezdettől, hogy van, akinél megéri, mért én ismerek olyan feljelsztőket, akik egész nap ilyen SSH-s, SFTP-s cuccokat csatolnak fel-le, fel-le, androidos telókkal meg mindenféle USB-s eszközökkel tarkítva, egész napjuk ebből áll, csati fel-le, fel-le, fel-le, 8 óra múlva is, fel-le, fel-le. Akkor megérheti használni, valóban. Vagy aki hiperbloat DE-t használ, ami indulásból úgyis bekajál 1 GB memóriát, és eleve fut rajta máris egy csomó Gtk-s vagy Qt-s lib, ott nem okoz nagy plusz fogyasztást, nem okoz túl sok plusz töltést, ilyen rendszerekre is van tervezve. Nekem nem éri meg, mert csak 1-2 állandó meghajtót csatolok, amit fstab-ból is tudnék, vagy andoridos nem rootolt telót, aminek meg a csatolása úgyse automatikus sehogy sem. Azért meg nem fogok sallangot futtatni, hogy szökőévenként egyszer egy új pendrive-ot vagy USB-s meghajtót fel akarok csatlakoztatni. Akkor csatolom kézzel terminálban, igen, kényelmetlen, de egyrészt erre is tudnék scriptet írni, de ritka használatra az sem éri meg, felcsatolom kézzel, ritkán egy alkalom erejéig ki lehet bírni, cserébe nem fut az év minden napjának minden órájában egy felesleges szutyok a háttérben mindenféle társfolyamattal, csak azért, mert majd egyszer hátha kell.
fstab-nál azért is írtam, hogy ezt csak állandóan, rendszeresen rádugott eszköznél lehet használni, olyan pendrive-nál hatástalan, amit először dugsz a gépre.
Az meg való igaz, hogy átállítható Android-telefonon az USB-kacsolat defaultja, de csak rootolt telón, nem hivatalosan, és rootolással kapásból buktad is rá a garit. Persze, ha nincs már rá jótállás, akár ez még egy járható út is, de az emberek 99%-a nem rootolja a telót. Vagy mert nem ért hozzá, vagy mert nem meri, vagy mert a gari miatt aggódik. Nem tragédia, de Google hibája, sokat nem lehet ellene tenni a rootoláson kívül. Ez van, okosteló PC-s rendszeren így is, úgy is kényelmetlenséggel fog járni, egy ultrabloat, konzumerista rendszer, mint a Win10 meg a többi szutyok, nem a felhasználóért van, hanem a felhasználó szivatására.
-
Frawly
veterán
válasz
Shyciii
#7365
üzenetére
Na, látod, ezt mondtam én neked, hogy nem 3 MB az. Nyilván az udiskie-t is hozzá kell számolni, ugyanis ha automount-ot szeretnél, akkor ez is hozzátartozik a gvfs-hez. Pont erről beszéltem, hogy behúz, indít futtat 100 kiló szutykot, ezért nem használom. Persze, ha nincs betöltve, akkor nem foglal semmit, de akkor meg nem is csinál semmit. Vifm meg nem tud semmilyen gvfs-t meg libmtp-t kezelni, egy terminálos program, nem tud semmilyen grafikus szolgáltatáshoz kapcsolódni, mint dbus, gvfs-akármik. Persze, a conf fájlába biztos fel lehet venni valami gvfs-es, vagy fusermount-os vagy valami udiskie-s parancsot, de az sem out of the box, hanem hekkelni kell hozzá erősen, és a kívánt funkció akkor sem lesz automatikus, hanem be kell hívni billentyűre.
Egyébként ha rendszeresen csatolt eszközről van szó, akkor a /etc/fstab-ba is fel lehet venni csatolási bejegyzést, és odaírni neki a nofail mount opciót, így ha nincs a gépre csatlakoztatva, akkor nem áll meg a boot, de ahogy menet közben a gépre csatlakoztatod a kívánt meghajtót, akkor az udev érzékeli, az fstab alapján felcsatolja az initrendszer vonatkozó szolgáltatása. Persze ez mtp-re nem működik, ahhoz mindenképpen userland-es MTP-s megoldás kell. Erre használok jmtpfs-es saját scriptet. Oké, nem teljesen automatikus, mert gyorsbillentyűre kell behívnom, de nem olyan nagy kényelmetlenség. Az androidos teló csatolása úgyse automatikus, csak úgy szólok, mert az ilyen telók 99,9999%-a biztonsági okból nem csatolódik, hanem a kezdőképernyőn kell lehúzni egy értesítést, ott kiválasztani, hogy az USB kapcsolat fajtája nem sima töltés, hanem MTP-kapcsolat, és majd csak utána lehet a gépen csatolni. Ezt a hülye Gúgli találta ki, adatlopás ellen, ők azzal érvelnek, hogy életszerűen előfordul, hogy a user nem veszi észre, hogy a telefonjára valaki USB-kábelt cuppantott, és lopja lefelé az adatait a telefonról. Ja, tényleg reális, az egyszeri szűz lány is így szokott megesni, hogy észre sem veszi, hogy beleáll egy gerendányi dákó, és jól megfarkalják, csak úgy véletlen szokott megesni. Aha.
-
Frawly
veterán
válasz
Shyciii
#7360
üzenetére
Most már annyira felcsigáztál, hogy feltettem én is a gfvs-mtp csomagot, ami feltette a gfvs-t és függőségeit. Újraindítom, erre nem hogy 3 MB-tal többet fogyaszt, de még 3 MB-tal kevesebbet boot utáni idle-ben. Persze a htop-ot nézve azonnal rájöttem a svindlire: nem fut se gvfs, se másik társfolyamata, így az egész nem is ér semmit, csatlakoztatok egy USB-s drive-ot vagy MTP-s telefont, semmi nem történik, persze erre számítottam is.
Nézve az Arch Wiki-t, valami Thunar vagy PCmanFM vagy hasonló Gtk/Qt-s szutyok kell hozzá, azt meg nem rakom fel. Meg lehet ezt oldani máshogy? Mert én nem látom be, hogy mit kéne elindítani, ami automatikusan csatol.
-
Frawly
veterán
válasz
Archttila
#7362
üzenetére
Kösz, el is felejtettem, hogy ki akartam próbálni, ezt még megejtem Artixon.
Chrome, Chromium, Opera, Vivaldi, Brave, stb. nálam kizárva, nagyon utálom a Chrome/Blink motoron alapuló böngészőket, röhejes memóriaéhség, bugosság, minden beléjük van drótozva, egy csomó mindent beállítani sem lehet, pl. saját DNS a böngészőbe. A Firefox is rég indítható már, igaz én nem láttam előnyét, ha Wayland alatt használom, nem gyorsabb, nem szebb, nem jobb, nem eszik kevesebb erőforrást. Annyi, hogy Wayland alatt VAAPI-val mehet a hardveres videókódolás, de azt megint külön be kell kapcsolni és mivel kísérleti feature, ezért gyakran bugos, eltörik. Nem véletlen nincsenek ezek a dolgok alapból bekapcsolva rajta.
-
Frawly
veterán
válasz
Archttila
#7357
üzenetére
Igen, azok a sorok még egy régi, X.org-os i3wm configból maradtak hátra, amit elfelejtettem törölni. De majd belejavítok a konfigba, mert már változott még egy ponton, pavumixer helyett már terminálos pulsemixer-t használok. Régen vacilláltam az ncpamixer és a pavumixer helyett, az egyik minimalista, de nem tudott mindent, ezért a GUI-snál maradtam (úgyis ritkán használom, csak mikor a külső DAC-om használom), de most kiváltja őket egy harmadik.
Ezek a változások most jönnek, mert most nem is Arch + Sway-en vagyok, hanem pár napig még Artix + X.org + Openbox-szal kísérletezek egy másik SSD-ről, ebben már át vannak vezetve az újdonságok, de még a Sway konfigjába nem, azt majd klónozás után ejtem meg, ahogy rákerül az új laptop új SSD-jére. Eddig nem tudtam klónozni, mert először SSD-t kellett venni, majd miután megérkezett, csavarhúzókészletet a torx csavarokhoz, majd időm nem volt, és csak most került be az új gépbe az új SSD, a napokban megy rá a klónozás.
Nem lenne rossz az Artix, ami miatt dobom, az az, hogy a mirrorjai lassúak. Meg az OpenRC-vel összecsiszoltsága nem valami jó, bár lehet runit-tal vagy S6init-tel jobb lenne.
-
Frawly
veterán
válasz
Archttila
#7355
üzenetére
Ja, 4M-mel nem csak „kicsit” lassul be, hanem nagyon. A kicsit azért írtam, hogy ha nem pontosan találnád el a szektorméretet, de nem lennél tőle olyan messze. Valószínű ez a 4M túlon túl kicsi volt.
A Sway-kongigom itt tudod elérni. A nagy részét kivágtam onnan, mert 95%-ban gyári a Sway konfigom, csak az elején lévő két hosszabb blokk saját szerzemény, meg a legvégén lévő 1 rövidebb, swaybar-os rész, a többi tényleg default, nem láttam értelmét benne hagyni, nincs benne tanulság. De előre szólok, hogy csalódni fogsz, nagyon minimalista konfig, csak egy-két plusz definíció, egy-két megváltoztatott szín, de semmi csicsa, semmi extra, szóval ha valami nagy dolgot vártál, akkor azt nem találod meg benne.
Egy tanulságos van talán benne, aminek viszont nem veszed hasznát, az a modális billentyű. A Win/Super billentyű megnyomásakor a Sway-em egy ún WM módba vált (ez beragad), és innen plusz egy gomb megnyomásával indulnak az alkalmazásaim, ezek főleg scriptként vannak meghívva. Az egész különlegessége az, hogy nem kell a Win billentyűt nyomva tartani, hanem fel lehet engedni, és után külön kell nyomni a másik billentyűt, amire az alkalmazás indul. Ez ugyanaz a modális trükk, mint Vim-ben az Esc billentyű, ami módot vált, nem kell nyomva tartani. Ha te nem használsz Vim-et, akkor neked ilyen funkció jó eséllyel nem fog kelleni, sőt, nem fog tetszeni.
Annyira nem vagyok pro a konfigolásban, mint dt, meg Luke Smith, az ő konfigjaik jobban néznek ki, szebbre formázott, kommentelt, grafikai dizájnjában is tökélyre vannak a színek belőve.
dt-nél nem tudom mit használ, szerintem a sztenderd .gitignore fájlokat használja, ha ezeket beteszed egy-egy mappába, akkor egy git commitnál azokat nem fogja felszinkronizálni, hanem figyelmen kívül hagyja őket, akkor is ha változtak, akkor is, ha nem. Ja, biztonság, mert lehetnek benne neki olyan fájlok, amik személyes információt tartalmaznak, nyilván azokat nem akarja senkivel megosztani. Nem csak dt, hanem senki sem.
-
-
Frawly
veterán
válasz
Shyciii
#7350
üzenetére
Ezek szerint tényleg ennyi fogyaszt, ami hihetetlen. Biztosan nem fut gvfs-folyamat? pacman -Rns segítségével szedd le. gvfs egy csomó összetevőből áll.
Az nem elég logika, hogy a gvfs-mtp-t leszedted, a pacman a függőségeit nem szedi le automatikusan. Azért kell az -R után az ns kapcsoló még.
#7351 sati: minden ThinkPad-en mások a tapipad, trackpoint neve, kódja, stb.. Ezeket a swaymsg -t get_inputs paranccsal tudod lekérdezni, ahogy Logitech-nél is csináltad. A görgetés működik trackpointtal, a középső egérgombot nyomva tartva használom a trackpointot, akkor nem az egérkurzor mozog, hanem a tartalom görgetődik, nem csak függőlegesen, hanem vízszintesen is működik, feltéve, hogy van vízszintesen is görgethető tartalom az adott alkalmazásban. Sőt, a touchpad-en két újjal húzás is görget nálam.
Ez a dd parancs teljesen jó SSD-re is, a szektorméretet emeld meg, min 64M-et ajánlok, de ha a forrás és cél is SSD, és kellően gyors, akkor 256M vagy 512M értékekkel is lehet próbálkozni.
-
Frawly
veterán
válasz
Archttila
#7346
üzenetére
Ez teljesen jónak tűnik. Ha rossz lenne, akkor a Sway induláskor piros figyelmeztetősávval felhívja rá a figyelmet, hogy melyik sorban van hiba. Kapcsos zárójel csak akkor kell, ha egy input eszközhöz egyszerre több tulajdonságot is megadsz.
Pl. nálam a ThinkPad-en:
input "1:1:AT_Translated_Set_2_keyboard" {
xkb_layout hu,us
xkb_options grp_led:caps,grp:alt_space_toggle,caps:escape
repeat_delay 280
repeat_rate 50
}
input "2:7:SynPS/2_Synaptics_TouchPad" {
dwt disabled
tap disabled
pointer_accel 1
middle_emulation enabled
drag disabled
left_handed disabled
}
input "2:10:TPPS/2_IBM_TrackPoint" {
tap enabled
pointer_accel 1
middle_emulation enabled
left_handed disabled
}De nálad nem négy alszabály van 1 eszközre, hanem 1 főszabály 4 eszközre, a Logitech billentyűzetre, meg a *-ra, ami bármely eszközt jelent, az megint más, hogy ez a 4 beállított eszköz ugyanarra fog vonatkozni.
Bár a config fájl szépségét megőrzendő, ez a megoldás olvashatóbb, elegánsabb lenne, de ugyanúgy működne:
input 133:8209:Logitech_K520 {
xkb_model "logicd"
xkb_layout "hu"
xkb_capslock disable
xkb_numlock enable
}Egyre kell csak ilyenkor figyelni, a nyitó kapcsos zárójelnek egy sorban kell lennie az eszköz nevével, ami nem mutat a legszebben, de ez sajnos szükséges. Enélkül induláskor a Sway behány ilyen config error: unexpected character hibaüzit.
-
Frawly
veterán
válasz
Shyciii
#7344
üzenetére
Szerintem nézd meg még egyszer, a 3 MB memóriafogyasztás biztosan irreális. Főleg, hogy a gvfs önmagában nem csinál semmit, az csak egy interface / user land driver az ún. gnome virtual filesystem protocol-hoz, ha csak azt telepíted, akkor nem csinál semmit. Ahhoz, hogy neked az bármit csatoljon, kell a gvfs-mount, kell a gvfs-mtp, meg egy csomó komponens még, azokat szépen hozzáadogatod, és meglátod, hogy nem hogy 3, de inkább 36 MB fölött leszel, garantálom talán a 80-at is. Meg add hozzá a shared memóriafogyasztás, mert nem csak a gvfs, gvfs-udev, gvfs-mount, gvfs-bizbasz fut ám, hanem böltöget nagy rakás Gtk-s libet is. Ne felszínesen nézd, hogy a nem shared memóriafogyasztása az egy szem gvfs folyamatnak alacsonynak tűnik, úgy lemaradsz a teljes képről. Nézd az egész process listát, rendezd ág-ábrázolásba, ne csak az első memófoglalási oszlopot add hozzá, és máris meglátod, hogy foglal az még dögivel. Ami engem nem zavarna, mert dögivel van szabad memóriám, hanem ez a sok sallang sokra tud menni, ha az ember nem kezeli elvi kérdésként és elhalmozza ezeket, egy kicsi elfér itt, á, ezt nem bánom még alapon.
udev szabályos csatolás az nekem sem működött soha, Arch Wiki alapján csináltam. Bár az is lehet, hogy az a legjobb megoldás, csak bénák vagyunk hozzá, hogy normálisan beállítsuk.
Notification-nel nincs bajom, a Dunst emlékeim szerint nem foglal, ha nem fut, csak akkor indul be, ha értesíteni valót kap, de nekem nincs szükségem rá. Azoknál a scriptjeimnél, amelyeknél szükségem van debug kimenetre, azok kiírják azt terminálba, ha meg már nincs rá szükségem, bezárom.
Azt se gondoltam volna, hogy van még ilyen telefonközpontos képzés, el nem tudom képzelni, hogy mit lehet továbbképződni, főleg, mióta gépek csinálják leginkább, de ha még oda is tesznek embert, akkor is csak pár gombot kell neki megmutatni, hogy milyen bejövő hívást hova hogyan kapcsolhat, és hogy kezelje a prioritásokat. Nagyon nagy tudománya ennek már nincs. De még régen, az analóg időkben is sokszor meg tudta csinálni egy helyben betanított portás, meg 0 műszaki érzékkel bíró Titkárságiné Mancika.
Új hozzászólás Aktív témák
Hirdetés
- Villanyszerelés
- Autós topik
- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
- Gaming notebook topik
- E-roller topik
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- The Crew sorozat
- RC modell földön, vízen, levegőben
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Vélemény: nem úgy tűnik, de Lip-Bu Tan most menti meg az Intelt
- További aktív témák...
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- BESZÁMÍTÁS! ASUS H610M I5 12400F 32GB DDR5 512GB SSD RTX 4060 8GB SOF CLONE 3 Chieftec 600W
- LG 48C2 - 48" OLED EVO - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen5 CPU
- SanDisk Extreme Portable 8TB (SDSSDE61-8T00-G25)
- Külföldi csomagszállítás Packeta csomagpontokon keresztül!
- NJOY Aster 3K 3000VA/2700W Rack Szünetmentes Táp
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest