- One mobilszolgáltatások
- iPhone topik
- Mobil flották
- Samsung Galaxy S21 FE 5G - utóirat
- Ilyen lesz a Fairphone 6
- Android alkalmazások - szoftver kibeszélő topik
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Honor 200 - kétszázért pont jó lenne
- Samsung Galaxy A56 - megbízható középszerűség
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
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.
-
vargalex
félisten
válasz
Shyciii
#7383
üzenetére
Most rákeresve a dolgaimban, lehet, hogy kevertem. Egy Alcatel Idol 2-nél (pedig az nem mai készülék) fastboot módban futtattam egy TWRP-t mentés miatt (nem is telepítettem fel), majd utána szervízbe került a készülék. Javították, de visszajött egy screenshottal, hogy a készülék módosított recovery-t futtatott valaha, így ha olyan hiba lesz, ami arra vezethető vissza, elutasíthatják a garanciát. A szervíz által használt belső alkalmazásról készült a screenshot.
-
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
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
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.
-
Frawly
veterán
válasz
Shyciii
#7342
üzenetére
Én kézileg mountolok, ha annyira gyakran csinálnám, akkor írnék rá egy fzf scriptet, ami az lsblk által listázott eszközök közül engedne választani, meg utána néhány célmappa között, és felcsatolná fuse mount-tal, hogy ne kelljen hozzá root jelszó, meg ne csak root tudjon hozzáférni a felcsatolt meghajtóhoz.
Androidos telót jmtpfs-t használó scripttel csatolom fel, megint gyorsbillentyűre meghívva. Notification sem kell egyáltalán, nem használok olyat, a script terminálablakban mutatja a csatolás sikerességét vagy sikertelenségét, ha tudomásul vettem, bezárom a terminálablakot.
A gvfs bloat, de azt elismerem, hogy aki sokféle eszközt, meghajtót, virtuális FS-t csatolgat fel, ebből áll szinte a napja, annak megéri feltenni, mert kényelmes automatikus megoldás, meg egy csomó fájlkezelő is natívan kezeli a gvfs-es megosztásokat. Tehát bloat, de egyes esetekben kínálhat olyan előnyt, amikor a bloatsága indokolható. Én kb. minden 2 hétben egyszer csatolok fel, egy nyomorult eszközt, azért ne fusson mindenféle gvfs folyamat a háttérben. Nagy tévedés, hogy 35 MB-tot foglal, vagyis lehet annyit, de csak a fő gvfs process, de futtat az ám egy csomó gvfs-blabla folyamatot is, és végeredményben úgy bekajál 80-100 MB memóriát is akár, hogy jó recsegős-kolbászosat böffent utána, nálam meg az egész grafikus felület nem eszik ennyit, ennek jó a felét foglalja mindenestől, feh, polybar, picom-mal együtt.
Meg azt is szem előtt kell tartani, hogy aki full Gtk-s DE-t használ, annak már be van töltve a memóriába egy csomó gtk-s lib, így a gvfs ezeket tudja shared library-ként használni, újra ezeket nem tölti be, így pedig ebben az esetben sokkal kevesebb plusz memóriafogyasztást okoz. Így Gnome, Xfce, Mate, Cinnamon, LXDE, Budgie, stb. alatt okés lehet a használata. Én viszont gtk-s programok közül csak egyet használok rendszeresen, az a Firefox, és nagy ritkán Wine, Steam használja még, így nem ezek nálam nincsenek betöltve shared library-ként, extra 80-100 MB memóriafogyasztást meg nem akarok. Nem mintha a 16 giga RAM-ba nem férne bele, de a minimalilzmus a bootot is gyorsítja, a rendszernek induláskor negyede, ötöde szutykot kell betölteni, a procinak is sokkal kevesebb munka kevesebb kódot futtatni, a lemezeknek (hiába SSD, az egyik ráadásul NVMe) is kevesebb munka töltögetni. És hiába mondja uby, hogy +x MB nem tétel több giga RAM-nál, és valóban nem, de egy kis 100 ms itt, egy kis 200 ms ott, a sok apró sallang betöltése meg a végén sokra megy, mikor már 30-100 ilyen összegyűlik. Én is használtam korábban ezeket a bloat megoldásokat, de aztán rájön az ember, hogy ezek mind kiválthatók, nélkülözhetők.
-
#63718632
törölt tag
-
#63718632
törölt tag
válasz
Shyciii
#7247
üzenetére
Mostanra látom már, nekem is szükségem lesz egy saját szkriptre, hogy ne fejből kelljen mindent és gyorsabb is legyen egy új telepítés.
Majd megpróbálom össze rakni magamnak.
Az a kérdésem, hogy github vagy gitlab legyen? Mindegyiket csak úgy használtam eddig, hogy valamit leklónoztam onnan telepítésre. Saját helyem egyiken sincs. -
#63718632
törölt tag
-
Frawly
veterán
válasz
Shyciii
#7162
üzenetére
Ja, a micro jó. Olyan, mint a nano meg a pico, csak sokkal többet tud, hagyományos, sztenderd billentyűkombókat ismer, Ctrl+C/V, Ctrl/Shift-Ins, Ctrl+X, Ctrl+Q, Ctrl+S, stb., tehát sztenderd elvekre épülő, nem modalitással bonyolított, nem kell a használatát tanulni, mint a vimnél vagy Emacs-nél. Aki használt már nano-t vagy pico-t, vagy mceditet, Notepad/Notepad++ klónt, az a micro-val is könnyen boldogul, nem sokat kell tanulni rajta, de mégis terminálos, konzolos, text user interface-es, minimalista, csomó plugin és beállítási lehetőség, kódszínezés, scriptelhetőség, szóval komoly cucc, ötvözi a vim komolyságát, minimalizmusát a hagyományos szerkesztők egyszerű kezelhetőségével, az a fajta komplex editor, amiből komplett IDE is építhető, és lehetőségeiben felér a vim, Emacs, Kakoune, Visual Code, Atom, Sublime, Notepad++, stb. tudásához, komplexitásához.
A Vifm-ben sem kötelező vi-os billentyűket használni, át lehet teljesen konfigolni (gyári billkombók kinullázása unbind-del, nyíl billentyűkre mozgás, F1-F10-es gyorsbillentyűk, mint nc/mc-ben, stb.), de akkor szerintem az értelme veszik oda.
A vim-et meg azért nehéz tanulni, mert
1) ahhoz, hogy profitálj belőle, szerintem tudni kell gépírni
2) át kell álljon rá az agyad, mivel nem text editor igazából, hanem text processor, jobban hasonlít egy interaktív sed-re, mint egy text editorra. Ezért sok szerkesztési műveletet át kell fogalmazni, máshogy kell alatta megközelíteni, végezni, eltérő logikával. Ezt pedig nehéz szokni. -
vargalex
félisten
válasz
Shyciii
#7113
üzenetére
Ne a mobilod grafikus teljesítményét nézd, hanem a CPU számítási teljesítményét. Hiszen pl. a transmission nem a GPU-t használja! És ne is céges szerver kategóriát.
De hagyjuk, nem akarod megérteni, hogy a többség (Magyarországon) Core i3-nál jóval gyengébb CPU-kon torrentezik. És még a routeren torrentezést nem is említettem, ahol még csak nem is ARM, hanem MIPS architechtúrán tolják ugyan ezt.
Ezekhez képest írjuk itt mi az erős CPU-t. De ezt leírtam már az összes hozzászólásomban. Sehol nem írtam olyat, hogy nézd meg általánosságban. És valóban nevetséges, hogy csak részleteket ragadsz ki a hozzászólásaimból, a lényegén teljesen átsiklasz... -
vargalex
félisten
válasz
Shyciii
#7111
üzenetére
Ez az x86 világban igaz. De mondom, nézz szét a NAS-ok között. Sőt, sokan használják android boxokat linux-al ilyen célra, amik szintén ARM-el szeretlek.
A home szerver topicban pedig az a jellemző, hogy passzív hűtéssel ellátott lapokat használnak. Ezt az általad említett CPU-kkal nem tudod megtenni.
És még egyszer mondom, ne desktop vonalban gondolkodj! -
vargalex
félisten
válasz
Shyciii
#7109
üzenetére
Márpedig egy Core i3 nem csak egy RPi4-hez, hanem egy átlagos NAS CPU-jához (ami általában szintén ARM) igen is erős CPU-nak számít. Ezt kell elfogadni. Nem feltétlenül mai desktop CPU-khoz kell hasonlítani. Azoknak nyilván nem gond a gigabit. De nem is feltétlenül csak ARM-hez. Nagyon sokan, köztük én is "szar Celeron, meg Nxxxx-es" CPU-val szerelt lapokat (én konkrétan Intel J3455-öt) használnak otthoni mindenes szervernek. Elég lenne csak benézni a Home server / házi szerver építése topic-ba. Szerintem az én szerverem sem bírná a gigabitet torrentben 1 magon, persze kipróbálni nem tudom, mert 500 Mbps-es netem van. Szóval minden csak viszonyítás kérdése.
És ugye az eredeti kérdező nem is desktopról beszélt, hanem konkrétan az RPi-ről. Amit egyébként én sem használnék desktop eszköznek (még az operátorok számára sem).
-
vargalex
félisten
válasz
Shyciii
#7105
üzenetére
Azért egy bármilyen Core I3-at nem szabad összehasonlítani egy RPi-vel. Ég és föld a különbség. Láthatod, hogy nálad a transmission kihajtja a gigabitet, míg a kollégánál 80-160 Mbps-nél vége. Pedig a csúcs RPi-vel használja. Így nála teljesen jogos a több magos alkalmazás igénye.
-
Frawly
veterán
válasz
Shyciii
#7103
üzenetére
Régen, míg nagy seedállományom volt, és nagy tételben csapattam a témát, 300+ torrent seedelése ment 24/7-ben, 50+ GB feltöltés/nap, addig szükségem volt olyan funkciókra, mint különböző sebességlimitek, napi feltöltéslimitek, finom szemcsés prioritás fájloknál, torrentek közötti sortartás és prioritás kezelése, napi, heti, havi statisztikák, stb.. Akkor sok minden kellett egy torrentkliensből, csak az uTorrent meg qBittorrent jött szóba, a többi akkor a nyomába se ért ennek a kettőnek featureset-ben. Ma már alig torrentezek, azon belül is előfizettem inkább, így nem kell seedelnem annyit, ezért elég egy alap szintű torrentkliens is, annyi, hogy a torrentek közötti sortartást kezelje, meg hogy milyen fájlokat töltsön le a torrentből, mivel néha sorozatmegapakkokat töltök, de egyszerre csak 1-2 évadot belőle. Nagyon másra nincs igényem, alap szintű lett a torrentezésem.
Ez a qBittorrent ilyen régi szokásként maradt meg nálam, még azokból az időkből, mikor full featured bloat DE-t használtam, azon belül is KDE-t, meg Qt-s progikat. Azóta persze már rég nem ez a helyzet, ahogy egyre jobban elmentem a minimalizmus felé, de a qB egy olyan progi volt, ami túlélt eddig. Béke poraira. A végén már csak a Wine, Steam, Firefox, terminál marad a gépemen, ami GUI-s program, a többi mind CLI-s lesz. Esetleg a Thunderbird van még fent, ha a neomutt nem boldogulna valami e-maillel.
-
Frawly
veterán
válasz
Shyciii
#7094
üzenetére
Azt elfelejtettem írni az előbb, hogy most a transmission-cli-t fogom kipróbálni. Már régóta látom linuxos videókon ajánlva, de még nem használtam. Sok évvel ezelőtt használtam a transmission-gtk-t, de az kifejezetten nem tetszett, mert fapados volt, akkor meg én nagyon benne voltam a nagy szabású seedben, bonyolult grafikus kliensekben. Most viszont nem ez a helyzet, adok neki esélyt.
A transmission-cli nem csak CLI-ként használható, hanem böngészős webklienssel is. Azt sem próbáltam még.
-
Frawly
veterán
válasz
Shyciii
#7094
üzenetére
Nekem nem kéne GUI-s, de a qBittorrent eddig olyan jó volt, és annyira bevált, annyira a legfunkciógazdagabb linuxos kliens, hogy ezzel kivételt tettem. Egészen mostanáig. Ma viszont repült a gépről, mert még mindig nem javították ki a hibát, ennyi nap után sem, ami azt jelenti, hogy a belátható közeljövőben sem fogják. Tudtam egyébként, hogy nem szabad kivételt tenni, most meg is bántam. Töröltem, mert már másodszor fordult elő, hogy nem bírják időben lekövetni a libtorrent-rasterbar frissülését, ilyen banda szoftverét meg nem használom.
Nálam nem tett fel extrát a qBittorrent, mert a Qt-s dolgokat a Goldendict felrakta, igaz azt is dobni fogom majd, ha találok helyette jobbat.
rTorrentből nekem az hiányzik, hogy be lehessen állítani, hogy egyszerre csak x darab torrent töltődjön, a többi álljon sorba. Egyébként más vonatkozásban megfelelne, fapados, de használható.
-
Frawly
veterán
válasz
Shyciii
#6990
üzenetére
Ezeket egyik telepítőben sem lehet választani, mármint azokat, amiket írtál. Pont ezért nincs az Archnak eredetileg telepítője, hogy te építsd fel a rendszert, ha nem akarsz GRUB-ot vagy display managert, akkor nem telepítesz. Ez a rossz ezekben az előre gyártott installerekben, kicsi a mozgástered, hogy mit akarsz telepíteni, a particionáláson kívüli dolgokba általában nem tudsz beleszólni.
-
Frawly
veterán
válasz
Shyciii
#6956
üzenetére
De, minden OS ugyanúgy HDD-nek kezeli az SSD-t, mintha LBA szektorok lennének rajta. A Flash Translation Layer (FLT), wear leveling, garbage collection, meg egyéb belső működést az SSD aktív vezérlője végzi, és ennek a működési részét kitakarja mind a felhasználó, mind az OS felé, nem is enged ebbe belenyúlást, belehekkelést, részben garanciális, részben biztonsági/adatvédelmi okból.
Az SD kártya, pendrive pont ettől más, annak nincs aktív vezérlője. Ezért azok profitálhatnak az F2FS-ből. Lényegében az F2FS egyfajta Flash-vezérlést hajt végre, de ez SSD-nél lehetetlenségbe ütközik.
Sokakat az zavar meg, hogy az SSD is Flash NAND alapú memóriát használ, de a vezérlése egész más!
Az F2FS nincs túltolva, kevesen is használják. Csak 1-2 elvakult fan akarja túlszépítve eladni. Mondom, próbáld ki, nem romlik el tőle az SSD, meg az Arch is bootol, de meg fogod látni, hogy nem hogy semmiben nem gyorsabb, mint egy ext4, hanem lesznek dolgok, amikben egyenesen lassabbnak is érzed. Nem szabad az ilyen benchmarkolós tesztoldalak hülyeségének bedőlni. Ezt viszont nem kell elhinni nekem, tapasztald meg te magad.
-
Frawly
veterán
válasz
Shyciii
#6954
üzenetére
Oké, az SQLite indulását leszámítva ez az egy mérés valóban nem szintetikus teszt, hanem valós felhasználás. Bár még ez is kicsit szintetikusan lett kivitelezve a tesztben, mert a háttérben egyéb intenzív I/O benchmark futott szándékosan. Ez a valós felhasználásnál nem annyira jellemző, hacsak már nincs annyira határra tolva a gép, hogy nem maradt szabad erőforrás a háttérben.
Meg mondom, sok mérés kamu benne, mert az ext4 és btrfs nem ilyen 5× meg 10× lassabb, a komának a rendszerével volt valami gebasz. Az f2fs-nél még a btrfs is gyorsabb tapasztalatom szerint, ha nem kapcsolsz be btrfs extra feature-öket, bár ha ezeket meg nem kapcsolod be, akkor meg a btrfs-nek nincs értelme és lehetne helyette annyi erővel ext4-et is használni.
De erre már hívtam fel 1-2 éve is többször a figyelmet, hogy ez a Phronixos phószer mocsok elfogult a F2FS felé, én is az ő hatására próbáltam ki, de meg is bántam gyorsan. Mondom, ha nem hiszed el, tőlem kipróbálhatod, átformázod rá a partícióid f2fs-re, visszamásolod az adatokat, fstab-ban az UUID-ket kiigazítod, initramfs-ben az f2fs tool hook-ot beállítod, és teszteld vele a rendszert, vagy húzz fel egy másik rendszert f2fs-re, majd várlak vissza jelenteni, hogy nekem volt igazam.
Meg ez az F2FS nem a legjobb egyébként sem SSD-re. Azért, mert az SSD vezérlője úgyis HDD-s működést amulál az OS felé, meg NTFS fájlrendszerre van optimalizálva. Ez az F2FS olyan „buta” Flash eszközökhöz való, amelyeken nincs aktív vezérlés (SSD-n van, meg sem lehet kerülni), pl. pendrive, SD-kártya, azon valóban gyorsabbak lehetnek F2FS-sel, mint más fájlrendszerrel, főleg random I/O-ban, szekvenciálisban már nincs nagy különbség szerintem. De HDD-n meg SSD-n kb. 0 értelme van az F2FS-nek.
-
Frawly
veterán
-
Frawly
veterán
válasz
Shyciii
#6950
üzenetére
Ezt én is akartam linkelni a Linux OFF topikba, mert egy vicc. A Phoronix mindig az F2FS-t hozza ki győztesnek, de az én tapasztalatom szerint a leglassabb fájlrendszer, legalábbis nálam SSD-n, Archon. A leglassabb trimelésű, a leglassabb, mikor bootkor a fájlrendszer ellenőrzi a rendszer, a leglassabb, mikor alkalmazások indításáról van szó.
Nálam az ext4 vált be, villámgyors. Nem tud sokat, de azt rettenet széptempóban. Egész partíció szabad helyének trimmelése néháyn másodperc. Bootkori fájlrendszerellenőrzés <1 mp. Progik villámgyorsan indulnak vele, lényegében azonnal a képernyőre vágódnak.
Mondjuk ezt a NILFS2-t nem ismerem milyen, nem hallottam róla, nem próbáltam még soha.
-
Frawly
veterán
válasz
Shyciii
#6938
üzenetére
Olyat még nem láttam, hogy egy GPU a BIOS-ban nem volt letiltható. Bár én azért használnám, ha játszol is, mert játékok alatt a teljesítménye gyaníthatóan jobb, mint egy CPU-ba integrált megoldásnak, kivéve, ha nem nagyon modern prociról van szó.
Annyi, hogy ha mégis használod, akkor fel kell rakni a zárt NV drivert, az Arch hivatalos tárolójából a legújabb 440-es driverágat, nvidia és nvidia-dkms azt hiszem a neve. NV-ben nem vagyok otthon, utoljára még a korai XP-korszakban volt a kezem ügyében NV kártya (MX440, FX5200), azóta vagy csak ATi (9600, 9800) vagy AMD (HD2400, RX570), vagy integrált Intel (GMA3600, GMA950, X3100, HD2000, HD3000, HD4000), Linuxon is csak ilyeneket használtam. ATi-t is utoljára még Ubuntu 10.04 alatt talán.
Ha annyira le akarod tiltani, akkor talán a hozzá való csomagok eltávolításán túl le kell tiltani a hozzá tartozó kernelmodult, blacklist-ben, és akkor eleve már detektálni sem fogja a kernel, és a X.org sem.
-
Frawly
veterán
válasz
Shyciii
#6936
üzenetére
Talán másfél éve használtam F2FS-t, körülbelül. A tesztek már 5 éve gyorsabbnak hozzák ki akárminél, ennek a bullshitnek ne dőlj be. Tőlem felteheted, a mentő nem fog elvinni, de ne mondd, hogy nem szóltam előre. Persze nagy károkat sem okoz, egyszerűen csak lassabb, főleg ilyen betöltési időkben, fájlrendszer-ellenőrzéskor, trimkor. Egyértelműen érezni, hogy az ext4 fürgébb. Szekvenciális értékek meg nálam nem fontosak, mivel nagy másolásokat és fájlírásokat ritkán művelek.
Az az MX130 valóban nem egy nagy szám GPU, de egyes prociba integrált GPU-knál jobb lehet, kb. Vega8 szint. Erősen függ, hogy milyen Intel IGP-vel hasonlítjuk össze, mert azok is fejlődtek elég sokat generációról generációra. Bár ezt a „sokat” relatív fogalomként kell kezelni, mert egy kicsit is normálisabb dedikált asztali GPU-hoz képest így sincsenek fasorban sem. A mostani legújabb Intel GPU, az Iris UHD 630 kb. a GTX8800 szintjén van, ami egy 14 !!!!!! éves kártya. Az integrált AMD GPU-k kicsit erősebbek, kb. 2-3×-os a különbség, egy mostani AMD Vega 7 integrált laptop GPU kb. GT 740 szint, annál kicsit erősebb, ez már felzárkózás a 6 évvel ezelőtti szintre (bár erősebb asztali GTX kártyáknál inkább 8 évvel ezelőtti szint), 14 évvel ezelőtti szint helyett. Elvileg a Vega 11 egy kicsit erősebb, amit az asztali procikba integrálnak, kb. 1,5×, ezt elég nehéz belőni, hogy asztali GPU-ként minek felel meg. Főleg azért, mert benchmarkonként, játékonként, DX/OpenGL/Vulkan verziónként változik, hogy hol egyik kártya erősebb ebben-abban, hol a másik, vannak játékok, ahol egy átlagban egyenlő erejű kártya nagyon elhúz, driveroptimalizációk, játékoptimalzáció, több VRAM, gyorsabb fajta VRAM, vagy valami egyéb optimalizáció miatt nagyon fekszik neki, ezért nehéz a szinteket belőni.
Egyébként ez a Xorg-os példád is azt bizonyítja, amit írtam. Ilyen Zen installereket mellőzni kell. Olyanoknak készültek, akiknek nincs meg a tudása az Arch telepítésére. Neked megvan, fel tudod tenni kézzel. Kicsit hosszabb, kicsit lassabb, bár nagy rutinnal nem valami nagy idő.
Az viszont nem logikus, hogy leszedett driver mellett miért fogyasztott többet. Lehet valami mesa sw-render LLVMpipe drivert töltött be helyette, vagy nem tudom. Ilyet még nem láttam, hogy egy leszedett csomag nagyobb fogyasztást okozzon. De ezért is jó, hogy kézzel nekiállsz ezeket kikísérletezni, mert ezekből tanulsz, ezekből lesz rutinod, hogy milyen hardverhez milyen driverek, csomagok kellenek, így már kézzel is csukott szemmel fog menni a telepítés, csak felhúzod a csomagokat, és nem leszel semmilyen idiótáknak összeállított installerre rászorulva.
-
Frawly
veterán
válasz
Shyciii
#6933
üzenetére
Én használtam fél-egy évig F2FS-t SSD-n. Ne ülj fel a teszteknek, borzalmasan lassú. Érezhetően lassabb, mint ext4-gyel. Ráadásul mikor én próbáltam, az fstrim is bugos volt vele, igaz ezt javították.
Ha annyira akarod, próbáld ki, de csak akkor, ha mazohista hajlamaid vannak, és ne mondd, hogy nem szóltam előre.
(#6934) Bici: lehetni biztos lehet, valami AUR helpert lefordítani Debianon és ott futtatni, az meg tudja csinálni a forgatást, meg megcsinálja a csomagot, legfeljebb olyan paraméterrel hívod, hogy a kész csomagot ne próbálja pacmannal telepíteni.
Az Arch Wiki meg írja, hogy hogyan kell saját repót létrehozni.
-
Frawly
veterán
válasz
Shyciii
#6929
üzenetére
A 214 alap memóriafoglalás kicsit sok. Igaz nem irreálisan. Ha fent van az udiskie, nm-applet (ez feltételezi, hogy megy a NetworkManager is), akkor simán lehet a közelében. Nálam az Openbox minden ilyen nélkül kb. 170 MB közelében volt, csak az Openbox, polybar, picom kompozitor, feh háttérkép futott (még téma sem volt az ablakokon), meg a háttérben a wpa_supplicant és dhcpcd (Wi-Fi-hoz, ennek egy hátránya van, hogy megszakad kapcsolatnál nem kapcsolódik magától újra), meg ezt én systemd-mentes disztrón mértem (Void), semmi systemd, semmi homed, semmi loginmanager, semmi.
A másik, hogy ezek a task-manager típusú programok összevissza jelzik ki a szabad memóriát. Ezért én csak a free -m parancsot tartom hitelesnek, ez biztosan a kerneltől kérdezi le. Igazából még ebből is le kéne vonni a terminál és a free parancs fogyasztását, de ez elhanyagolható szokott lenni. De a htop is ugyanezt mutatja, csak az összeadja az used+share oszlopokat a free parancs táblázataiból. De a sima top, lxtask, gnome-system-monitor, stb. teljesen hülyeségeket szokott mérni. htop-ban a hres oszlop számít meg kicsit a shared, nem a mem%.
Nálam most Arch, SwayWM Wayland, swaybg, swaybar eszik összesen szintén 171 MB-ot. Igaz 201-ről indul, de miután leült a dhcpcd meg valamelyik systemd service futása, onnantól 171-re süllyed tartósan.
Nem csak a memóriafoglalás számít, hanem a betöltési sebesség is, igaz a kettő korrelál. Az, hogy most 30-40 MB plusz ide vagy oda, nem sokat határoz meg, lehet betöltési és bootidőben egy SSD-s gépen dob +2ms-ot. A lényeg, hogy nem olyan full DE-t futtatsz, ami indulásból bekajál fél-egy giga memóriát és vagy 9-10 mp-ig tölt bootkor, mire mindenféle service-t meg grafikus library hegyeket töltöget befelé.
Ezek a scriptek meg veszélyesek, mert egyrészt változik mindig az Arch telepítése, valamit mindig variálnak, amiről a script nem fog tudni. Meg rugalmatlan, mert mindig ugyanazokat telepíti, én pl. mindig egy kicsit máshogy telepítek, bár ez változóban van, mert ahogy megyek az egyre nagyobb minimalizmus felé, úgy már nincs nagyon alternatív dolog, amit variálhatnék, erősen szűkülnek a lehetőségek 1-2 programra. Ugyanezért nem szoktam régi rendszert visszaklónozni, mert a felhasználói szokásaim, alkalmazáskínálat is változni szokott, nem megyek semmire egy olyan rendszerrel, ami a fél-egy évvel ezelőtti szokásaimhoz volt kialakítva.
Az a baj, hogy így is kerül fel bloat a gépemre, AUR csomag telepítésekor, meg játékok, Steam is feltesznek egy csomó sallangot sajnos. Wine is bloat, meg az összes mainstream böngésző. Igaz ezek nem indulnak a rendszerrel meg ritkán is indítom őket a böngésző kivételével.
-
Frawly
veterán
válasz
Shyciii
#6918
üzenetére
Azt is kalkuláld bele, hogy legutóbb a base csomagcsoportból kivettek egy csomó csomagot, ami nem települ default. Emiatt kevesebb csomagod lesz.
Olyan nincs, hogy +30 megával több memóriafogyasztás, de a htop nem mutatja. Kapcsold be a rendszerfolyamatok mutatását is rajta. Linux kernel is hízik verzióról verzióra, systemd-nek is egyre több modulja fut, meg egyre több service-t futtat. Akár még X.org, kompozitor is ehet többet.
Én ilyen Zen installereket és scripteket nem alkalmazok. Nagyobb munka ezeket megírni, mint kézzel telepíteni. Úgyse telepítek gyakran, meg legalább így telepítéskor rá vagyok szorítva, hogy újra és újra elolvassam az Arch Wiki-t, így látom, ha valamiben változás volt.
-
Frawly
veterán
válasz
Shyciii
#6918
üzenetére
Ahogy ubyegon szokta mondani, ez a látóasszonyok topikba való. Innen ezt mi a látatlanban nem fogjuk tudni megfejteni. Neked kell tudni, hogy miket tettél fel, meg htop-ban vagy egyébben megnézni, hogy mi eszi a memóriát. Tippre gvfs vagy cups, vagy valami hasonló kiegészítő, addon.
-
Frawly
veterán
-
#63718632
törölt tag
válasz
Shyciii
#6871
üzenetére
Tudom, nem nagyon ajánlott, de én szinte realtime frissítek
.
A pamac indikátor ott csücsül a tálcán, aztán ha jelez. Megy a pacman -Syu, hiába állítottam 48 órára a keresést-figyelést. Mindíg jelez, amint van valami. Másra nem is nagyon használom csak erre, meg ha keresek valami csomagot. -
Frawly
veterán
válasz
Shyciii
#6857
üzenetére
Az Openbox nem dinamikus, hanem stacking WM, ami azt jelenti, hogy az ablakokat floating módban kezeli és azok részben vagy egészben átfedhetik egymást. Az Awesome dinamikus tiling WM, de azok között a legfelhasználóbarátabb.
Az xmonad nekem is magas a Haskell miatt. Akkor már inkább dwm, mert C-ül legalább tudok, az annyira nem átláthatatlan. Amit a dwm-ben nem szeretek, hogy mindenhez patchelni kell, és a patchek nem kompatibilsek automatán, hanem kézzel kell őket beszúrogatni, ami több patchnél egyre nagyobb munka, egyre kényesebb művelet. Igazából a legtöbb dinamikus tiler dwm-klón, az xmonad is, csak C helyett Haskell-ben írva, a Qtile Pythonban, a Spectrewm C-ben (de támogat külön konfigfájlt), stb.. Igazából az awesome is dwm-klónként indult, csak a nyelv változott, amiben írták (C, de konfigjában már Lua-ra épít), de eltávolodott tőle, ahogy adták hozzá a feature-öket.
vim-nél én is abszolút sorszámot használok, sortöréssel, és görgetésnél mindig a sor végére görgetődik le a képernyő, nem csúszik át sor a következő képernyőre (lastline opció). A wildmenu parancskiegészítés csak parancsmódban működik, kettőspont karakter után. Tényleg csak az abszolút minimumot használom a konfigomban. Pont amiatt, amit már írtam. Nem értek egyet azzal, hogy sokan szénné konfigolják, meg hozzáadnak 100 addont minden apró-cseprő dologhoz, és ha véletlenül vanilla vim-hez vagy vi-hoz kell leülniük, jól arcra esnek, mert nem bírják használni, hirtelen a spéci beállításaik és addontengerjük nélkül élhetetlen lesz nekik.
-
Frawly
veterán
válasz
Shyciii
#6854
üzenetére
Itt van a vimrc konfigom, de neked csak az első néhány sor kell (sorszámozás, sortörés, tört sor görgetése, automatikus parancskiegészítés, 24 bites színmélység, színtéma), a többi map, meg let részt még nem ajánlom, nagy részüket én se használom, a let rész meg csak azért van, ha oldalsáv nézetben fájltallózást nyitok meg vim-ben, annak a vizuális megjelenítését olvashatóbbá tegye, de ezt a feature-t is rettenet ritkán használom.
Elindulásnak a vimtutor parancsot ajánlom, meg ezt a netes játékot. Amíg megszokod a módokat, meg a szövegben mozgást.
Mikor én próbálkoztam először vim-mel, akkor elkövettem azt a hibát, hogy próbáltam annyira szénné konfigolni, hogy lényegében úgy működött, mintha csak egy normál szövegszerkesztő lett volna, működött az egér, kurzormozgató billentyűkkel navigáltam, nem kellett módot váltani, stb.. Na, ezt nem szabad, mert egyrészt így soha nem tanulja meg az ember, meg így pont az értelme, legjobb oldala veszik el.
-
Frawly
veterán
válasz
Shyciii
#6852
üzenetére
Az Xmonad nem Haswell-ben, hanem Haskell-ben van írva, de az nekem is meredek, ha ez megnyugtat. Pont a Linux OFF topikban hoztam elő ezt a funkcionális programozás témát, hogy mennyire elvont, erre le lettem oltva, hogy én vagyok hülye, mert ott a szakik a topikban már az 1930-as évek óta használják, meg möhőő, meg jóaz, nekik tökéletesen érthető. Értem, akkor májerkedjenek csak.
vim/neovim mindegy, de idő megtanulni. Nem is a billentyűk jelentését, hanem amikor vim-ben szerkesztesz, sok szövegszerkesztési problémát át kell fogalmazni, nem úgy kell csinálni, ahogy hagyományos editorokban. A vim ugyanis nem arra a filozófiára épül, mint egy hagyományos text editor, hanem egyfajta interaktív sed-nek lehet tekinteni, és inkább text processornak lehet nevezni. Külön meg kell szokni a módokat, az egésznek a logikáját, elsőre idegen lesz. Nekem is nagyon sokszor neki kellett futnom, mire sikerült megszoknom. A lényeg, hogy mikor tanulod, akkor nem a billentyűk memorizálása a legfontosabb, hanem egy újfajta gondolkodás elsajátítása. Eleinte idegen érzés lesz nagyon, mintha az orroddal vagy a lábujjaiddal kéne szövegszerkeszteni, nehezen boldogul vele, aki még csak most kezdte tanulni, türelmet igényel. Érnie kell a folyamatnak, ahogy formálja a gondolkodásod, nem lehet sürgetni, meg siettetni.
Meg igazából a vim-nek akkor van értelme igazán, ha tudsz gépírni. Az egész úgy van tervezve, hogy gépírástartásból legyen vezérelve, és nem nyúlsz ki onnan egérhez, kurzormozgató billentyűkhöz, stb.. A vim egyfajta speciális gondolkodásról, filozófiáról szól, amit ha megtanulsz, nem csak szövegszerkesztésre tudsz használni, hanem mindenfajta szoftver vezérlésére, vim billentyűkiosztást és logikát fogsz használni mindenhol, shell, terminál, fájlkezelő, böngésző, ablakkezelő, médialejátszók, stb.. Lényegében a gépet fogod teljesen máshogy használni, azt fogja eredményezni.
Egy jótanács: mindegy, hogy vim vagy neovim, ha tanulod, akkor próbáld alapállapotában használni, ne konfigold szét őket a saját jelenlegi berögződéseidhez. Ha változtatsz is a konfigon, csak egyszerű dolgokat, sorszámozás, sortörés, magyar nyelvi helyesírás-ellenőrző használata, stb., azaz csak pár sornyi alap dolgot tegyél bele a vimrc-be, de billentyűket ne nagyon szabj át, meg addonokat se telepíts, mert úgy nem a vim-et fogod megtanulni, hanem a saját konfigod használatát.
-
Frawly
veterán
válasz
Shyciii
#6841
üzenetére
Vifm-ből hívott csoportos átnevezés vim-ben grep/sed-szintaxissal:
:%s/[0-9]{2}/0\0/gNem teszteltem, de azt kéne csinálnia, amit írsz, a kétjegyű számokat (de csak azokat) átcseréli háromjegyűre. Ha látod a listán, hogy helyesen cserélt le mindent, a végén ZZ billentyűkkel kilépsz vim-ből, és visszakapod a Vifm-et, az átnevezett fájlokkal.
A „:” parancsmódba teszi le a vim-et, az „s” a substition rövidítése/parancsa (általános alakja s/keresett/cserestring/ formában szokásos), előtte a % jel azt jelenti, hogy az összes sorban hajtsa végre, ne csak az első sorban, a „g” a végén meg a global rövidítése, ami miatt egy soron belüli többször előfordulásokat is lecserél, ez az esetünkben nem szükséges, mert egy sorban egy egyezés lesz, de én megszokásból mindig gyűröm a végére a g-t. A [0-9] számjegyet jelent, a {2} pontosan két előfordulást egymás után (lehetne [0-9][0-9] formában is írni), a \0 a keresett kifejezést teszi oda az extra 0 után pluszban.
Nem árt megtanulni regexp-pül, mert nem csak csoportos átnevezéshez jön jól, de scriptekben, meg úgy általában linuxoknál, Unix-származékoknál, programozásnál, nem csak vim-ben, de bármilyen regexp képes editorban, prognyelvben, terminálban grep/sed-hez, még a Total Commander, Double Commander is támogatja alternatívaként a saját regexp formátumán felül. Előnye, hogy a Commader-ek [bla][bla] regexpjénél többet tud, rugalmasabb, igaz bonyolultabb is, és nehezebben olvasható.
Az awk-t én sem szeretem, túl bonyolult a szintaxisa, de ha oszlopszerű adathalmazból akarsz kinyerni oszlopokat, akkor arra viszont könnyebben használható, mint egy posix/grep/perl regexp.
(#6842) májkimiki: ez ilyen. Főleg, ha ilyen 2 magos, 2 szálas példányod van (vannak erősebb, 4 magos, 4 szálas modellek is), nuku L3 cache, alacsony órajel, alacsony IPC. Ahogy nézem, még hardveres virtualizációt sem támogat. Ha ez vigasztal, Windows alatt még sokkal rosszabb lenne.
-
Frawly
veterán
válasz
Shyciii
#6838
üzenetére
Vifm-nek nincs saját csoportos átnevezés-lehetősége. Vagyis van, de az nem saját, hanem más programot hív meg. Alapból úgy van a konfigja megírva, hogy a vim-et hívja meg, abban van a fájllista, amit kijelöltél, ott lenyomatod regexp mintákkal meg tételesen, hogy mit mire akarsz átnevezni, mentesz és kilépsz, és maguktól átneveződnek a fájlok, mappák.
Tehát alapból kijelölöd a fájlokat, majd cw, és előjön a vim, ha fent van nálad. De elvileg bármilyen szövegszerkesztőből csinálhatod, akár nano, akár más, akár még grafikus GUI editor is lehet, csak akkor a vifmrc-ben a vicmd-t át kell írni. A lényeg, hogy tudjon regexp mintákkal dolgozni a text editor.
Az Arch frissítés most nálam is problémás volt. Nem tört el semmit, jól működik a rendszer, de a frissítés nem akart lemenni, nss és lib32-nss lowfax miatt, /usr/lib/p11-kit-trust.so és /usr/lib32/p11-kit-trust.so fájlok már léteztek a rendszeren. Az --overwrite kapcsolót használva viszont már rendben lement a frissítés, és reboot után bugmentesen működik tovább a rendszer. Persze Archon is ritkán van ennyire durva frissítési hullám, évente max. 1-2×. Legtöbbször egy hét alatt max. csak ilyen 10-20 csomag jön össze 100-200 MiB terjedelemben (nálam), és azoknak a frissítése sem szokott problémás lenni.
-
Frawly
veterán
válasz
Shyciii
#6822
üzenetére
Fura. Ez szerintem valami script-lefutási hiba, nem a /tmp méretével függ össze.
Már eleve azt nem értem, hogy minek mp3-akat összetömöríteni, mikor azok már elve tovább nem tömöríthetők. Mivel eleve átmennek egy pszichoakusztikus adatcsökkentésen, majd egy Huffman-tömörítésen, tovább már semmi nem tud rajtuk tömöríteni.
-
Frawly
veterán
válasz
Shyciii
#6815
üzenetére
Redditen unixporn topik, meg YouTube videók, alattuk mindig meg van adva a git tároló a konfigfájlokkal, onnan sokat lehet meríteni. Nem csak Openboxhoz, hanem bármihez, sőt, új CLI-s terminálos programok felfedezéséhez is jó, amiket még nem ismert az ember. Na, meg a nagyobb YouTube-erektől is sokat lehet tanulni, videón mutogatják, hogy mi hogy működik, mit hogyan lehet konfigolni, mire kell figyelni, mire milyen alternatívák vannak. Ilyen csatornák, mint Luke Smith, DistroTube/Derek Taylor, Brodie Robertson, ne meg teljesen kezdőknek rettenet hasznos lehet Chris Titus Tech, gotbletu, és van még ilyen pár, ott volt valami amerikai orvostanhallgató csóka a vim/markdown témájával, az is nagyon hardcore-ban tolja, annak már nem is emlékszem a nevére. Egyedül ilyen politikus megmondólúzereket nem érdemes nézni, mint Bryan Lunduke, meg ilyen n+1. teszteljük a Gnome vagy XY disztró legújabb kiadását, mert most fedezték fel maguknak a Linuxot emberek, mint Switched to Linux, Linux bloke, stb., ezeket szerintem szimplán időpocsékolás nézni, annyira amatőrök.
-
Archttila
veterán
válasz
Shyciii
#6811
üzenetére
Koszonom!
Tiling nem kell, szoval akkor marad az Open es a polybar mert arra gondoltam, hogy ha mar ugy is valtok Debian/Xfce vonalrol akkor legyen ez egy nagy ugras, igy elengedem a DE-et es Arch/openbox/polybar vonalon elek tovabb.
(mindig is akartam egy minimal rendszert)Elkezdtem visszaolvasni 1000 hszt es azt kell mondjam rengeteg hasznos okossagot leirtatok mar
persze nyilvan lesz meg par kerdesem, de majd ugy is meglatjatok... -
Frawly
veterán
válasz
Shyciii
#6790
üzenetére
Végül is pastebin.com-ra beteheted idelinkelve. Bár én saját színkonfigot akarok, .Xresources fájlban beállítva, ahogy Luke Smith csinálja, nem is nehéz, de nem volt még időm kísérletezni, hogy milyen színeket adjak meg, hogy kell definiálni őket. Hosszú távon pywal-t fogok használni, ami a színsémát generálja.
-
Frawly
veterán
válasz
Shyciii
#6788
üzenetére
Hosszú távon én is az st-nél fogok maradni. Annyi, hogy annál a színeket akarom először belőni, hogy jó legyen, és utána állok át arra. Természetesen ez a Termite ideiglenes lesz csak. Közben a fura karakterek vim-ben is megoldva, Void bug miatt volt, lecseréltem a Termite-ot az Arch binárisra, az egyelőre nem bugzik. Meg Archra is visszaváltok. Újra se kell telepíteni, mert még megvan a régi telepítés, csak konfigfájlokat, új scripteket kell átmásolnom, meg befrissíteni, 2 hónapja nem volt használva.
-
Frawly
veterán
válasz
Shyciii
#6784
üzenetére
Ja, ez a másik, amit írni akartam. Ha nagyon minimalista valaki, loginmanager sem kell. Csak annyi a kényelmetlensége anélkül élni, hogy bejelentkezéskor be kell írnod a felhasználói nevet is, ami ugyan kényelmetlen, de biztonságilag meg plusz. Még többféle grafikus felület is indítható login manager nélkül, vagy startx után megadva mit futtasson az xinit, vagy a .bashrc-ben bekódolni, hogy ha tty1-ről jelentkezel be X felhasználóval, akkor milyen felület induljon el, ha tty1-ről Y felhaszálóval, akkor mi induljon, ha tty2-ről X felhasználóval, akkor amaz, stb.. Mindig az adott felhasználó .bashrc-jébe kell beleszerkeszteni.
Amire még jók a login managerek, az a képernyőzárolás, de azt meg lehet oldani egyéb lock screen progikkal is, akár GUI-sal, akár CLI lock-olós megoldásokkal konzolban.
Csomagfenntartó szerintem nem hülye, de mivel ő kizárólagosan használja szerintem a LightDM-et, így sose távolította el, és nem tűnt fel neki, hogy maga után hagy dolgokat.
-
Frawly
veterán
válasz
Shyciii
#6777
üzenetére
De, tudja alapból az mc. Options → Panel Options → Navigation → Lynx-like motion.
A Lightdm-et rég nem használtam, de az tényleg gáz, hogy maga után hagy szemetet. A felhasználóját távolítsd el az userdel paranccsal. Nekem anno az volt a bajom a Lightdm-mel, hogy instabil volt, igaz azt az akkori Intel GPU driver problémám is okozhatta.
-
Frawly
veterán
válasz
Shyciii
#6774
üzenetére
Kurzorbillentyűkkel a mappák között mozogni az mc is tud, ezt Lynx-módnak hívják. A hjkl gombokkal mozgást pedig vi/vim-módnak.
Eltávolításnál a pacman -Rns kapcsolókkal szedd le a csomagot, mert az minden vonatkozót töröl elvileg, nem csak a függőségeit, hanem konfigfájlokat, meg mindent. Ennek ellenére igazad van, 1-2 rosszul megírt progi, meg csomag hagy maga után szemetet, hiába távolítod el. Igaz ez csak fájlszemét, nem fut, nem foglal memóriát, csak felemészt egy apró tárhelyet, használatban nem lévő fájlokat hagyva maga után.
Meg az is következetlen, hogy a szabvány az lenne, hogy a progik a ~/.config/programnév/ mappába tartják a beállításaikat, erre számos különc progi a ~/.programnév_fájl és ~/.programnév_mappa/ helyen tárolják, ebből meg zagyvaság lesz a home mappában. Szóval a Linux sem tökéletes, valóban.
-
Frawly
veterán
válasz
Shyciii
#6772
üzenetére
A ' jel, egyfajta aposztróf karakter, Shift-et nyomva tartod, és magyar billentyűzetkiosztáson megnyomod hozzá az 1-es billentyűt, ezzel kapsz a Vifm parancssorában (alsó sor) egy ' karaktert.
Olyan, mint a nem nyomdai, hanem írógépes idézőjel ("), de ez csak egyszeres írógépes idézőjel, amit aposztrófnak is használnak.
Az 'a - 'z-vel csak azt akartam írni, hogy a ' jel után begépelek egy tetszőleges, de előre beállított betűt. Minden betű másik mappára van nálam drótozva. Ha a 'c parancsot írom be, akkor az a ~/.config mappába visz. Ha a 'm parancsot, akkor az a mountolásra használt mappámba. Ha a 't parancsot, akkor az a Torrent mappába. A 's a script-es mappámba. Ezeket a vifmrc-ben konfigoltam be kézzel, pl.
mark d ~/Downloads/Ezt a fenti sort 'd segítéségével érem el. De te megadhatsz akármilyen betűt (lehet kisbetű, nagybetű, de szerintem még szám is), sőt, stringet is:
mark blaBla /hozzá/rendelt/mappa
Ezt meg a 'blaBla néven éred el. Nyilván ez már nem lenne praktikus, mert sokat kéne hozzá gépelni. A mark-oknak pont az lenne a lényege, hogy max. 2 billentyűleütésből eléred a rendszeresen használd mappáidat. Ezek a markok olyanok, mint böngészőben a bookmarkok.Az a baj, hogy a Vifm neked kényelmetlen lesz, ha pl. nem tudod használni folyékonyan a vim-et, de szerintem gépírni sem árt hozzá (ahogy vim-hez sem). Sok Vifm-es parancsot akkor fogsz megérteni, ha tudsz vim-ül. Pl. a cw, amire a fájl átnevezése jön elő, azt nem a térdükből szopták a Vifm-esek, meg nem a Burdából vették az ihletet, hanem a vim-nek is van egy cw parancsa, ami ott a change word (egész szó lecserélése). Csak mivel a Vifm nem szövegszerkesztő, hanem fájlkezelő, így ebben nem szavakat, hanem fájlnevet cserélsz le. De pl. ezeknek a mark-oknak a kezelését is egy az egyben a vi/vim-ből vették át. Meg a kijelölés módot is (v vagy V), a G-vel az utolsó sorra ugrást szintén, és még lehetne sorolni sokáig.
Ennek ellenére átszabható minden Vifm-es billentyű, ilyen mc-s, meg Total Commanderes stílusúra, csak sokat kell hozzá konfigolni, meg a Vifm egyik előnye veszne el vele. A vim-mel is ott szokták elrontani a kezdők, hogy minden billentyűparancsot átszabnak, engedélyezik az egeret, kurzorbillentyűket, hogy a Sublime, Atom, Visual Code, stb.-t utánozzák, de ezzel meg a vim lényege veszik oda, a modális-gépírásos filozófia.
-
Frawly
veterán
válasz
Shyciii
#6770
üzenetére
A legutóbb használt két mappa között ' ' (Shift+ 1 1 a magyar billentyűzeten) gombokkal tudsz váltani. Én a :media parancsot nem is használom, az összes fontos mappának adtam könyvjelzőt, amik között 'a - 'z mark-okkal váltok. 'm nálam a külső meghajtók felcsatolására szánt mappa, míg pl. a 'd a ~/Downloads és tudok közöttük váltani.
A .jpg fájlok szűrése: =.jpg Nem kell csillag vagy ilyesmi, csak simán ezeket a billentyűket kell nyomni. Így csak a jpg-ket filterezi be, és VG billentyűkkel az összeset ki tudod jelölni. Lehet elvileg egyszerűbben a :highlight paranccsal, de azzal most nem jön össze. A = jeles filtert zr billentyűkkel, vagy másik mappába átváltással tudod nullázni, mert csak ideiglenes szűrő.
Csak permanens törlésnél megerősítés: vifmrc-be set confirm=permdelete
A megadott kiterjesztésekre tudsz programot megadni a vifmrc-ben. Van benne már pár sor, hogy hogyan kell csinálni, azok alapján készíthetsz saját mintákat, hogy milyen fájltípust mivel nyisson meg megnyitásra, szerkesztésre, konzolban, vagy GUI alatt.
-
Frawly
veterán
válasz
Shyciii
#6768
üzenetére
Lehet valahogy meg is lenne oldható, csak a vifmrc-be kéne hegeszteni hozzá saját makrót, vagy saját scriptet hívni.
Zipet egyébként a Vifm is megnyit, a fuse-zip csomagot kell neki feltenni. Ezt fejlesztik is. Aminek viszont abbamaradt a fejlesztése: rar2fs, fuse-7zip, ne ezekkel van probléma.
-
Frawly
veterán
válasz
Shyciii
#6764
üzenetére
Bele tudna, ha a fuse-hoz fejlesztett rar2fs és fuse-7zip modult nem lennének lusták a fejlesztők karban tartani. De mivel lusta genyók, ezért nem fordulnak a kódok, egyre több disztró tárolójában nem találhatók meg ezek a csomagok, és így igen, ennek híján a Vifm nem tud ilyen tömörítvényekbe belenézni. A Double Commander saját plugineket használ erre, így annak nem gond.
Bár még így sem lehetetlen ezeket a tömörítvényeket Vifm-ben kezelni, hogy ha ilyen tömörítvényre bekonfigolsz egy RAM drive-ba vagy tmpfs-be történő automata kibontást, vagy valami spéci automata felcsatolást, és akkor kvázi bele tudsz nézni ezekbe. mc-nél is járható út ez.
Egyébként az mc-nek azért van sok kötöttsége, mert nagyon konzervatív, meg sok mindenben az nc-t akarja utánozni. A Vifm meg modern fájlkezelő, és az nem akar semmit imitálni, a vi/vimes irányításon kívül, így az szabadabban konfigolható, könnyebben, rugalmasabban témázható.
-
Frawly
veterán
válasz
Shyciii
#6760
üzenetére
Legutóbb MS-féle cab meg wim fájlokban kellett belenéznem, hogy windowsos fontokat szedjek ki belőlük. Vagy pl. a Vifm régen ki bele tudott nézni .rar-ba, de már nem fejlesztik a rar2fs modult hozzá, amit használna, már AUR-ból sem fordítható le, eltört. De pl. most legutóbb tar.zst-be se tudott nekem belenézni a Vifm, bár azt Double Commanderrel sem próbáltam még.
Az rTorrent teljesen jó, egy nagy hátránya van, nem tud torreteneket sorba állítani prioritás és letöltési sor szerint, hogy egyszerre csak x db. torrent töltődjön, és az is prioritás szerint. Én emiatt fogom most nemsokára feltenni a Transmission CLI-t. Ha ilyen prioritásos, sorbaállítós igényed nincs, akkor viszont az rTorrent tud minden mást.
Korábban qBittorrentet használtam, az egy korrekt progi, nagyon sokat tud, de Qt-s, és baromira eszi az erőforrásokat. Ugyanaz, mint a Double Commander, de pepitában.
Pythonnal az a bajom, hogy bloat. Bár egyre többet használom matekszoftverekben, meg pl. Curse Radio, PyWal is abban íródott. De ha egy mód van rá, kerülöm, mert bloat nyelv, bloat alkalmazásokat írnak benne.
A modarin256 mc-téma nekem is tetszik, azt használom, de csak mc-ben. Vannak egyébként nála jobb témák, a vimcolors oldalon lehet ihletet meríteni. Vifm-ben jelenleg klasszik kék Norton Commander színsémát használok, egyfajta retrós hatás miatt, mc-ben azért van modarin 256, hogy jobban elkülönüljön.
Bár nekem a színséma mindegy, csak legyen sötétebb, ne legyen túl nagy kontrasztos, ne égesse ki a szemem, és ne legyen ízléstelen, ne legyenek benne rikító színek. A kedvencem a Mozilla Bespin színtéma, de nem rossz a Dracula, Nord, Gruvbox, Solarized Dark, stb. sem. PyWal is szép témákat tud random összehozni a háttérkép alapján, lásd Luke Smith videóját. De nem rossz a Code Dark színséma sem, ami a Visual Code(ium) témája, ezt most legutóbb egy ausztrál gyereknél láttam, egész pofásan néz ki neki neovim-ben Fire Code Mono betűtípussal, az lf is egész jól néz ki neki.
Nálam a színséma már csak azért sem számít annyira, mert átlátszó a terminál, és mikor átlátszó részben valami, akkor fakóbbak, kevésbé kivehetőek a színek, csak valami sötét háttér látszik, meg olvashatók, színesek legyenek benne a karakterek és kész.
-
Frawly
veterán
válasz
Shyciii
#6757
üzenetére
A Vifm sem tud futni önmagában, kell neki a terminál. De ez kifizetődik, amikor már sok terminálos alkalmazás van nyitva, akkor egy csomó libet közösen használnak, nem tölti be mindegyik példány a sajátját. Így 10-15 terminál alig foglal többet memóriában, mint 2-3.
A Tux Commandert rég néztem, akkoriban évekkel ezelőtt nem találtam rossznak. De aztán mikor fő rendszerként váltottam Linuxra, akkor a Double Commandert tettem fel. De mióta áttértem csak terminálos alkalmazásra (mpv, firefox, játékok kivételével), így terminálos fájlkezelésnél maradok. Megmondom őszintén, a Double Commander hiányzik, mert elég zseniális, sokat tud. De hát nagy bloat progi egy terminálos megoldáshoz képest. Néha napján mégis előveszem, ha valami olyan különleges tömörítvénybe kell belenézni, amit a Vifm nem kezel.
A trash-kezelését sose bántottam Vifm-nek. mc-ben nem tetszik, hogy a nézeteit és a billentyűit nem lehet normálisan testre szabni. Vifm-et teljesen testre lehet szabni és saját scriptekkel, makrókkal bővíteni. Na, meg a hatékonyabb vim-es irányítás is mellette szól. Az mc csak a fájlstruktúrában tud vimes billentyűkkel mozogni, de ezzel kifújt.
Nézegettem még Rangert, de a Python miatt kiesik, kerülöm az abban írt alkalmazásokat, és még ott van az „lf” (LF kisbetűkkel), amit még nem próbáltam. Az nnn fájlkezelő sem jött be, nekem túl kevés, amit nyújt.
-
Frawly
veterán
válasz
Shyciii
#6753
üzenetére
A konfigfájl maga a dokuemtáció Vifm-nél, abba nézz bele, lehet a /usr/share/doc/vifm vagy hasonló mappában lesz egy példaconfig, amit a ~/.config/vifm/vifmrc formában elmentesz, tudsz is használni, meg át tudod szerkeszteni.
A Vifm-nek pont az a lényege, hogy alapból vi-os billentyűkkel működik, cselesen azért is kezdődik vi-jal a neve. Kifejezetten azoknak készült, akik már jók vi/vim használatában, teljesen elsajátították, és szeretnék a fájlokat is ilyen módon kezelni. De átdrótozhatsz bármilyen billentyűre bármilyen funkciót, illetve törölhetsz is róla. A billentyűdefiníciókat ugyanúgy kell írni, ahogy vim-ben.
Pl. tegyük fel, hogy F2-re be akarsz drótozni átnevezést. A ~/.config/vifm/vifmrc konfigfálj végére beteszed ezt:
nnoremap <F2> cwLehet elegánsabban is, de nem tudom mit hív meg a cw billentyűs átnevezés, valami ilyesmit:
nnoremap <F2> :renameVan egyébként a Vifm-nek doksija, ezen az oldalon.
-
Frawly
veterán
válasz
Shyciii
#6740
üzenetére
A kijelzőméret relatív, mert az is számít, hogy milyen közelről nézed. 4K felbontásnak meg valóban nagyobb képátlón van értelme, kicsin sem mutat rosszul, csak a kicsi kijelző nem profitál belőle.
Abban igazad van, hogy néhány tiling WM-ben alapból van ablakdísz, de nagyon minimalista, skin nélküli, egyszínű valami. Általában ezeket is eltünteti az, aki ilyen WM-et használ. Skinezni sem lehet ezeket az ablakdekorációkst, csak ki-be kapcsolni, meg bekapcsolt állapotban a színét megadni (ami lehet transzparens is általában, de kivétel biztos ebben is van, ha támogatott is, akkor is kell kompozitor is hozzá). Háttérképnek valóban nem sok értelme van tiling WM-en, hacsak nem használsz az ablakok között rést. Én nem használok, de én szeretem, ha valami szép háttér fogad, és arra nyitom az alkalmazásokat.
A Konsole-ról pont azt írom én is, hogy bloat. Csak példának hoztam fel. st-ből jó a Derek Taylor-féle változat is. A lényeg, hogy ne gyári default st-ből indulj ki, mert azt elég nehéz normálisra bekonfigurálni meg patchelni.
Képmegjelenítés azért kell terminálba, mert néhány terminálos fájlkezelő tud képekről előnézeti képet mutatni, ami hasznos, illetve w3m böngésző is tud ilyet, szintén terminálos. Na most már, ebben az st régen elvérzett. Persze csináltak hozzá patch-t, amit egyébként ráhegeszteni se nehéz, kivéve, ha több másik patch-csel használod együtt, mert akkor rémálom. De azt hiszem, hogy a Luke Smith-féle st patchelve van erre is, talán a Derek Taylor-féle is.
-
Frawly
veterán
válasz
Shyciii
#6736
üzenetére
Ami a terminálokat illeti: nekem a Termite jött be legjobban. Azon terminálemulátorok közül, amik még nem olyan bloatak, mint a Konsole, Gnome-Terminal, xterm, LX Terminal, stb.. A legnépszerűbb most linuxos körökben az Alacritty, de nekem nem annyira jön be, annak ellenére, hogy most én is ezt tesztelem. Kevesebbet tud, nehezebben konfigurálható, kicsit szerintem lassabb is. Valahogy most nagy hype van az Alacritty körül, mert új, meg GPU gyorsított, de ez utóbbi sem számít, mert ha fut hardveres GPU gyorsítást (OpenGL-t vagy Vulkan-t) használó kompozitor a WM felett, akkor úgyis minden alkalmazás kirajzolása GPU gyorsított lesz, az is, ami eredetileg nem volt az.
Az st nem lenne rossz, ha nem kéne minden egyes fontos funkcióhoz patchelni, raádásul a patch-ek is össze tudnak veszi. Alapból nagyon fapados az st, se átlátszó hátteret nem kezel, se görgetést, se truecolor megjelenítést (24-32 bites színmélység), se semmit, problémás a Unicode-emoticonok és néhány betűtípus megjelenítése, képek megjelenítése benne. Ezekre mind van st-patch, de mivel azok meg összevesznek, nehezen szabható testre, egy kínlódás normálisra megcsinálni. Megoldható persze, csak nagyon nem kezdőknek való. Aki mégis megpróbálná, az a Luke Smith-féle st-verziót használja az AUR-ból (megnézve hozzá Luke Smith legutóbbi st-s videóját a YouTube-on), az patchelve van mindenre, full extrássá, igazából viszont ilyenkor az st-nek a minimalizmusos előnye veszik el lényegében.
Igaz a Termite a legjobb, de annak is vannak hibái. Állítólag valami nem rendezett licencű vagy problémás frissítési modellű komponenst használ (már nem emlékszem pontosan), ami miatt nincs benne a disztrók 90%-ánál a hivatalos tárolókban, ráadásul nagyon sok függősége van a fordításának, nem magának a proginak, csak a fordításának. Ezt Gentoo-n tapasztaltam, hogy milyen nagy kínlódás forráskódból pörgetni, Void-on még nehezebb volt. Archon mázli, hogy benne van a hivatalos tárolóban, csak ezt a hajára kenheti az, aki mégse Archot használ, meg nem Arch-vonalat, mert pl. kiadás alapúságot vagy LTS-t akar, vagy systemd-mentes disztrót akar, így meg a Termite nekik egyből nem tűnik a legfrankóbb választásnak. Így most nincs egyértelműen mindenki számára legjobb terminálemulátor. A minmalistábbak st-vel és Termite-tal nyomják, illetve az egyre népszerűbb Alacritty-vel, a full extra bloat DE-s felhasználók meg a DE-jük terminálját használják, ami legtöbbször Gnome-Terminal, KDE-n a Konsole. Ez megint attól függ, hogy ki mire használja a gépet, milyen stílusban, milyen disztrót, WM/DE-t futtat. Vannak emberek, akik annyira GUI only-k, hogy szinte sose szednek elő terminált, amikor csak lehet, elkerülik, nekik meg mindegy. Aki viszont 90-99%-ban terminálos alkalmazásokat használ, annak meg baromi fontos, hogy milyen terminált használ, hiszen a böngésző mellett a legtöbbet használt program a gépükön.
-
Frawly
veterán
válasz
Shyciii
#6734
üzenetére
Tiling WM-ből kettőféle van: automata vagy más néven dinamikus tiler az egyik, ilyen a dwm, spectrwm, Qtile, xmonad (ez a négy ráadásul mind dwm-klón, csak más prognyelveken írva, a dwm és spectrwm C-ben, a Qtile ugyanaz, csak Python-ban, az xmonad meg megint ugyanaz csak Haskell-ben írva, és ezek közül mindegyiket azon a nyelven kell konfigurálni, amelyben írták), bspwm, Awesome WM, meg úgy általában a tiling WM-ek 90%-a dinamikus, amelyeknél egy előre eldöntött szisztéma szerint nyílnak és méreteződnek, illetve rendeződnek a megnyitott progik ablakai.
A másik fajta a tiling WM-eken belül a manuális tiler, i3wm, SwayWM (i3wm-klón csak Waylandre), StumpWM, Musca, Ratpoison. Ezeknél nem megadott szisztéma szerint nyílnak az ablakok, hanem neked kell kézileg nyomni gyorsbillentyűkkel, hogy hova nyíljon, ez pedig egyben meg fogja szabni, hogy mekkora mérete lesz.
A másik nagy csoport a tiling WM-ek mellett a stacking WM-ek, ezek a hagyományos ablakkezelők, amelyeknél nem csempékként rendeződnek a programok, hanem egymást átfedni tudó ablakokban, ilyen a WM-ek 90%-a, meg az összes Desktop Environment-ben lévő WM. Stacking WM-nél másik különbség, hogy az ablakoknak vannak fejlécei és diszitései is, míg tiling WM-eknél nincsenek, legfeljebb csak ablakkeret, vagy opcionálisan rés az ablakkeretek között, igazából ezek nem is ablakok, meg ablakkeretek, hanem csempék és csempekeretek (opcionális), és csempék közötti rések (opcionális).
Egyébként ezek a memóriafoglalási számok, amiket írtál, nekem soknak tűnnek. Nálam az Openbox foglal kb. 170 MB memória körül Polybarral, és feh háttérképpel. Igaz nálam nem fut semmilyen systemd-s szutyok, se gvfs, se dokk, se semmi. Egy Bspwm még ennél is kevesebbet kéne foglaljon, 130-150 MB körül, dwm 130-hoz közel. Mármint összfogyasztásban, amiben minden benne van, nem csak a WM.
Egyedül az i3wm-es és Qtile-os számaid tűnnek reálisnak, bár azokat is kicsit sokkalom.
Amit írsz, hogy 3 ablak fért egymás mellé tiling WM-ekben és nem láttad bennük rendesen a tartalmat: pont ezért mondtam múltkor, hogy a tiling WM-eknek akkor van értelműk, ha nagy felbontást használsz, és ki is tudod használni, mert nem extrém kicsi képernyőn nyomod (12 col meg alatta), bár a képernyőméret is relatív, mert attól is függ, hogy milyen közelről nézed. De ahogy múltkor beszéltük, még az is eltér, hogy milyen progikat használsz. Aki tiling WM-et használ, az egy olyan célközönség, hogy ők 90-99%-ban terminálos alkalmazásokat használnak fix szélességű fonttal, és 99%-ban billentyűzetről, nem egereznek. Te meg kb. 90%-ban GUI-s alkalmazáskat használsz változó szélességű (proporcionális) betűtípussal, és inkább egérrel dolgozol, ami meg a stacking WM-eknek fekszik inkább.
Én két okból adtam fel a tiling WM-eket: 1) a laptopomon pitscha kis felbontást kell használnom 1366×768, ezeken csempézni esélytelen, mert bélyegkép méretűek lesznek az alkalmazások, 2) az összes tiling WM-nek fogyatékossága, hogy ha fut az előtérben egy full screen vagy stacking módban futni tudó alkalmazás, akkor nem tudnak róla átváltani másik, háttérben futó alkalmazásra, mert nem létezik nekik „háttér”, amiben futna akármi is.
Ahogy én használom a gépet, azt tabbed WM-nek vagy fullscreen WM-nek lehetne hívni, talán inkább az előbbi, de használom az utóbbi módot is, ezek félúton vannak a tiling és a stacking WM között. Tabbednél maximális ablakban futnak a progik, de látszanak a panelek is (vagy alul, vagy felül, ez mindegy), esetleg opcionálisan az ablakkeretek és fejlécek, full screen-nél meg az utóbbiak nem látszanak, csak az alkalmazás maga foglalja el az egész képernyőt. A felhasználásom nekem a tiling WM-hez áll közelebb, mert nincsenek ablakdiszítések, se ablakkeret, se ablakok között rés, billentyűzetről irányítok mindent (sehova nem kattintok, se panelre, se alkalmazásindító menübe), így lényegében maximalizált képernyős tiling WM-ként használom most az Openboxot is, ami pedig stacking.
A Fluxbox és az Openbox elég hasonlóak, ugyanannak a Blackbox nevű WM-nek a leszármazottjai, klónjai. Csak Fluxboxon kapsz egy panelt is, meg egy-két dolgot, ami Openbox-ból hiányzik, meg talán konfigurálni sem XML-ben kell.
-
-
Frawly
veterán
válasz
Shyciii
#6712
üzenetére
Ezt a 120-140%-ot nem tudom értelmezni. Értem, a 100%-hoz képest, de mi a 100%? Kinek a szemére van az mérve? Ez kb. így magában olyan, mint a 50%-kal dúsabb L'Oréal szempillák. Most lehet én vagyok gyépés, de nem tudok ezekkel mit kezdeni.
A Polybart én is használom, de egy alapabb, gyári defaulttól alig eltérő konfiggal, egyszerű fekete sáv, fehér betűszín, minden jobbra igazítva. Azt nem is tudtam, hogy ilyen jól is tud kinézni. Nekem az nem kell, hogy kattintásra mindenféle jöjjön elő, pláne nem ilyen GUI-s programok, mint az lxtask (htop-ot használok helyette). Mondom, ez felhasználásfüggő is, mert te meg én egész máshogy használjuk a gépet. Te többségében GUI-s programokat használsz arányos betűtípussal és egérrel kattintgatsz funkciókért, én terminális TUI programokat monospace betűtípussal és szinte mindent billentyűzetről vezérelek, leginkább vim-stílusban. Ezt nem értette a másik topikban ubyegon, hogy nem lehet mindent egy felhasználó igényei és szemlélete alapján meghatározni, nem mindenkinek a Mentás Cinmanó lesz az etalon. Nekem sem mindig ilyen volt a felhasználásom, fokozatosan alakítottam ezt ki, és még a jövőben is fog folyamatosan még minimalistább, keyboard only irányba tovább változni.
-
Frawly
veterán
válasz
Shyciii
#6707
üzenetére
Azért, mert nem jó a szemed, vagy messziről nézed a kijelzőt. A szemem nekem sem jó, vagyis ahogy nézzük, mert közellátó vagyok, így közelre inkább jobban látok, cserébe távolra meg szarabbul, szemüveg kéne, de nem hordok. Nekem most egy 12 colos ThinkPad X220 van a mellkasomon (ágyban pihenek), eléggé beletolva az arcomba, simán látom leméretezve is. De tény, hogy ezek az apró betűk fárasztóak.
Kétpaneles fájlkezelőket meg nem is nagyon érdemes tilingban futtatni, hacsak nincs 2K/4K felbontásod. Ezek anno pont azért jöttek két panellel egy helyett, hogy egyfajta tiling effektként több infót jelenítsenek meg egymás mellett, több infót tudjanak zsúfolni ugyanakkora területre. Tilingban úgy lenne értelme, hogy 2-3 darab 1 paneles fájlkezelőt futtatsz.
Egyébként meg attól is függ, hogy TUI vagy GUI programokat tilingolsz-e. A GUI-s programokban változó szélességű fontok vannak, pl. az i sokkal kevesebb helyet foglal, mint egy m. A TUI-s programok ugyebár monospace fontokat használnak, amik sor/karakter arányban azonos méretnél jobban pazarolják a helyet, viszont lekicsinyítve jobban is olvashatók (a screenshotodon a terminál a legolvashatóbb). Te ahogy látom, GUI-s progikat használsz inkább, én meg TUI-sakat, Writer helyett vim, Double Commander helyett vifm.
Egyébként mi ez a panel nálad felül? Elég jól néz ki, a neve mellé konfigfájlt is linkelhetnél. Előre is kösz.
-
Frawly
veterán
válasz
Shyciii
#6694
üzenetére
Nézd, nem vitatkozni akarok, meg azt úgyse vitatnám, hogy normális 1-2 monitoros desktop megoldás a legjobb. De akik ilyen 2 monitorral, meg többféle programmal egyszerre dolgozó fejlesztők, azok úgyse laptopon fognak dolgozni, és nem csak a kijelzőméret miatt.
Én csak annyit mondok, hogy de, a laptop képernyője is alkalmas lehet már tilingra. Inkább függ a felbontástól, mint a tényleges képátlótól. Meg attól is, hogy kinek milyen jó a szeme. Nyilván egy értelmes szintig, mert 5-12 colon nyilván nem sok mindent lehet csinálni, még full screenben is pici, komoly, tartós munkára alkalmatlan ez a méret.
Én egyébként a laptopon full screenben nyomatok mindent, kivéve párbeszédablakok meg 1-2 spéci progi (PCem), ami nem hajlandó teljes képernyőre skálázódni. De erre a szükségmegoldásra is inkább az alacsony felbontás visz rá, 1366×768. Néha, ha kell valami, akkor két részre van osztva a képernyő és ennyi. Ez is ritkán, és többet nem tuszkolok egymás mellé, mert nem látnék belőle semmit.
Szerintem Borland Delphit nem nagyon használ már senki. Régen sem volt népszerű, most meg kb. a kutya sem. Max. a meglévő kódokat fordítgatják vele, de még azokat is inkább FreePascal fordítóval (ami Delphi- és Object Pascal kompatibilis is). Mondom ezt úgy, hogy én régen éveket programoztam Borland Pascalban, és anno szerettem, de eljárt felette az idő, bánom, hogy nem C-t tanultam már akkor is helyette.
-
vargalex
félisten
válasz
Shyciii
#6700
üzenetére
Hát, nem tudom. Én Oracle-ben vagyok járatos. Megfelelő indexeléssel, particionálással nem lesz gyorsabb, áttekinthetőbb, ha szétdobod... Persze valószínűleg azért dobod szét, mert nincs particionálás. Egy bérszámfejtő alkalmazáshoz tartozó adatbázisban nincs annyi különböző adattípus, ami indokolná azt a sok táblát.
-
-
vargalex
félisten
válasz
Shyciii
#6696
üzenetére
Persze, nálunk is hazahozhatta mindenki a munkaeszközeit. Ezzel nincs gond. Nyilván kényelmesebb a nagyobb monitor, de nem létszükséglet. Volt olyan fejlesztő kollégám, aki még a külső monitort sem használta.
Viszont az XML egy sorában 400 karekterből bármilyen beágyazás esetén (normális formázás mellett) a töredéke információ, a többi csak tab... -
Frawly
veterán
válasz
Shyciii
#6688
üzenetére
Az Xfce-t fel lehet témázni szépre, de akkor nem lesz lightweight. Főleg azóta nem, hogy Gtk3-ra álltak át. A Gnome-ról írtakkal maximálisan egyetértek.
Tilingnak lenne értelme laptopon is. Csak akkor nincs értelme tilingozni, ha kicsi felbontást használsz, vagy kevés terminálos alkalmazást, vagy nem tudod jól kezelni a billentyűzetet, állandóan le kell nézni, idegenkedik valaki tőle. Min. FullHD felbontástól van értelme, olyan embereknek, akik majdnem csak kizárólag terminálos alkalmazásokat használnak, és billentyűzetkezelésük is vagy haladó, vagy tudnak gépírni. Annak, aki kis felbontást használ, ilyen 1366×768, 1280×720, 1280×800, vagy ezek alatt, annak nem nagyon ajánlom, hacsak nem szereti a mikroszkopikus méretű fontokat. Az 1400×900 határeset lehet. Meg annak nem jó még a tiling, aki ilyen GIMP, Darktable, Blender, KDEnlive, Davinci, meg ahhoz hasonló, nagyon GUI heavy programokat használ, ahol 8 ablak, 20 toolbar, 100 ikonnal, tele párbeszédablakokkal, ezt a helyzetet nem szokták a tiling WM-ek jól lekezelni.
Ami a kolléga problémáját érinti, hogy bizonyos mappákat ki akart zárni a fájlkezelőből, doksik megnyitásánál: én ezt fzf-t használó Bash scripttel oldom meg, ami vim-ben nyitogatja a doksikat, erőforrásigénye is 0. Ez WM független, megy bármilyen grafikus felületen, nem kell ilyen mime-akármikkel szenvedni, meg 1000 GUI-s szemét között kibogozni, hogy melyik lehet a hunyó.
-
Frawly
veterán
válasz
Shyciii
#6674
üzenetére
Memóriafoglalásra nem vettem észre jelentős különbséget. Abban viszont egyetértek, hogy a GPU gyorsítás nem számít, mert ha a WM felett fut kompozitor vagy be van kapcsolva X.org-on a DRI hardveres gyorsítás, akkor úgyis OpenGL gyorsítani fog minden X.org-os alkalmazást, Firefox, xterm, urxvt, Termite, Alacritty.
Termite-ot én is jobban szeretem, a vim-kijelölésmód miatt. Ez az Alacrittyből hiányzik, meg a görgetése is elég primitív az utóbbinak, Ctrl+Shift+PgUp/PgDn-ra görget, és csak sok sornyit, egy soros görgetést nem találtam benne, ami gáz.
Így csábítana a Termite vissza, de Archon kívül egyik disztró tárolójában sincs meg, így fordítani kell jellemzően, és a fordításának rohadt sok függősége van. Én meg gentoo-zni akarok később, és nem akarok emiatt szívni.
Amivel most kísérletezek, az a Luke Smith által módosított st, azaz a suckless-féle Simple Terminal. Egyedül a színek nem stimmelnek, azért nem vettem még használatba.
-
Frawly
veterán
válasz
Shyciii
#6658
üzenetére
Poén lenne, de Void-hoz nincs ilyen. Egyébként meg mi használná ezt az issue fájlt? Nekem a Void ASCII logója sem tetszik neofetchben. Béna, az Arché jobb.
De a voidosoknak egyébként is jó lenne lecserélni a mostani logót, ez a két félkörben egy pötty elég béna és semmilyen, valami dizájnantitalentum tervezhette. Mondjuk egy pipa jel ötletesebb lenne: ✓vagy ✔, esetleg kicsit szögletesítve, hogy nehogy valaki Nike márkajelnek nézze. Esetleg ilyen vonalasan 3D-ben eltolt nagy V, azaz kb. \\// vagy hasonló.
-
Frawly
veterán
válasz
Shyciii
#6651
üzenetére
Úgy értve a kompatiblitist, hogy elkezdesz scriptelni rá, és van pár olyan megoldása, ami normál Bash-on meg sh-n nem fog menni. Hozzászoktat ilyen nagyon baró, de spéci megoldásokhoz, és ha majd egy sima bash-os géphez kell leülnöd, akkor gondok lehetnek belőle, hogy nem mennek a zsh-n megszokott dolgaid.
.
Új hozzászólás Aktív témák
Hirdetés
BoB
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Iphone 16E 128GB Fekete Bontatlan 24 Hónap Garancia
- Beszámítás! Apple Mac Studio M2 MAX 2023 32GB 512GB SSD számítógép garanciával, hibátlan működéssel
- BESZÁMÍTÁS! Microsoft XBOX Series X 1TB SSD fekete játékkonzol extra kontrollerrel dokkolóval
- Alkatrészt cserélnél vagy bővítenél? Nálunk van, ami kell! Enterprise alkatrészek ITT
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest