- Azonnali alaplapos kérdések órája
- Kormányok / autós szimulátorok topikja
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Milyen notebookot vegyek?
- Androidos tablet topic
- Apple MacBook
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Fujifilm X
- Vezetékes FEJhallgatók
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
-
PROHARDVER!
Arch Linux topik
Új hozzászólás Aktív témák
-
vargalex
félisten
válasz
Shyciii
#8603
üzenetére
Akkor én a kivétel vagyok, OpenWrt van a routereimen (és a rokonoknál lévőkön, akiknél én állítom be) már a kezdetektől. Még White Russian-al kezdtem 2007-ben...
A pkttype-nak 5 különböző értéke van, amiből az unicast és a host azonos jelentéssel bír... Mondjuk abban egyetértünk, hogy reject helyett egy drop jobb lenne... Nem kell tudatnuk vele, hogy él a host.
De gondolom az alap config nem egy ajánlás, csak egy példa, ami egyébként működőképes.
-
vargalex
félisten
válasz
Shyciii
#8601
üzenetére
A legtöbb esetben úgyis van előtte egy router, ami ezeket már be sem engedi... És ugye ezek az input láncon vannak engedélyezve, ami egy LAN-on csücsülő headless eszköz esetén pont jól jön.
Nem néztem át tüzetesen a config-ot, de az 5/second-os rate limit nem global beállítás minden kapcsolatra? -
Siriusb
veterán
válasz
Shyciii
#8599
üzenetére
Köszönöm!
Arch-on így néz ki az alapbeállítás:
❯ cat /etc/nftables.conf#!/usr/bin/nft -f# vim:set ts=2 sw=2 et:# IPv4/IPv6 Simple & Safe firewall ruleset.# More examples in /usr/share/nftables/ and /usr/share/doc/nftables/examples/.table inet filterdelete table inet filtertable inet filter {chain input {type filter hook input priority filterpolicy dropct state invalid drop comment "early drop of invalid connections"ct state {established, related} accept comment "allow tracked connections"iifname lo accept comment "allow from loopback"ip protocol icmp accept comment "allow icmp"meta l4proto ipv6-icmp accept comment "allow icmp v6"tcp dport ssh accept comment "allow sshd"pkttype host limit rate 5/second counter reject with icmpx type admin-prohibitedcounter}chain forward {type filter hook forward priority filterpolicy drop}} -
-
Archttila
veterán
válasz
Shyciii
#8558
üzenetére
Nem baj, igazabol annyit valtozott a tortenet, hogy mar nem kell olyan gyakran kulso eszkozoket csatolgatni, szoval most nincs fent semmi, manual mountolok ha szukseg van ra.
Valakinek mukodik ez az Arch Wiki-ben talalhato ipv6 disabled guide? [link]
/etc/sysctl.d/40-ipv6.conf
## Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.enp1s0.disable_ipv6 = 1restart service, reboot, de tovabbra is ott virit
ip addresskiemeneten a v6
A Kernelt-t parameterezve mukodik, de inkabb tiltanam systemd-vel, ha mar adott ra a lehetoseg...
systemd, LAN, enp1s0 -
Archttila
veterán
válasz
Shyciii
#8553
üzenetére
Vegul feladtam
(pedig nem szokasom) mert barmit csinaltam nem sikerult eltalalni a megfelelo jogosultsagokat, szoval maradt az udisks2 egy csinositoscripttel:[alucard@arch ~]$ mnt.sdb1Mounted /dev/sdb1 at /run/media/alucard/8a986e8a-8daf-4954-8f4e-39a4fb38e602[alucard@arch ~]$ umnt.sdb1Unmounted /dev/sdb1. -
válasz
Shyciii
#8473
üzenetére
a service-re persze, hogy azt írja, hogy dead, mert nem önmagától fut, hanem a timer indítja.
én nem is erre utaltam.
ha megnézed, a saját logomat, amit odamásoltam, nekem is azt írja, hogy dead, alatta viszont ott van a journalctl vonatkozó logja, amiben látszik, hogy 6-án hajnal fél2-kor lefutott.
ha kiadod asystemctl status fstrim.serviceparancsot, neked is látszódni fog ugyanaz, amit a journalctl-ban is látsz.
growlernek viszont nem volt ilyen alatta. -
#68216320
törölt tag
válasz
Shyciii
#8400
üzenetére
Ezt tudom, de sajnos nem működik.
Csináltam már desktop fájlt, pl. az imwheel-t így indítom, de valamiért az xrandr-t nem szereti.
Próbáltam direktben indítani, azaz a desktop fájlba írni a paramétereket a paramétereket is, de próbáltam a script-et is, amit jelenleg kézzel indítok folyton. Egyik megoldással sem tetszik neki.
Igazság szerint jó volna valami DE-től független megoldással indítani, mert ha feldobok esetleg egy i3-at vagy bármi mást, akkor ne kelljen ezzel külön foglalkozni.
És persze user független is jó volna.
Nincs valami systemd paraméter arra, hogy várjon a DE betöltésre és csak azután fusson le egy xrandr paraméterezve? -
-
Archttila
veterán
-
Siriusb
veterán
válasz
Shyciii
#8373
üzenetére
Persze, akár openbox-ot, akár gnome2-t használtam, biztos, hogy kevesebb erőforrás kellett neki. Sőt, mondok jobbat, nekem jobban kézreáll a GTK, amikor python-ban UI-t készítek, mint a QT.
Amikor fiatal voltam, én sem haboztam mindent beállítani a saját számíze szerint pl. openbox-ban, de most már nem érdekel. Amennyire kell, testreszabom oszt' csókolom. Tudom, egyszer kell rászánni az időt, de régebben szerettem ezt meg azt kipróbálni, és végül maradt a kde. Például Dolphin-nál vagy SMplayer-nél jobbat én nem találtam és a Dolphin-t nem volt jó gtk környezetben használni. Viszont ezért (is) jó a linux, mindenki azt csinál, amit akar! -
-
-
-
-
anorche1
őstag
válasz
Shyciii
#8118
üzenetére
Igy jonak nez ki, koszonom szepen!
Egy masik problema:
Teamviewer i3 -alatt nem indul el. Szolgaltatas fut. Terminalbol inditve semmi hibat nem dob, szerinte elindul. Htop -ban lattok is jo par teamviewer processzt, amit rootkent inditottt htopban sem tudom sigkillel kiloni.
Otlet? -
anorche1
őstag
válasz
Shyciii
#8100
üzenetére
Akkor itt lesz a kutya elasva.
Ugye ez manjaro config file, de en arch -ra xtermet telepitettem. Az URxvt -re meg azt hittem valami hulye jeloles, amit meg nem ertek. Nem hittem, hogy egy masik terminal app
Mindenesetre valahogy az xterm is dolgozik ebbol, mert a szinek ugyanazok lettek mint manjaro alatt.A 9x15 -os font meret nem valami raszteres jeloles egyebkent?
-
anorche1
őstag
válasz
Shyciii
#8096
üzenetére
Koszi szepen!
Mas:
Egy i3 -as rendszert csiszolgatok, es egy dologra nem birok rajonni. Hogyan tudom a xterm font meretet novelni? Tul aprok a betuk.
Picit csaltam, a manjaro i3 -as .Xresources fajljat hasznalom, nem sajatot irtam. Ezt itt talaljatok:
[link]
Mit kellene atirnom, hogy nagyobb betuket kapjak? -
Archttila
veterán
válasz
Shyciii
#8095
üzenetére
Értem.
Közben felfedeztem egy érdekességet.
archinstall scriptnél amikor ahhoz a részhez érsz, hogy mit pakoljon fel (0.desktop, 1.minimal, 2.xorg) leave blank meg nem tesz fel semmit, szóval a tegnapi leave blank 160 csomagjával szemben az 1-es minimal csak 140 csomagot telepit.
Gondolom ez bug, mivel a leave blank-nál lenne logikus a 140, minimalnal meg a 160.Mindenesetre érdekes.
Köszi a scriptet
-
Archttila
veterán
válasz
Shyciii
#8090
üzenetére
achinstall script:
Nálam telepítés után a free -m parancs 66MB-ot mutat, a neofetch pedig 161 csomagot. Ebbol a htop és a neofetch utólag került telepitésre, szóval 159. (bár lehet van benne feleslegesen egy networkmanager csomag is)![;]](//cdn.rios.hu/dl/s/v1.gif)
Az általad készített scriptet még editálom
illetve az alapinstall (így hogy már rendesen működik a gyári) felesleges meló, de a post-tot jó lenne majd valamikor összekalapálni. 
Frawly komát miért függesztették fel?
Mit gondoltok, az install script milyen hatással lesz a disztróra nézve? Szerintetek többen neki fognak futni a telepítésnek mint korábban?
Szerintem remek kezdeményezés.
Tényleg pikk-pakk vele az install. -
Frawly
veterán
válasz
Shyciii
#8056
üzenetére
Azért szerintem a 8 ajánlottabb. Nagyon keservesen, de beleférnék én is a 4-be, de akkor a rendszerhez swapot kell tartani, meg én rendszeresen vagyok 3 giga felett, és akkor már gyakran elkezdené használni a swapot is. 8-nál is kell még a swap, de akkor szinte csak nagyon ritkán nyúl hozzá. 16 gigánál meg átlagosabb desktop felhasználásnál teljesen elhagyható a swap.
Egyébként igen, nekem is ment le az idők folyamán a memóriaigényem, eleinte KDE-vel meg Cinnamonnal kezdtem, meg egy időben Chrome-ot is használtam. De aztán ahogy lett előbb mindenféle kisebb DE, majd WM-ek, Openbox, i3, Sway, dwm, egyre inkább ment lefelé. De ehhez nem csak a WM-ek járultak hozzá, hanem ahogy telt az idő, egyre inkább több programom terminálos lett. Régen pl. használtam LibreOffice-t, GUI-s text edittort, torrent, stb., ezeket fokozatosan kiváltottam terminálos megoldásokkal.
Ennek ellenére a memóriafogyasztásra figyelek. Minden gépemben 16 giga van (bár két laptopnál levesz belőle az integrált GPU is), és általában a nagy része üres, de mégis figyelek erre, mert elsősorban innen mérni le, ha valami megoldás bloat. Ha sok memóriát eszik, és nem azért, mert nem férne bele, de amelyik progi sok memóriát használ, annak a szutykainak a betöltögetésével a procinak is időznie kell, többletfeladata van, sanszosabb, hogy más I/O műveleteket (lemez) is jobban igényel akkor, az meg növeli a reagálási időket, pár ms itt, pár amott. Hiába bika a proci, javarészt egy szálon töltődnek ezek a szutykok.
Ez nagyon szépen tapintható a két véglettel. Egy KDE pl. 8-9 mp. alatt tölt be SSD-vel is. Ugyanez egy minimalista WM-mel, konzolos bejelentkezéssel harmada, majdnem negyede is lehet időben. És nem a gép lesz gyorsabb, egyszerűen csak kevesebb mindent kell a procinak betöltögetni, kevesebb utasítást kell végrehajtania, kevesebb minden olvasódik be háttértárról, és a sok kicsi meg összeadódik. De ugyanez van betöltési időknél egy terminálos progi betöltődése még ms-ben sem nagyon mérhető, míg egy nagyobb GUI-s alkalmazás, ami ugyanazt csinálja, azért több msec vagy akár majdnem másodpercben is mérhető késéssel töltődhet be. Azért nagyon nem mindegy, hogy valami azonnal vágódik a képernyőre, még az embernek a billentyűt sincs ideje felengedni, vagy van-e egy kis töltögetés.
Persze a másik végletre is figyelni kell, mikor valaki pótcselekvésből túl sok RAM-ot vesz. Pl. a DistroTube csatornán az amerikai faszi, eleve 32 giga RAM-mal vette a mostani gépét, abból is általában 20+ giga állandóan kihasználatlanul állt, mivel minimalista tiling WM, terminálos alkalmazások, kevés grafikus progi (böngésző, OBS felvétel 1080p-ben, KDEnlive videóvágás 1080p-ben, néha 1 szál VM). Erre pár hónapja bővítette 64 gigára. Nyilván semmi nem lett gyorsabb, most már 20-30 giga helyett 52-62 giga áll üresen. Ráadásul ez az a mennyiség, amit már a kernel cache-elésre se használ el, ez ilyen abszolút pocsékolás, pénzégetés, pótcselekvés, e-pénisznövelés.
De ugyanezt játszotta el a procival is. 12 magos, 24 szálas Threadripper 1920-ast vett, amihez drága, spéci alaplap is kell. Elégette rá az értelmetlenül sok pénzt anno, mikor megjelent. Közben meg egy 1600-2600-as Ryzennel (plusz egy normális B450-es AM4 alaplappal), simán jobban járt volna, az is 6 mag, 12 szál, bőven elegendő lett volna neki, de még akár gyorsabb is lett volna, mivel egy mag magasabb órajelre turbózik fel (hiszen egy magra több Watt energiakeret jut). De ha 6 mag nem elég, egy Ryzen 2700X (akkor még nem jelent meg a 3xxx/5xxx sorozat) mindenképp már sok lett volna neki, de a proci-lap csak töredékébe került volna. Ugyanígy, 32 helyett vett volna 16 gigát, azért ezen a szinten nagy különbségek vannak. Ezt megfejelte Radeon VII workstation kártyával, amit megint nem használ ki, néha napján játszik csak, akkor is 1080p-ben. Akkor már jobban járt volna egy jóval olcsóbb RX5700-zal, felébe sem került akkor, játékokban talán még kicsivel több fps-t is kapna. Ez az, hogy az overkill hardvernek a legtöbbször nincs értelme. A többletpénzt meg beletehette volna több/nagyobb SSD-be, akárhány TB-ba, vagy lecserélhette volna a 3 darab FullHD monitorját 4K-ra, vagy vett volna még jobb kamerát, az értelmesebb pénzköltés lett volna, ha már a pénz mindenképp égette a zsebét.
-
Frawly
veterán
válasz
Shyciii
#8009
üzenetére
A GRUB egy hulladék, az eltörik Ubuntun, Minten, meg mindenhol. Archnak előnye, hogy ott ki is kerülheted, ha nem teszed fel a GRUB-ot, akkor nem lesz mi eltörjön. Illetve, de, a rendszergazdának van erre ideje. Mert ez a munkája. Ha túl nehéz neki, elmegy szenet lapátolni, vagy munkanélkülinek.
Abban viszont egyetértek, hogy a Linux sem tökéletes. Az Arch sem. Ma már az OS-ek, böngészők kódbázisai olyan nagyok, hogy áttekinthetetlen kódméret, főleg, ha a csomagokat is hozzávesszük. Ráadásul egyre inkább rohannak a verziókkal. Nem csak a rolling, a Win10, fejlesztők, stb. is.
#8010 Sonja: nálam simán jó. Települ és működik az mc. Semmilyen PGP hiba nincs. Pedig semmilyen ilyen refresh-keys mókolást nem ejtettem meg.
Ilyenkor általában megéri egy pacman -Syu parancsot kiadni, mert az, ha van új keyring csomag, akkor azt is befrissíti, és utána menni fog az mc.
-
attilav2
őstag
válasz
Shyciii
#8005
üzenetére
Nekem még nem volt olyan hogy frissítés után ne bootolt volna be, igaz nem is nvidiát használok aminek csak zárt drivere van, az egy kernelfrissüléskor lehet megfagy bootkor, szerencsére amd vga-m van. Olyan már párszor volt hogy a KDE-t úgy hazavágta egy update hogy nem indult, de akkor használtam másik desktopot. Tv tuneremhez dkms-es drivert használok, volt hogy kernelfrissüléskor nem fordult le, de attól még bebootolt a rendszer, csak a tuner nem működött, néhány hét múlva javították a driverét, nem létfontosságú mert tv-m is van.
-
Frawly
veterán
válasz
Shyciii
#8005
üzenetére
Nekem még sose volt olyan, hogy egy Arch ne bootolt volna frissítés miatt. Soha!!! Volt, hogy frissítés tört el ugyan dolgokat, nagyon ritkán (kb 2 évente egyszer) 1-1 progi crachelt, meg produkált olyan bugot, amit workarounddal, csomag downgrade-del, stb. kellett megoldani (ilyenkor is megoldható pár perc alatt), de olyan sose fordult elő, hogy az egész rendszer enblock bootképtelen lett volna, meg rendszer nélkül maradtam volna akármikor is. Az is igaz, hogy nálam ez még Windowszal sem fordult elő, csak hogy 1-1 nem tetsző driver kékhalált okozott, de ilyenkor is elég volt egy csökkentett módú újraindítás, és a driver eltávolítása, vagy eszköz letiltása.
És itt azt kell érteni, hogy nem csak az Archot védem, meg istenítem, hanem igazából ez bármilyen disztróra igaz. Még talán BSD-kre is, ha a cég megtanulja magának megoldani, talál hozzá szakembert, akkor szinte bármilyen elterjedtebb modern OS-es ökoszisztémán el lehet lenni, annak bármelyik disztribúciójával.
-
attilav2
őstag
válasz
Shyciii
#8000
üzenetére
Ebben a leírásban külön van az efi és a boot partíció, én jobban szeretem ha egybe van. A youtubeon vannak LUKS Arch telepítési videók, de többnyire Grub-osak, nem tudom miért ragaszkodnak annyira a Grub-hoz, mikor a systemd-boot sokkal egyszerűbb, mondjuk systemd mentes rendszeren érthető, de itt Arch LUKS telepítési videókról van szó, nem az Arch egy systemd mentes forkjáról ahol érthető ha Grub-ot használnak. Artixon én is Grub-ot használok, efistub meg hasonló csak uefi nvram-ba író megoldások jöhetnének még szóba Grub helyett, de ha átrakom a lemezt egy másik gépbe akkor már nem bootolna mert a másik gép uefi-jében értelemszerűen nincs ott a bejegyzés.
Egyelőre a jövő zenéje lesz a titkosított ökoszisztéma, mert csak akkor van értelme ha minden adatomat letitkosítom, a külső lemezeken levőket is, a külső lemezeket valószínűleg bitlockerrel oldom majd meg, hogy win alatt is használhatóak legyenek. Linux alá van bitlocker megnyitó tool, csak nem tudom mennyire stabil. -
attilav2
őstag
válasz
Shyciii
#7998
üzenetére
Egy leírást te vagy Frawly vagy más hozzáértő csinálhatna a titkosított(LUKS) kézi telepítésről, mondjuk kezdetnek egy egyszerű 2 partíciós telepítéssel ( / /boot), swap nélkül
Csak a / lenne titkosítva, systemd-boot-al. Virtuális gépben meg lehet csinálni és akkor képekkel is tudjátok illusztrálni -
Frawly
veterán
válasz
Shyciii
#7967
üzenetére
Ez néha ugrál, majd mikor 178-at ír, akkor hagyjad futni a watch free -mw parancsot, és látni fogod, hogy egy idő után (10-20 mp.) visszaugrik ~140 MB környékére. Az teljesen jó. Le lehet menni egyébként ez alá is, de csak systemd-mentes disztrón, és annyira ultraminimalista megoldásokkal, hogy szerintem nem éri meg, mert használhatatlan lesz a gép, nem tudsz hatékony workflow-t kialakítani. Ez a ~140-170 MB ez teljesen jó, már kellően minimalista, hogy atomgyorsan, pattogósan fusson, de még kellően rugalmasak ezek a bspwm, Sway, stb. szintű dolgok, hogy bármilyen workflow-ra be tudod configolni őket.
#7968 attilav2: Nyilván úgy a Sway-nek meg a akármilyend-ket elhagyó minimalizmusnak nincs értelme, hogy a sok KDE által feltelepített szutyok továbbra is fut, meg mindenből olyan progikat használsz, amik betöltik a Qt-hegyeket. Minimalista rendszernél nem csak az OS meg az init service-ek minimalisták, hanem a progik is, többségében terminálos, CLI-TUI megoldások. Nyilván nem mindenben, mert pl. a grafikus bloat böngészőket nem lehet kiváltani, meg ha kell Wine, Steam, videóvágó progik, vagy hasonló, akkor annál sem lehet megúszni a bloatot. Ez nagyban attól is függ, hogy mire használod a gépet.
Egyébként a KDE-vel, Cinnamonnal, stb. sem lenne baj, csak bloat és nagyon windowsos szemléletű. Ennek ellenére kezdőknek kiváló, az első linuxos hónapjaikban, de ha már elértél egy szintet, akkor érdemes túllépni rajtuk.
Épp így, ahogy a kolléga is észrevette, hogy felesleges a GRUB, meg ahogy te is észrevetted, hogy felesleges a systemd-networkd, meg egyéb szutykok, úgy még elég sok ilyen sallangot lehet kilőni, ha ezeket nem tölti be a gép, máris sokat gyorsul a boot, betöltési idők, stb.. Csak azért, mert a gépnek nem kell betöltenie egymásra épülő sallangokat. Ezt nem érti ubyegon, hogy nem arról van szó, hogy ezek a sallangok ne férnének el 8-16 GB RAM-ba, hanem mikor ezeket kell a RAM-ba töltögetni, akkor az a procinak is munka, a felhasználnak plusz latency, és mindegyik csak egy apró, pár msec, de mikor sok ilyen egymásra épülő szutyok összejön, egyik 10, másik 50, harmadik 100 megákat töltöget be, akkor tudnak belassulni a dolgok.
systemd-mentes Archot viszont nem ajánlom. Még többet is foglalnak a memóriából, mert egyszer fut a saját initrendszerük, meg még rá a különböző systemd-pótló megoldások (elogind), és ezek együtt többet kitesznek, mint ha csak systemd-t használnál önmagában. Persze próbálkozhatsz vele, pl. Artix Linux, hátha bejön, de sok előrelépésre ne számítsál.
Főleg akkor nagyon kínszenvedés a systemd hiánya, ha ilyen KDE meg hasonló megoldásokat futtatsz, mert azok extrán igényelni szokták a sok szutykuk futtatásához. Gnome, Xfce is.
Igazából a Sway is támaszkodik a systemd-re, de csak a logind részére, de még ezt is át lehet hidalni elogind nélkül, a Gentoo Wiki-nek van erről valami cikke emlékeim szerint, hogy scripttel hogy lehet ezt kiváltani.
-
attilav2
őstag
válasz
Shyciii
#7967
üzenetére
Akkor minimalista rendszert használsz. Nálam legalább 2-3 giga minimum, gondolom a KDE miatt. Szoktatom magam a Sway-hoz, de még ott is 1.5-2giga a foglalás egy idő után gondolom a sok háttérszolgáltatás amit a KDE felrakott. Szerencsére legalább 4 ssd-m van a gépbe így tudok különböző rendszerekkel kísérletezni, ki kell próbáljam a minimalista Arch telepítést, vagy egy systemd mentes Arch klónt, ez utóbbiból tudtok ajánlani párat?
-
Frawly
veterán
válasz
Shyciii
#7950
üzenetére
Szerintem ez nem kell, ha amúgy nincs problémád a bootolással és a GPU-t használó alkalmazásokkal, akkor nem szükséges belebarmolni az mkinitcpio.conf-ba. Ha viszont van, és Intel GPU-t használsz, akkor igen, az i915-öt a MODULES sorba bele lehet tenni, próbaképp. Azért írtam fentebb, hogy nálam ez amdgpu KMS driverrel működött, de akinek hasonló problémája van, hogy nem megy neki valami, vagy esetleg bootkor a kernel behányna ilyen zavaró hibasorokat, akkor ezzel a beállítással sanszos, hogy megszabadulhat ezektől. Rémlett, hogy egy oldallal ezelőtt egy másik kollégának két AMD-s gépen is volt ezzel gondja, egy dedikált és egy integrált AMD GPU-val is.
Ilyen intel_agp meg kötve hiszem, hogy manapság kell bárkinek is. Ez valami nagyon régről maradhatott benne a Wiki-ben.
-
attilav2
őstag
válasz
Shyciii
#7941
üzenetére
Nos, nekem a chromium engedett bejelentkezni/syncelni FreeBSD alatt. Verzió: 88.0.4324.182 (Hivatalos verzió) (64 bites) ez van a chromium névjegye alatt. Lehetséges hogy csak az újabb verziókból vették ki a google sync lehetőséget a google kérésére, lehet hogy nem az api támogatást vonták meg? Gyanús hogy így lehet. FreeBSD alatt meg egy ideje nem frissül valamiért a chromium. Nem portsból van, nem forrásból pörgettem, pkg install -al felrakott csomag. Mondjuk beleőszülnék mire ezen a gépen lefordulna a chromium
AMD X4-860K 8GB, kb 5 évvel ezelőtti vas, de még akkor sem a legerősebbek közé tartozott. -
attilav2
őstag
válasz
Shyciii
#7941
üzenetére
A brave-t ajánlani tudom! Elég stabil. Tedd fel a google-chrome ot AUR-ból és szinkronizáld le amit kell, majd tedd fel a brave-bin-t AUR-ból és az első indításnál felajánlja a beállítások/könyvjelzők átvételét másik böngészőkből, kiválasztod a chrome-t és szépen beimportálja magának amit kell. A brave beállításaiban bekapcsolod a szinkronizálást, generálni fog egy jelmondatot ez lesz a jelszó, mentsd el,(újra telepítéskor jól jöhet).
brave-dev-bin AUR csomag is van, ha az új featureok hamarabb kellenek, bár ez nyilván a stabilitás rovására megy. -
Frawly
veterán
válasz
Shyciii
#7941
üzenetére
Ja, akkor gyári Chrome. Sokat a Chromiummal úgyse nyersz, mert 99%-ban amúgy is megegyezik a Chrome-mal, meg ha úgyis mindent Google accountba szinkronizálsz, akkor annak az 1% (többieknek mondom: nem kötözködni, csak hasraütésszerű számok) sem fog különbözni.
Igazából szerintem ma már mindegy mit használsz, mindegyik browser egy bloat szar lett. Én azért maradok a Firefoxnál, mert testreszabhatóbb, mint a Chrome-alapúak, és legalább ennek a használatával nem a Google egyeduralmát támogatom.
-
Frawly
veterán
-
Frawly
veterán
válasz
Shyciii
#7911
üzenetére
Na, látod. Megint beigazolódik, amit mondtam.
A find parancs helyett én is fd-t használok, mert tényleg gyorsabb. Én fzf-fel vegyítem, tehát fd . / | fzf és így pár billentyű lenyomásából ki tudok választani listáról dolgokat, gyakran csak 1-2 billentyű. Én így nyitom meg az összes mappát, dokumentumot, már Vifm-et is ritkán használok. Így tényleg baromi gyors, hogy benyomom a gyorsbillentyűt, előjön a lista, 1-2 billentyűre kiválasztom a megnyitni kívánt mappát, fájlt (ezekre külön gyorsbillentyű van), és azok azonnal megnyílnak a nekik fenntartott alkalmazásban, mindegy hány mappa mélységben vannak a jelenlegi pozíciómhoz képest. Ez kb. 1000× gyorsabb, mint a hagyományos GUI-s workflow, hogy előbb becélozni egérrel az alkalmazásindító ikont, néha még rosszabb, mert alkalmazásmenüt is meg kell nyitni előtte, aztán mikor már fut az alkalmazás, akkor abban még megnyitogatni dolgokat, megint egérrel célzás, tallózás. Nálam ugyanez 1-3 billentyű (gépírástartásban már elve felettük vannak az ujjaim), még csak pontosan sem kell emlékezzek a fájl vagy mappa nevére, elég, ha csak kb.-re írok be 1-2 jellemző betűt, még csak egymás után se kell legyenek, a fuzzy finder pont attól fuzzy, hogy akkor is megtalálja.
Ennek csak az az egy baja van, hogy ha nem a saját rendszerem előtt ülök, akkor rossz visszatérni a hagyományos GUI-s megoldásokhoz, főleg Windows alatt, mintha hátrakötött kézzel kéne mindent csinálni, annyira érezni, hogy nincs hatékonyság. Egyszerűen fényévekkel le van maradva. Nyilván ezt nem érzi az, aki a hagyományos megoldásokhoz szokott hozzá.
-
Frawly
veterán
válasz
Shyciii
#7909
üzenetére
Az st benne van egy olyan mappában, ahova a PATH mutat? Mert ha csak simán forgatod forráskódból, akkor lehet nem telepítetted, csak lefordítottad, és nem került be a /bin/ vagy /usr/bin mappába, vagy hasonló.
De nekem ez a vifmrun is gyanús, simán st -e 'vifm /home/Data /home/Data' sornak kellene lennie, run nélkül. Lehetőleg idézőjelben, az mindegy, hogy egyszeres vagy kétszeres idézőjel.
#7908 jimmy399: akkor meg végképp fogalmam sincs, hogy ha LTS-sel sem jó.
-
Frawly
veterán
válasz
Shyciii
#7905
üzenetére
Ez tényleg fura. Ilyet még nem láttam. Nálam simán elindul a Vifm mindenhogy, default usermappáknál és fájloknál is, amik mappa esetén 755-ösek default (ahogy írod, a listázáshoz kell az execute jog a mappákra), a fájok 644-esek (tulajnak/usernak írható, csoportnak és többeknek csak olvasható. Ez a default minden disztrón.
Persze az is igaz, hogy ez felhasználástól függ, mert aki többfelhasználós gépet használ, és fájlokat akarn megosztani, ott muszáj min. a csoportjogokat is úgy beállítani, hogy mindenki írhassa, futtathassa, amit kell. Elvileg a 777 az publikus mappáknál kéne, ahol követelmény, hogy nem csak a tulajon és a csoportján belül tudják írni, futtatni, hanem tényleg mindenki. Bár ilyenkor se célszerű minden fájlra, mert a fájlkezelők (nem csak a Vifm) akkor binárisként/scriptként próbálnak futtatni adatfájlokat is, és írogatják ki a hibaüzeneteket. Így futtatható jog tényleg csak a mappákra, binárisokra, és scriptfáljokra kell, de ezek az összes fájl számához képest töredéke egy normál rendszeren. 777-re meg tényleg az esetek 99,9999999%-ában felesleges állítani, ez mint mondtam, sok embernél csak régi megszokás, hogy kényelemből bevereti háromszor a legmagasabb oktális számot, mert elég ráfeküdni egy darab billentyűre.
xshkd vonatkozó sora nálad mit mond?
-
Frawly
veterán
válasz
Shyciii
#7900
üzenetére
Ezt most nem egészen értem. Minek kellett pontosan futtatási jog? vifm-nek, vagy sxhkd-nek, vagy az sxhkd scriptnek vagy minek?
A chmod 744 az oké, ha célzott fájlra van kiadva, de akkor már jobb a chmod +x parancs. Valószínű ebben az esetben ugyanezt eredményezte volna.
Egész partícióra viszont nem szabad kiadni a 744-et. valószínű nem tudta a Vifm megnyitni a /home/Data mappát, és egy chown -R felhasználód /home/Data parancs megoldotta volna, a jogok összekutyulása nélkül. Vagy mountoláskor az umask opció.
-
Frawly
veterán
válasz
Shyciii
#7891
üzenetére
Nekem nem is ez a bajon az xmonad-dal meg xmobar-ral. Persze ez is baj vele, hogy komplett Haskell toolchain kell hozzá, meg állandóan újrafordítgatni kódból, ráadásul a Haskell csomagok elég nagyok is, nem csak az a gond, hogy 117 csomag, de vannak közöttük ilyen 100+ mega felettiek, igaz ezek nem mind a futtatáshoz kellenek, csak a kódfordításhoz. Hanem hogy ebben a megérthetetlen funkcionális programozásos Haskell-ben van megírva, ami felfoghatatlan, meg agyrém. Ezeknél még a dwm is jobb, mert igaz, hogy forráskódból forgatós az is, de legalább hagyományos, sztenderd C, rövid forráskód, nincs függőség, stb..
Ez az xmondat, xmobar azoknak mennyország, akik eleve Haskell-ben fejlesztenek, jól ismerik, és az egész ökoszisztémájukat eköré akarják építeni. Mindenki másnak nagyon nem ajánlom. Neked különösen nem, mert a bspwm szerintem sokkal haladóbb, minimalistább, rugalmasabb az xm-akármi-haskelles megoldásoknál.
Kolléga helyében az amdgpu modult feketelistára tenném a /etc/modprobe.d/akarmi.conf fájlba a blacklist amdgpu sor hozzáadásával.
A TRIM-ről meg kiderült, hogy NTFS, úgyhogy ott az ntfs tools csomagosokat kell csesztetni, nem a kernel tehet róla.
Bár azért annyiból megértem a kollégát, hogy Archon nem lenne szabad előfordulnia, hogy egy új kernel miatt ennyire eltörik valami. Akármilyen új is. Bár azt várjuk még ki, hogy mire jut a radeon és xf86-video-ati driverekkel, hátha az megoldja neki.
-
Frawly
veterán
válasz
Shyciii
#7849
üzenetére
Alapból elég ronda, de át lehet témázni normálista, rendes Gtk-téma, jobb panel, normális háttérkép, azért ki lehet belőle faragni jót. Ez az egérszürke, kerekített, paktányemblémás téma szerintem is gáz, azt nyilván nem érdemes default-on hagyni. Ízlésük sose volt az Xfce-seknek, ezt meg kell nekik bocsátani. Védelmükre legyen mondva, hogy próbálnak valami egyedivel előrukkolni, csak az esztétikai érzékük nincs meg hozzá szegénykéknek.
Nálam vágólapkezelésre clipmenud megy. Notification nincs, mert csak nincs rá egyszerűen szükségem, felcsatolásnál sem. Asztali ikonok nem keveset tudnak fogyasztani sajnos, ezt már régen tapasztaltam.
Az Xfce még a Gtk2-es időkben volt sovány, mióta áttértek Gtk3-re, és bevezettek új feature-öket, azóta már inkább a nehezebb súlycsoportban indul, mint a könnyebben. Ugyanez igaz az LXDE-t váltó LXQt-re is. Épp ezért, régen gyenge gépre még javasoltunk Xubuntut meg Lubuntut, ma már ezeket meg sem említem, mikor valaki régi/gyenge gépre keres disztrót. Lassan már az MX is határeset.
-
Frawly
veterán
válasz
Shyciii
#7846
üzenetére
Nyilván az Openbox kevesebb lesz, de nem annyival, mint gondolnád. Az Xfce is Openbox alapú, ha Openboxon használsz kompozitort, dokkot, témát, akkor majdnem ugyanott vagy, ezeket ráadásul Xfce-n is ki lehet kapcsolni. Szerintem az 1330 reális, úgy, hogy Gparted meg 2 füles Firefox is megy. Nem kevés, de nem az az agyam eldobom szint.
Alapból nekem is 700-1000 MB-ot eszik a dwm/SwayWM, Firefox fut sok füllel, meg pár terminálablak. Gpartedet nem használok, sose szerettem, nem csak azért, mert GUI-s, hanem lassú, lassan particionál, szeret bugzani, stb.. A böngésző meg minden platformon bloat sajnos, azt nem lehet megúszni.
Meg ahogy írod, ilyen minimalista rendszernél se dokk, se asztali ikonok, se értesítés, se központi vágólapkezelés, se autocsatolás, stb., azok azért szépen tudnak enni, ha minden fut a háttérben, ezeket felrakod Openboxra, majdnem Xfce-szintű fogyasztást kapsz. Nyilván ezek tiling WM-nél nincsenek nagy részt, már ezekkel jelentős memória spórolható.
Jelenleg, míg e sorokat írom, csak Firefox fut, 12 füllel, meg egy szál terminál, és 1279 MB a fogyasztás. Arch + dwm, minden sallangtól mentes, egyedül mint írtam, még az ez spi meg dbus szutyok nincs csak kiszedve, de más semmi nem megy, se autocsatolás, se ikonok, se kompozitor, se semmi (jó, ntp, meg nagyon minimalista vágólapkezelő csak, meg egy feh háttérkép, ami nem is foglal). Szóval ehhez képest az 1330 nem olyan irreális full DE-n, úgy, hogy még fut 1-2 extra bloat.
-
Frawly
veterán
válasz
Shyciii
#7821
üzenetére
Nálam X.org témában ezek vannak fent, meg ezeknek a kötelező függőségeik:
xf86-input-libinput
xf86-input-synaptics
xf86-video-amdgpu
xorg-fonts-encodings
xorg-server
xorg-server-common
xorg-setxkbmap
xorg-xauth
xorg-xev
xorg-xinit
xorg-xkbcomp
xorg-xmessage
xorg-xmodmap
xorg-xprop
xorg-xrandr
xorg-xrdb
xorg-xset
xorg-xsetroot
xorgprotoEzek közül vannak feleslegesek, pl. az xsetroot, xprop, xev csak valamihez kellett, saját scriptben kísérleteztem velük és csak fent maradtak. De a többi kell, libinput billentyűzetnek, synaptics a tapipad multitouch részéhez, xf86-amdgpu a 2D-s videógyorsításhoz és vsynchez, xauth, server, xinit, xmodmap, xkb, xset, utóbbi három billentyűzetkezeléshez. Tehát annyira sok sallang nálam sincs, nem a teljes xorg metacsomag van fent.
Talán még a fontencoding az, ami lehet felesleges. Nem is én tettem fel, valami behúzta függőségnek.
-
Frawly
veterán
válasz
Shyciii
#7818
üzenetére
Akkor lehet ez a különbség. Bár nem látom be, hogy ez ekkora lenne, mivel nálam csak a X.org server fut, lehet van fent felesleges csomag, de azok nem töltődnek be, ha nem használja őket semmi. Következő installnál én is törekedni fogok, hogy a minimumot rakjam fel ebből is.
Amire még az én esetemben gondolok, hogy az AMD GPU miatt nőtt meg a memóriaigény, szerintem komplexebb drivere van (mint kernel, mind a X.org, mind a mesa szintjén), mint a korábbi Intel IGP-knek, amit használtam, mivel jóval több feature-t is tud. De ez is csak egy tipp, nem vagyok benne biztos.
-
Frawly
veterán
válasz
Shyciii
#7809
üzenetére
Az elég szép. Nem tudom, nálam alap Arch van, Arch Wiki alapján feltéve, nem használok semmilyen scriptet, dwm is minimalistább, kisebb WM, nem kell neki sxhkd, stb., és mégis többot foglal a rendszer. Az is igaz, hogy a rendszerben még benne van pár szemét, dbus, at-spi, pipewire, amit nem én telepítettem bele, hanem valami csomag behúzta függőségnek, és az Arch elindítja, ha kell, ha nem.
Lehet nálad még valami régebbi Arch telepítés van, amibe ezek a szutykok még nincsenek benne default, és/vagy a terminálod is soványabb. Egyébként a bspwm-re átállást én is fontolgatom, mert összességében a dwm nem jön be. Használható, elvagyok vele, de vannak korlátai, mindenhez patchelni kell, nem támogatja rendesen a panelprogramokat, mint polybar, nem lehet manipulálni X-es toolokkal (xdotool, wmctrl, néhány scriptemben használnék ilyeneket), mivel nem ewmh kompatibilis. A bspwm úgy sokkal rugalmasabb nála, hogy lényegében semmivel nem bloatabb, így kacsingatok felé.
-
Archttila
veterán
válasz
Shyciii
#7735
üzenetére
Működik, köszönöm!
Annyi, hogy a végéről ki kellett vennem a ./ karaktereket a %f elől, ellenkező esetben hibát dob.
Egyetlen dolog nem tetszik csak, hogy ha különböző felbontású képek jönnek egymás után a mappába, akkor rettentően csúnya az ablakváltásnál használt átmenet. Ez nem nagy probléma, de azért észrevehető. -
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
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
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
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
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.
-
BoB
Topikgazda
válasz
Shyciii
#7701
üzenetére
A zstd elég gyors, de be lehet állítani a tömörítés mértékét is a sebességg kárára / előnyére (mondjuk máshol is). (erre váltottak az arch csomagok tömörítésénél is).
Ráadásul ha Arch-ot használsz előbb említett okok miatt ez mindenképpen fent lesz már.
wiki.archlinux.org/index.php/Archiving_and_compression#Compression_tools
-
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
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.
-
Archttila
veterán
válasz
Shyciii
#7556
üzenetére
Egy régi lassú SD-n teszteltem, SSD-röl meg amúgy is folyamatosan készül a backup.
Tegnap filmeztem, de annyit azért sikerült kiderítenem, hogy ha mind a két kimenetet használom a PI-n és kifagy, az valószínűleg nem a rossz sway konfig miatt van, mivel odáig el sem jut a folyamat, mivel már login előtt szénné fagy
Szóval a PI config fájljában kell bevésnem a HDMI-ikhez valamit.... utána lehet csak tesztelni a sway-t. -
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
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.
-
Siriusb
veterán
válasz
Shyciii
#7498
üzenetére
Ellenőriztem. És az a fura, hogy ha a Recent-et bekapcsolom, az szépen működik.
Találtam ilyen hibaüzeneteket:
baloorunner[1189]: QFSFileEngine::open: No file name specified
éskrunner[1154]: file:///usr/lib/qt/qml/org/kde/plasma/components/Highlight.qml:34:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }Az elsőnek utána kell néznem, lehet ott van a gebasz, csak fogalmam sincs mi az a
QFSFileEngine. -
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.
-
Archttila
veterán
válasz
Shyciii
#7478
üzenetére
Igen fennáll.
raspberrypi-firmware 20201029-1
De most kapaszkodjatok, visszaraktam a qBittorrent-nox -ot és a korábban említett 150GB-os torrent pár perc után felzabálta a Pi-t
(a képen még megy, de pár perc után kapja a Kill-t)
Van egy olyan sanda gyanúm, hogy kell majd a Swap
Egyébként a fenti bug-ot pár napja átemelték ide, szóval még nagyon is aktuális.
-
vargalex
félisten
válasz
Shyciii
#7462
üzenetére
Az AUR webes felületén a kérdéses csomagnál jobb oldalon a Package Actions-nál a View Changes-re kattintva bármelyik régebbi commit-ra kattintva letöltheted az AUR csomag verzióját, amiben ugye benne van a PKGBUILD, így kézzel a
makepkg -siparancssal fordíthatod és telepítheted a letöltött verziót.
-
válasz
Shyciii
#7466
üzenetére
az mindenképp gond a te esetedben, hogy az AUR-ban nincsenek csomagok, tehát nincs egy központi hely ahonnan be lehetne szerezni az adott szoftver korábbi változatát, hanem ezt minden egyes package-re külön kellene megoldani, amivel nagyjából senki sem foglalkozik, így hacsak nincs meg neked valahol a korábbi változat (én a pikaurt használom, az pl a
~/.cache/pikaurmappában tartja az általa elkészített csomagokat), akkor tényleg csak a kézzel telepítgetés marad, vagy az, hogy megvárod, amíg kijön a javított, frissebb változat. -
válasz
Shyciii
#7434
üzenetére
most hogy így mondtad, lecsekkoltam, hogy amúgy nálam is aktív-e vagy csak én hittem azt eddig, de úgy látom rendben van
[root@vavatch lenry]# systemctl status fstrim.service
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
Active: inactive (dead)
TriggeredBy: ● fstrim.timer
Docs: man:fstrim(8)
[root@vavatch lenry]# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Fri 2020-11-27 15:58:25 CET; 2 days ago
Trigger: Mon 2020-11-30 01:35:57 CET; 7h left
Triggers: ● fstrim.service
Docs: man:fstrim
nov 27 15:58:25 vavatch systemd[1]: Started Discard unused blocks once a week. -
Archttila
veterán
válasz
Shyciii
#7404
üzenetére
Nálam valahogy így nézett ki:
- Ubuntu 10.04
- Debian (Sid) Xfce
- Manjaro Xfce
- Arch Xfce (első Arch telepítésem)
- Arch SwayWMFrawly
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.
Pontosan ezen az ösvényen járok.
Szépen sorban day by day elhagyom a korábban megszokott GUI-s alkalmazásokat, és helyettük terminálos minimalista megoldásokat használok. (moc, zathure, rtorrent etc.) bár itt most annyi változik, hogy a moc helyett lehet mégiscsak beüzemelek egy mpd+ncmpcpp kombót, valami jóféle visualiser-el -
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.
(pedig nem szokasom) mert barmit csinaltam nem sikerult eltalalni a megfelelo jogosultsagokat, szoval maradt az udisks2 egy csinositoscripttel:
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
BoB
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Eladó Steam kulcsok kedvező áron!
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Honor Pad X8a 64GB Wifi,1 év Garancia
- Wacom Cintiq DTK-2260 - Digitális rajztábla
- 18 éve! Billentyűzet magyarítás magyarosítás. Festés vagy lézerezés és egyebek! 3 lehetőség is van.
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- AKCIÓ! Lenovo Thinkpad P15 Gen1 15 FHD notebook - i7 10750H 16GB RAM 512GB SSD Quadro T1000 W11
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest