-
GAMEPOD.hu
Arch Linux topik
Új hozzászólás Aktív témák
-
BoB
Topikgazda
válasz Siriusb #6682 üzenetére
A krunner file location problémára most hirtelen workaround jutott eszembe, mégpedig a custom window rule.
Be lehet állítani hogy mekkora legyen a krunner ablak, és beállítod jó szélesre, a fájl nevek mellett lehet látni az elérési útvonalat, mert amúgy mutatja csak nem fér ki olyan kicsi az ablak alapból (nem mindet mondjuk de ha fölé viszed az egeret akkor igen).
[ Szerkesztve ]
You may corrupt the souls of men, but I am steel. I am doom.
-
Shyciii
veterán
válasz Siriusb #6687 üzenetére
Többek között ilyesmi esetek miatt hagytam ott a KDE-t. Gnome-ot mert borzalmasan lassú volt és kevés beállítási lehetőség. XFCE-t témázva is randa, és egyáltalán nem olyan gyors ahhoz képest, hogy light. Nah ezután akadtam a szemem elé a WM rendszerek. Abból a Tilingot rögtön kilőttem, mert egy notebookon nincs értelme, de Openbox, Fluxbox és társai már tetszetősek voltak. Openbox kapásból nyert ahogy átolvastam ezeket, és néztem a konfig fájljaikat. Azóta sem bántam meg, és még csak kósza ötletként sem merül fel, hogy visszamenjek másra
-
-
-
Laszlo733
aktív tag
válasz Siriusb #7016 üzenetére
Azt nem tudom, hogy a " sima " lua -hoz van - e köze, de azt nem lehet eltávolítani, mert függőségre hivatkozik.:
függőségek vizsgálata...
hiba: nem sikerült előkészíteni a tranzakciót (nem sikerült kielégíteni a függőségeket)
:: luaeltávolításával megtörik a 'lua' függőség amit a conky kér
:: luaeltávolításával megtörik a 'lua' függőség amit a vlc kér -
Laszlo733
aktív tag
válasz Siriusb #7020 üzenetére
Arra hivatkozik, amit Te is mondasz:
conky: Syntax error (.config/autostart/conky2.desktop:2: unexpected symbol near '[') while reading config
file.
conky: Assuming it's in old syntax and attempting conversion.
conky: [string "..."]:147: attempt to index a nil value (local 'settings') -
Frawly
veterán
válasz Siriusb #7040 üzenetére
Nálam nincs az illető fájlban ilyen, nem is tudom mi ez a tally, életemben nem hallottam még róla. Utánanézhetnék, de lusta vagyok hozzá. Nekem nem tört el semmi. Bár azt régóta tudom, hogy valamit nagyon rosszul csinálok, mert Archon nem szokott semmi eltörni. Utoljára Gentoo-n törtek el, kísérleti RC kerneles, meg -9999 verziós tesztcsomagok, de az utóbbiba is inkább az én tudatlanságom játszott bele, meg én kerestem a bajt, hogy ilyen ultrafriss csomagokkal próbálkoztam, ha már lúd, legyen kövér alapon.
Abban viszont igazad van, hogy ennek kint kéne lennie az archlinux.org főoldalán, mert több embert érinthet, hogy akinek ilyen van benne ez a tally, szedje ki. Ezt sose értettem, pont erre lenne a főoldaluk hírszekciója, eleve fizetnek a szerverért, és nem használják ki, hogy van.
-
_Dumber_
őstag
válasz Siriusb #7042 üzenetére
Kövezzetek meg de én még mindig yaourt-ozok.
A pikaurt majdnem használom, de ha több keresési eredmény között ki kell jelölnöm, hogy mit akarok telepíteni, akkor defaultként az 1 van beállítva a pikaurban (default=1). A yaourtban meg semmi. Így ha entert nyomok a yaourt csak kilép a pikaur meg az 1-es sorszámot telepíti.
Le lehet ezt a funkciót állítani? -
vargalex
félisten
válasz Siriusb #7061 üzenetére
Én is éppen tegnap frissítettem a teljes rendszert, és gond nélkül megy tovább a qbittorrent (qbittorrent-nox-ot használok). Valóban áprilisi verzió, amit egyébként tegnap flaggeltek out-of-date-ra. De ez még nem jelenti, hogy máris lenne újabb verzió. Persze lehet, hogy egy rövid időre volt a repoban...
Alex
-
Frawly
veterán
válasz Siriusb #7126 üzenetére
Nem keserítesz el senkit, sőt, jó is, hogy írod, mert ebbe bele fognak futni páran. Egyelőre még csak én futottam bele, de ahogy az új libtorrent-rasterbar verzió lecsorog a stable tárolóba, más disztrókon is, nem árt tudni erről a problémáról. Elhiszem, hogy azóta megoldották a qB-fejlsztők, de hány hét is telt el? Mondjuk lehet csak disztrószinten fordították újra a libtorrent-rasterbart, és nem a qB-fejlesztők oldották meg, de akkor is. Ez így élből komolytalan. Én annyiból valóban sajnálom, hogy ha a fejlesztők nem lennének ilyen nemtörődöm hozzáállásúak, akkor simán a legjobb opensource torrentkliens lenne. De ahogy nézem, a torrent egyfajta rétegigénnyé süllyedt vissza, most majdnem minden fejlesztő hanyagolgatja a témát, lásd transmission-cli-nak sem megy a régi TUI kliense. Tényleg összeszedhetnék magukat, mert ez a torrent egy elég régi protokoll, nagy újítás nem érkezik bele, a klienseknek mostanra már ultrakiforrottnak kéne lennie. Ha valami új dolog lenne, akkor elfogadnám, hogy még csak kísérleteznek vele, nem ért még be az egész.
Azzal viszont maximálisan egyetértek, hogy ilyen SMB-s szopások helyett sokkal egyszerűbb egy FTP szervert beröffenteni, általában minden támogatja szerver és kliens szintjén is, és ugyan semmivel nem biztonságosabb protokoll, de legalább ransomware-támadásoknak nem esik áldozatul, és tényleg multiplatform, és baromi egyszerű működésre bírni, én is ezt szoktam preferálni gépek közötti megosztásnál LAN-on. Nagyon gyorsan be lehet konfigurálni egy FTP-t, míg az SMB-vel, meg NFS-sel elég sokat lehet szívni, amire általában az esetek 99%-ában nincs idő.
-
Shyciii
veterán
válasz Siriusb #7499 üzenetére
Egyébként most nézegetve a krunner hibákat vannak érdekességek. Valakinek szintén meghalt , mint neked, de ha kikapcsolta a calculator-os részét a krunner alatt, akkor újra működött neki rendben Amúgy ez a hibaüzenet azért érdekes, mert olyan szintaxist használna, ami már meg lett változtatva, vagyis már nem így kellene kinéznie. Egész pontosan a Qml 5.15 óta más a connection szintaxisa. Ez ugye a Qt-hez tartozik (amit anno KDE-n meggyűlöltem, és azóta is kerülöm azon programokat, amik Qt-n alapulnak. Így pl a VLC és a qbittorent is kiesett).
De hogy ennek lehet-e köze a krunner hibához...[ Szerkesztve ]
-
Siriusb
veterán
válasz Siriusb #7499 üzenetére
Odáig jutottam, hogy a baloo-ra szűkítettem le a problémát: a baloosearch egy adott keresésre minden egyes találatra üres string-et ad vissza, tehát a terminálban annyi üres sor látszik, ahány találat van.
balooctl disable + purge + enable
parancsok után viszont szépen kiírja a fájlok útvonalát. -
Frawly
veterán
válasz Siriusb #7521 üzenetére
Én meg speciális scripttel frissítek, ami a pacmant úgy hívja meg, hogy tmpfs ramdrive-ra tölti a csomagokat. Így nem gyűlik be a csomagcache, eddig a sok éves archozás alatt egyszer fordult elő, hogy egyel régebbi csomagverziót kellett feltenni. Korábban volt nekem is, hogy majdnem 10 GB-ra hízott a pacman cache. Utána elkezdtem kézzel takarítgatni a pacman -Scc kiadásával, de aztán ráuntam.
-
urandom0
senior tag
válasz Siriusb #7629 üzenetére
Na állj, a suspend az a felfüggesztés, az tényleg felfüggeszt minden folyamatot, és elmegy alvó módba!
A zárolás az, ami nem függeszt fel semmit. Félreértettük egymást.Ha konkrétan képernyőkímélő kell, az tudtommal nincs KDE-ben, szóval marad az xscreensaver. De mi a cél pontosan? Miért ragaszkodsz a képernyőkímélőhöz?
-
Lenry
félisten
válasz Siriusb #7632 üzenetére
én ha úgy állok fel a céges gépemtől, hogy tudom, hogy ki fog kerülni a látóteremből, akkor zárolom. ekkor egy általam válaszott kép lesz a teljes képernyőn, középen egy jelszómezővel.
ha pár percig nem nyúl hozzá senki, akkor a monitorok elalszanak.
ettől az égvilágon semmi bajuk nem lesz, ez teljesen üzemszerű, tervezett működés, ettől teljesen fölösleges féltened a monitort.[ Szerkesztve ]
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Frawly
veterán
válasz Siriusb #7632 üzenetére
Az a baj, hogy nagyon pontatlanul írod mit akarsz, és csak találgatni tudunk. A képernyőkímélő nem egyértelmű, mert nem tudom, hogy a kijelző energiatakarékos kikapcsolását érted alatta (ami igazából DPMS blank time) vagy tényleg a kalsszikus DOS/Win képernyővédőt (ún. screensaver, amikor a képernyőt nem kapcsolja ki, hanem mozgó grafikát jelenít meg).
Épp így a Lock screen / suspend esetében sem egyértelmű, hogy mire gondolsz.
Egyébként meg pont itt jön elő, amit írtam. Nálam ez e beállítás pálcika WM-en annyi, hogy egy autostart nevű Bash script fájlba beteszem a xset dpms 0 0 630 & tartalmú sort, és kikapcsol a screensaver és a screen blank is 10 perc 30 másodperc múlva. Nem kell vergődni, hogy melyik ikon, melyik menüjébe rejtették ezt a nyomorult beállítást.
Épp így a screensaver is így indul nálam, autostart fájlban újabb sor: xss-lock ~/scripts/screensaver-script & és ennyi. De épp ilyen egyszerűen definiálom a billkombókat, touchpad apró beállításait, tálca beállításait, szintén ebből a fájlból, 1-1 sor. Nem kell keresgetnem grafikus felületen, meg 500 kattintásból állítgatnom, hogy mi hol van, egyszer megírtam, 10+ évig működni fog, nem lesz az, hogy a KDE4, 5, 6 máshogy kezeli Qt4, Qt5, Qt6 alapokon, vagy máshogy kezelné a Gnome2 meg a Gnome3.x-4x. Nem mindig az a legfelhasználóbarátabb megoldás, ami annak látszik. Ráadásul ez az autostart megoldás memóriát sem foglal annyit, és rendszerújrahúzáskor csak visszamásolom, legtöbb X.org alatt futó pálcika WM eszi, de ha xinitrc-be behúzom, akkor az összes. Waylandes grafikus felület csak annyiban más, hogy ott az autostart részt be kell emelni a WM konfigfájljába, meg némileg módosítani, pl. SwayWM-nél:
exec swayidle timeout 600 '~/scripts/screensaver-script' timeout 660 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"'
Ez már bonyolultabb, de ezt is csak egyszer kellett kigugliznom és megírnom, soha többé nem kell keresgetnem semmit rajta, 10 perc múlva elindítja a screensavert (ami egy terminálban futó asciiquarium), +1 percre rá a képernyőt elsötétíti. Viszont ha újra gép elé ülök, akkor feloldódik a képernyősötétítés, de az i3lock és az alatta futó asciiquarium továbbra is fut, be kell írnom a jelszót, és akkor a screen lock is feloldódik. A +1 perces időeltolódás azért van, hogy ha véletlenül mégis a gép előtt lennék, és látom, hogy kilőtte a képernyőt, még gyorsan nyomok valamit, hogy ne zárolja a grafikus felületet, van egy kis plusz időm.Egyébként az óránkénti négy-ötszöri képernyőkikapcsolás nem árt a kijelzőnek. Az 1-10 másodpercenkéntnyi talán, a 12-15 percenkénti nem. Azt meg nagyon erősen ajánlom, hogy a képernyőt x inaktivitási idő miatt zárold, ha nem vagy gépnél. Igen, kényelmetlen a jelszót állandóan begépelgetni, de majd megszokod, és a te biztonságod szolgálja, és nem függeszt fel semmilyen futó folyamatot. Nagyon ajánlom akkor is, ha egyedül használod a gépet, vagy egyedül élsz, ha hirtelen ott kell hagyd a gépet, és valaki illetéktelen behatoló is jut be a gép közelébe, akkor sem tud a gépbe belematatni.
-
ztsoft
őstag
válasz Siriusb #8152 üzenetére
Engem is nagyon zavar (egy időben a billentyűzetet akartam szétverni miatta ), de szerencsére rátaláltam a Ctrl+L-re (Az összes dokumentum mentése), így megúszta a fizikai sérülést.
A legszebb, hogy a Geany-ban sem működik a Ctrl+S. Szerintem valahol ütközés lehet, de nem tudom, hogy hol. Egy esti frissítés tett be neki (másnap reggel vettem észre), pacman logból vissza állva sem oldotta meg. Most semmi kedven újra konfigolni a teljes rendszert.
Jó dolog fontosnak lenni, de fontosabb, hogy jók legyünk.
-
jimmy399
senior tag
válasz Siriusb #8148 üzenetére
Nekem van egy Fm2 pro4-m alaplapom, egy AMD A8-5600K-s procim, DDR3 ram, egy Ati Radeon 5550 HD-m a PCI-E slotban, valamint egy HD 7650D a CPU-ba integrálva.
Az 5550-re van csatlakoztatva egy sima mezei 16:10-es Lg monitor, a 7650D-re még egy sima 16:10-es monitor 19".Frissítettem a legutóbbi kernelre és amikor engedélyeztem a 5550-en a második kijelzőt kiterjesztve, azonnal csonttá fagyott a rendszer. Csak a reset segített, mert bár ssh-n be lehetett jelentkezni, de nem tudtam leállítani rendesen a gépet úgy sem.
Ezek már nem mai hardverek, és mégis szétfagyasztotta a gépet.
Debian 11 simán megy ezzel a felállással 5.10.0-s kernellel, Arch alatt meg 5.10 és afelett fagyott azonnal csonttá. Rendesen ignorepkg-ba kellett tennem a kernelt, mert ment a remegés, hogy jó lesz-e vagy sem.Hardverhiba kizárt, Windows 8.1 & 10, a Debian11 is simán megy.
[ Szerkesztve ]
--- N/A ---
-
anorche1
őstag
válasz Siriusb #8323 üzenetére
Szerintem igen, ez lesz a titok.
Koszonom a valaszokat!Egy masik kerdesem is lenne, hogy valakinek sikerult eletrekelteni a hibernalast swap file -lal?
16GB ramom van, egy 16GB -os swapfilet hoztam letre, ami tokeletesen is funkcional.
De mikor kiadom a systemctl hibernate parancsot, Not enough swap space for hibernation hibat dob, akkor is, ha van osszesen 300MB ram foglalas.
Beraktam a /etc/default/grub -ban hozzadatam a GRUB_CMDLINE_LINUX_DEFAUL sorhoz a resume=/home/anorche/msata/swap swap_file_offset=14018560 erteket, majd grub-mkconfig -o /boot/grub/grub.cfg, restart, de nem segitett.Kiprobaltam gyorsan swap particioval is. Igy mar ugy csinal, mint aki hibernal, de valoszinuleg csak valamilyen egeszsegtelen modon kikapcsolja a gepet.
Ez igy nem jo[ Szerkesztve ]
"It never gets easier, you just go faster." Greg LeMond
Új hozzászólás Aktív témák
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Canva Pro előfizetés - 1 éves
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen