- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: Bye PET Palack, hello SodaStream
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- btz: Internet fejlesztés országosan!
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- LordAthis: AI Kérdés érkezett - 3600 soros Spagetti kód refaktorálása és budget
- LordOLOG Szféra
- sh4d0w: Netflix? Ugyan, VW előfizetés!
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
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... -
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. -
-
-
Lenry
félisten
Meg Debian- és Ubuntu-vonal alatt azért sem gond, mert ott külső tárolóként hozzá lehet adni a Google-nek a Chrome-tárolóját, vagy kézzel, a Google oldaláról letöltve a .deb csomagot, dpkg -i segítségével telepíteni.
ne felejtsd el, hogy raspberryről van szó.
a Google nem compile-ol ARM-re asztali Chrome-ot, meg én Chromiumból se láttam kész friss deb-et, akinek van rá ingerenciája az fordíthat magának, de az huszonsok gigabyte meg egy Pi-n gondolom el is tart kb addig, amíg kijön a következő verzió
-
Frawly
veterán
válasz
Archttila
#7487
üzenetére
Ez annyira nem rossz. Jó, egy szem 6,7 gigás torrenthez kicsit sok, de még nem annyira túlzóan, hogy az ember agya a láncot ledobja. Ha ez így jól megy, akkor hagyjad. Egyik torrentkliens sem sovány, mindegyik jól megeszi a memóriát, meg ha gigabiten töltesz le, akkor a CPU-t is, ezzel nem tudsz mit csinálni, minimalizmus ide, nem bloatság oda. Egyszerűen maga a torrent protokoll bloat, főleg ha sok mindenkitől töltesz le sok mindent, megy-jön a sok fájlszelet, ellenőrző összeg, hibajavítás, prioritáskezelés, stb., ez mind viszi a sávszélt, memóriát, procit.
A Chrome-alapú böngészők meg valóban gyorsabbak, mint a FF, de nem a Wayland miatt, mert az FF-on is bekapcsolható, hanem a rendermotorjuk gyorsabb. Cserében viszont a Google hatalma nő általuk, hogy már szinte minden böngészőt a Blink/Chrome motor hajt, másrészt ez a motor a teljesítményre van kihegyezve, de cserébe nem nagyon lehet semmit állítgatni rajta, addon is kevesebb van hozzá. FF-ot sokkal részletesebben testre lehet szabni, több a jó addon hozzá, illetve ha ezt használod, akkor a Google hatalmát csökkented, plusz a FF kevesebb memóriát is eszik, cserébe 1-1 oldal renderelése kicsit lassabb, nem vészes, pár ms.
#7488 Shyciii: nem azt mondom, hogy friss, mert tényleg régi a 83-as, de annyira nem elavult, mintha mondjuk egy 60-70-es verzióról beszélnénk, azért még minden weboldalt meg webalkalmazást lerenderel, meg mindenféle addont támogat. Arra a felhasználásra, ami te írtál elég. Meg Debian- és Ubuntu-vonal alatt azért sem gond, mert ott külső tárolóként hozzá lehet adni a Google-nek a Chrome-tárolóját, vagy kézzel, a Google oldaláról letöltve a .deb csomagot, dpkg -i segítségével telepíteni.
Félre ne érts, én nem támogatom amúgy a régi verziók használatát. Azért is szoktam minden topikban leírni a rolling frissességének mindenhatóságát, és szoktam is javasolni, hogy aki mesa, GPU driver, Steam, Proton, Wine, stb. frissességével küzd, az ne szenvedjen Ubuntu-vonalon, meg LTS-ezzen, hanem tegyen fel normális full rolling disztrót, ha nem tudja telepíteni az Archot, akkor ArcoLinux vagy Manjaro formájában, de azt használja, nem kell többé Obeiöfböff PPA-zni, meg dependency-kkel kínlódni, hogy ne dinoszauruszok korabeli verziókon ragadjon az ember. Persze emiatt le is szoktak tolni, hogy mit képzelek én, túl nagy az Arch-om, meg az Arch instábillll, meg nem server/corporate grade, nem LTS, nincs hozzá rendes support, stb.. Ja, ezek egyike se, de nem kell vele szenvedni, mert minden simán fog rajta menni, a legújabb verziók is, legújabb hardverek, nem kell nonfree tárolókkal vergődni külön, disztrófrissítésekkel kockáztatni, hogy most vagy sikerült, vagy nem, nem ragad az ember régi verziókon.
Ha lenne RPi4-em, akkor sem PiOS-t tennék rá, meg ARM-es Debian, Ubuntu valamelyikét, hanem min. Arch ARM-et, ahogy a fenti kolléga is használja.
-
Shyciii
veterán
Mondjuk úgy nem nehéz stabilnak lenni, ha alig frissül bármi is
Közben foglalkoztam a screen tearing problémámmal is. Töröltem immáron felesleges kernel paramétert, intel driver paraméter módosítások, találtam egy mtpfs csomagot, ami rendesen működik, így nem kell már gvfs, és így most tovább csökkent a memóriafoglalás. Most már 172MB-ról 158MB-ra csökkent. -
Shyciii
veterán
Ez a teljes Debian repoban ilyen régi. Tehát aki desktopos sima debiant használ is a repoból 83-as Chromiumot használ. És ez eléggé régi, főlehg hogy egy mezei user bármilyen weboldalt megnyithat otthon. A Chromium meg a különböző verziókban elenyésző új funkciókat kap, vbagy gyorsítást (bár pont a 87-esben gyorsítttak jelentősen), ellenben csomó security hibákat javítanak. Márpedig elég gáznak tartom, hogy a Debian-t tartják az egyik legbiztonságosabb egyszerű linux esetén, közben meg az olyan csomagok, amiket a userek gyakran használhatnak, azok meg meg elavultak. Amúgy az Ubuntu a 85-ösnél tart, szal azért még ő is előrébb jár.
-
Archttila
veterán
free -mtotal used free shared buff/cache availableMem: 3394 644 157 159 2593 2548Swap: 0 0 06.7GB-os anyagnál, 60MB/s letöltési sebesség mellett.
RPI topikban ezt az okosságot kaptam. [link]
Azért látszik kevesebbnek a mem, mert az RPi integrált GPU-jának 512MB van megadva.
A rendszer 32 bites (armv7l) A 64 bites még annyira sem hivatalos mint ez, illetve majdnem minden update után hegeszteni kell rajta valamit...Természetesen SSD-röl fut a rendszer.
Jah igen Chromium! Ugye én 2003 óta használtam FF-et, de egyik nap gondoltam teszek egy próbát a Chromium-al már csak azért is, mert a 87-töl már alapból hozza a wayland támogatást. (jelenleg 85-nél jár)
Már az első indításnál feltűnt, hogy a valami eszeveszett sebes
Az ARM-es FF ehhez képes egy kövület. Uccu neki kapcsoltam is egy VA-API-t és áhhh, nem akarom elhinni amit látok, valami eszméletlen mennyire más élmény mint a róka. Erősebb, x86 hardware-en nem jön ki a különbség, de itt... -
Lenry
félisten
Ha egy mai fiatal nézi, vagy valaki nyugati emberke, aki ebben sose élt, szerintem annak csak szimplán fura és unalmas lesz.
jah gondolom azért magasztalta az egekig Tűzföldtől Tokióig mindenki, mert furának és unalmasnak találta.
maradjunk annyiban, hogy neked személy szerint nem jött át, és pont. -
Frawly
veterán
Igen, megvan, de ettől még baromság, és emberek hajlamosak komolyan venni, hogy így történt. Egyébként kár érte, mert mint írtam, rendezésében, ebben-abban nem lenne pedig rossz, ha nem ilyen ikonikus témát dogoz fel, talán végig is nézem. Mert az pl. hátborzongatóan élethű, ahogy az akkori életet ábrázolja, szocialista panellakótelepek, szoci neomodern dizájnos művházak, ipari létesítmények, még politikai vonulatot is jól mutatja be, mindenféle párbizottság, tanácsülések, szocialista szólamok, szobák dekorációja, berendézes, szoci kárpitos bútorok. Ez mondjuk csak annak tűnik fel, aki van elég idős, és még élt abban a korban. Ha egy mai fiatal nézi, vagy valaki nyugati emberke, aki ebben sose élt, szerintem annak csak szimplán fura és unalmas lesz.
-
-
Frawly
veterán
válasz
Shyciii
#7480
üzenetére
Általában én vagyok, aki a Debiant ekézni szoktam (az RPiOS is az, egy ARM Debian), meg én vagyok a legfrissességmániásabb a topikban, de szerintem a Chromium 83 még nem olyan elavult. Jó, nem valami friss, azt aláírom, én nem is tennék fel magamak ilyet, minimum Arch ARM-mel próbálkoznék, de ha backportolták benne a security patch-eket, akkor azért használható, főleg ilyen embedded céges vagy ipari környezetben elég, ha csak operátornak annyira kell, hogy kioszk rendszerben egy darab webes alkalmazással tudjon dolgozni a böngészőben.
-
Frawly
veterán
válasz
Archttila
#7479
üzenetére
Nekem ezek a számok nem tűnnek rossznak, szerintem nem annyira brutál memófoglalás. Az is igaz, hogy nem mutattál free -m kimenetet (látszódjon a shared, cache is), meg azt se értem, hogy a htop-ban a RPi4 memóriájából miért csak 3,3 GB látszik, mikor 4-nek kell lennie? Nem 32 bites rendszert futtatsz 64 bites helyett? Mert a 32 bit megmagyarázná a korábbi forráskódból forgatási problémáidat is. Vagy 64 bites az, és az RPi integrált GPU-ja vesz le a rendszermemóriából. Bár memóriád így is van szabadon, a háttérben fut minden, komplett grafikus felület, terminálok, progik, MiniDLNA, torrent, stb., ahhoz képest nem valami sok a 438 MB-os fogalás, majdnem 3 GB szabad memória van, ilyen felállásban én nem sok értelmét látom a swapnak. Bár betehetsz, de akkor arra figyelj, hogy még véletlen se HDD-ről fusson, meg SD kártyáról, meg eMMC tárolóról, hanem rendes SSD legyen alatta. Nem baj, ha csak valami olcsó, SATA3-as szutyok, de rendes desktop vagy M.2 SATA vagy hasonló SSD legyen.
Gigabites net kihajtásának ez az ára egyébként, ha tényleg több szálon van hajtva, akkor meg is van, hogy az rtorrent-nek is miért volt magas a CPU használata. A több szálas gigabites torrent már sokat tud enni egy szabvány windowsos PC-n is, mind memóriából, mind prociból.
Ez a Chernobyl sorozat szerintem nem valami jó, bár azt se értem, hogy egy Trinity-kiadásnak hogyan lehet epizódonként 25 gigás mérete, még 4K-ban sem kéne annyit foglalnia. Én is elkezdtem nézni ezt a Chernobylt (épp így talán Trinity Blu-Ray 1080p-s felbontás), és ugyan pl. a korszak jól van benne ábrázolva, emberek, épületek, ruhák, stb., de az egész történet el van torzítva benne, szakmai helytelenségekkel, meg csak marék szereplővel dolgozik, mintha csak azok vettek volna részt mindenben. Az egész annyira el van rugaszkodva a valóságtól, hogy szerintem időpazarlás megnézni.
A linkeden a faszinak a gondját meg szerintem nem bug okozza, hanem a külső HDD-je haldoklik vagy nem kap elég delejt, mert valami ócska kínai táppal hajtja, vagy nem aggat rá külön tápot, az USB foglalatból meg nem tud elég naftát felvenni.
-
Shyciii
veterán
válasz
Archttila
#7479
üzenetére
Durva, hogy ilyen hiba fennáll 1 éve. Mondjuk nem lepődöm meg. A cégnél a Pi4-eket arra vette a cég, hogy az operátorok a böngészőben tudjanak dolgozni az új programban. Nekem csak annyi feladatom volt, hogy állítsak össze egy linux szervert, amiről bebootolnak a Pi4-esek, és egy kész felület indul csak el, de nagyon minimálisnak kellett lennie a Pi4-es raspberry pi os-nek, kvázi böngésző, és egy full minimál ablakezelő, és semmi mást ne tudjanak csinálni. Azt hittem, hogy ilyen kevés cuccal nem lehet problémába ütközni, pedig de. A Pi4-es saját raspberry pi OS-ben a Chromium igencsak elavult. 83-as a legfrissebb a repojában, holott már 87-esnél tartunk...illetve 2 féle chromium csomag van. A másik 84-es verziójú, de azon a webrtc meg hibásan működik...
-
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.
-
Archttila
veterán
Szerveren transmission-t használtam évekig, webes klienssel, lustább pillanataimban droidon transmission remote-tal. A tudása számomra bőven elegendő volt, viszont mivel csak egy szálat használt így dobtam, mert a qbit félálomban fényéveket vert szegénykémre
Nagyjából úgy képzeld el, hogy gigás net mellett ha a Trans dobott egy 20-30-as peak-et akkor már juhééj volt, a Qbit meg konstans hozta a 80-85-öt. Gyakorlatilag miután elindítottam a qbittorrentet nem hittem a szememnek... annyit tudtam, hogy a vas képes rá, mivel korábban mértem HDD speed-et a Pi-n, és akkor valamivel 100MB/s felett hozta át a célvonalon a 2x1TB PiDrive-ot.Nem tudtam még beszélni a sráccal. Ph-ra sem lépett be és, whatsApp-on sem elérhető. Személyesen nem ismerjük egymást (külföldön él) Pár hónapja OLED témában volt egy hosszabb beszélgetésünk, (innen az ismeretség) viszont nagy meglepetésemre GitHUB-on az ő nick-je szerepelt a rtorrent-ps-ch project felett
szóval ha ő azt mondja hogy pass, akkor valóban baj van
Tegnap este még bedobtam pár limitáló opciót a konfigba,pieces.memory.max.set = 1000Mmax_memory_usage = 512Mdownload_rate = 8192upload_rate = 1024és (igaz nem azonnal) de 10-15 perc után így is jött a Killed hammer...
Ami számomra eddig egyértelmű az az, hogy kisebb (értsd pár GB) anyagokat simán kezel mindenféle varázspálcás bohóckodás nélkül, viszont nekem nem erre van szükségem.
Számomra az a fontos, hogy ha bekapcsolom az LG OLED tévémet, akkor DLNA/Plex etc. alá szolgáltassa a forrásanyagokat, amiknek a mérete (a tartalom terjedelmétől függően) sokszor az 50-200GB-ot súrolja. (4K BD HDR/DV) -
Frawly
veterán
válasz
Archttila
#7468
üzenetére
Kíváncsi vagyok mit fog mondani a fejlesztő. Nálam 1 giga felett evett, csak az rtorrent magában, igaz ebben a cache is benne van, már nem is emlékszem mennyi. De csak 4 torrent volt a kliensben, abból is csak 1 volt aktív, töltött le, alig pár GB terjedelemben. A neten is panaszkodnak, hogy sok memóriát eszik. Nagy procihasználatra nem emlékszem, igaz én anno i5-2520M és i7-2720M-es procikon próbáltam, amik szintén nem erőművek ma már, de egy RPi4-nél azért sokkal erősebbek.
A nagy memófogyasztást nem is annyira rovom fel, mert a qBittorrent sem keveset evett, igaz abba is bele volt számolva a saját lemezcache, meg a nagy memóriahasználatért cserében elég sok funkciót nyújtott. Végül nem is az erőforrás-használata miatt dobtam, hanem már vagy harmadszor fordult elő az évek során, hogy a qB-es fejlesztők képtelenek voltak annak a libtorrent-rasterbar libnek a változásait, fejlesztéseit lekövetni, amire a kliensük épül, ebből lett elegem. Egyszerűen a hozzáállásuk csapnivaló, lusták. Pedig amúgy a legjobb torrentkliens lenne.
Én végül transmission-cli-ra tértem át, ennek memóhasználata jóval kevesebb, rtorrentnél többet tud, procihasználata sincs nagyon. Főleg webes klienssel használom, de néha terminálból is tremc-vel. Nem egy nagy szám, nem tud sokat, de nekem elég.
-
Siriusb
veterán
Ha valaki pikaur-t használ és még nem frissítette meg a python-t, elsőként frissítse a pikaur-t, mert az eltérő python verzió miatt nem fog működni. Elvileg ezután már nem lesz probléma pythonverzió-váltás miatt.
Tudom, kb. 30 másodperc kézzel felrakni a pikaur-t, na de lusták vagyunk, nem?! Hátha spórolok valakinek. -
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.
-
Archttila
veterán
Az a furi h htop szerint nem sot, 350MB a teljes rendszer ramehsege. A CPU usage viszont 50-80% kozott ugral (bizony) ami vicc, meg akkor is, ha ekkora meretu (az az amugy egy darab) torrent a kliensbe.
Szerintem alapjaraton el van eresztve a rtorrent, ds valszeg ilyen-olyan ertekekkel vissza lehet fogni. (remelem)Tortenetesen ismerem az rtorrent-ps-hc fejlesztojet. Este beszelek vele, remelem tud mondani par okossagot ezzel kapcsolatban mert ha nem, akkor jon vissza a qbit.
-
Lenry
félisten
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. -
-
Archttila
veterán
Sikerült szépen belőni az rtorrent-et, viszont legnagyobb bánatomra ha nagyméretű adatot töltök vele (100-200GB) akkor elszáll a kliens. Szerintem felfalja a memóriát:
sudo journalctl -r | grep KilledDec 03 19:50:32 rpi4 kernel: Out of memory: Killed process 8996 (rtorrent main) total-vm:404948kB, anon-rss:12100kB, file-rss:120800kB, shmem-rss:0kB, UID:1001 pgtables:504kB oom_score_adj:0A pieces.memory.max.set = 1000M (elvileg a fizikai RAM fele ajánlott, de nekem a negyedével is elszáll)
-
Shyciii
veterán
AUR-ban levő csomagot hogyan lehet downgrade-elni, vagy régebbi csomagot feltenni? Erre nemigen találtam érthető leírást. Polybar új verzióját elszúrták, a workspace-ek kezelésénél a feliratok ugrálnak váltáskor. És bár a 3.4.3-as tar filet nagy nehezen megtaláltam, és a benne levő build.sh-val felraktam (persze előtte ki kellett találnom, hogy milyen dependencies-ek vannak), de ahogy nézem ez nem szabályos felrakás, mert a csomagok között sem jelenik meg, így el sem lehet távolítani, szal bár így működik ,de nem ez lenne az igazi.
-
Frawly
veterán
válasz
anorche1
#7460
üzenetére
Octopi-t sose használtam. Ha találgatnom kéne, akkor terminálból megkap valami parancssori opciót, amit a dmenu nem nyújt neki, és ennek hiányában nem fut. Terminálból is csak így egymagában hívod meg, egy parancsként, semmi kapcsoló mögötte? Esetleg terminálból indítva a megfelelő jogosultsággal indul, míg dmenu-ből indulva nem.Pamac nem jó helyette? Vagy a terminálos octopi parancsra csinálsz egy gyorsbillentyűt?
Ahogy olvasom, a PCmanFM-qt-ben nem lehet letiltani ezt a smooth scrollt. KDE alatt le lehet, de ebben a fájlkezelőben nem. Ez elég ostoba volt részükről, beletenni egy megkérdőjelezhető feature-t, és nem kikapcsolhatóvá tenni. Pedig nem is azért írtam, mert LXQt alatt bele fogsz futni, erről a smooth scrollingról még a KDE kapcsán tettem csak említést.
Egyébként ha nem ragaszkodsz az egész Qt-ökoszisztémához, akkor lehet az LXQt alapjául szolgáló Openbox-ot is futtatni, picom kompozitorral (és mondjuk tin2 vagy polybar panellel), és Gtk3 alkalmazásokkal, pl. a PCmanFM-nek van Gtk-s változata, abban nincs smooth scrolling.
Eset
-
anorche1
őstag
Eleg jol boldgulok vele, sikerult mindent megcsinalnom, beallitanom. Egy dolog maradt, a gyari fajlkezloben, a pcmanfm -ben nem tudom kikapcsolni a smooth scrollt. Erre tud valaki esetleg megoldast?
Meg meg egy:
Ha dmenubol inditotam az octopit, akkor telepitskoroctopi-helper[aborted]: Suspicious execution method
hibat dob. Terminalbol inditva jo. Erre valakinek otlet? -
Frawly
veterán
válasz
anorche1
#7457
üzenetére
Az LXQt sem rossz, esetleg Openbox. Képernyő fényerejét többféleképp is le lehet venni 0-ra, vagy xbacklight vagy hasonló backlight alkalmazással 0 fényerőt megadni paraméternek (lásd man), vagy kiadni a xset dpms force off parancsot, vagy ezt hozzárendelni egy billentyűhöz.
A minimalistább WM-ek csicsásításához pedig picom kompozitort érdemes használni, ami tud vsyncet, átlátszóságot, átlátszó elmosottságot, árnyékokat, ki/behalványodási effektet, ár az LXQt-nek lehet van saját beépített kompozitora, mert az nem csak egy WM, hanem egy komplett DE.
-
anorche1
őstag
válasz
anorche1
#7456
üzenetére
Vegul az lxqt mellett dontottem. Tetszik. Egy kerdesem lenne. Hogyan tudom qt -s alkalmazasoknal (qbittorent) dark semat, colort hasznalni?
Meg egy:
KDE alatt, ha a laptop funkcio billentyuivel allitom a fenyerot, akkor lehetosegem van teljesen kikapcsolni azt. Itt hozza tudok adni egy 0 fenyeros beallitast? -
-
vargalex
félisten
Nem azt írtam, hogy a queued trim függne attól, hogy discard, vagy fstrim van-e használva. Hanem annyit, amit a wiki is ír: a queued trim tiltása esetén a discard (continuous trim) használata lassulásokat, fagyásokat okozhat.
Nekem még az előző céges notebookomban egy éppen érintett érintett Samsung EVO850-re lett cserélve a Seagate SSHD 2018 augusztusban. Nem olyan régen volt az.
-
Frawly
veterán
válasz
anorche1
#7452
üzenetére
Animációkat javaslom akkor is kivenni, ha szereted a csilivilit, mert lassítják a grafikus felület reakcióidejét. Nem a hardverigény növelése miatt, vagyis nem csak amiatt, hanem mert az animációs időt mindegy milyen kicsi értékre veszed le, valamekkora lagot okozni fog. Egy kis wobbly windows meg leállási anim effekt belefér, de pl. programok megnyitásánál, bezárásánál, váltásánál, meg a dokknál, menüknél, alkalmazásindítóknál nem éri meg használni. Jelenleg az Openbox + picom kompozitor is tudna pl. fade effekteket, de kikapcsoltam, mert mikor hirtelen alkalmazást vagy desktopot váltok, akkor nem volt azonnali a váltás.
Ugyanez a helyzet a simított görgetéssel, néhány progi azt is tudja, hogy ha darabonként görgetsz, akkor is lagot okozva, kicsit tovább, lassítva görgeti a tartalmat, és a darabos görgetési mozgások kiegyenlítődjenek, de ez meg idegesítő, mikor hosszú doksiban pozicionál az ember, és szeretne azonnal a doksi egy adott részére ugrani, és ez a csilivili effekt megnöveli a reakcióidőt.
-
Frawly
veterán
válasz
vargalex
#7442
üzenetére
A queque-d (NCQ) TRIM és annak tiltott állapota nem függ attól, hogy discard vagy fstrim-mel van-e hasznával. Az NCQ vs. nem-NCQ TRIM épp úgy megy mindkét megoldással párosítva. Plusz a kernel ATA quequed TRIM blacklistjén lévő SSD-k elég régiek, már kapni sem lehet nagyon őket, nem valószínű, hogy valaki belefut modern rendszeren.
A Dolphin-ra nem tudok mit mondani, ezek szerint tudja (bár ha fájlokról van szó, nem mappákról, akkor én nem vagyok benne biztos, hogy akkor is menni fog neki), csak locale probléma volt. Nekem eddig ezt a fajta rendezést egyik fájlkezelő se tudta (még a fájlkezelők non plus ultrája, a Total Commander se), egyik OS alatt se. Igaz nagyon korán, még a DOS-os időkben ráálltam, hogy bevezető 0-kkal toldom meg, mert úgy minden alatt működik. Meg szerintem doksiknak, mappáknak nem is a legjobb ilyen "1" és "10" nevet adni, mert visszanézi az ember pár hónap, pár év múlva, hogy az ilyen pöcs nevű fájlokról, mappákról fogalma sem lesz, hogy mi a rákra szolgáltak, egyenként meg kell nyitogatni, vagy valami view-er programmal átmenni rajtuk. Ehelyett célszerű rendes beszédes nevet adni mindennek, rendesen kiírva, ez már nem CP/M, DOS, meg FAT12-16, hogy 2-8 karakteres nevekbe kell beleférni. És a hosszú, beszédes fájlnév, mappanév még akkor se probléma, ha valaki CLI-ből használja a rendszer, terminálból, konzolból, SSH-ból, mert a Tab-os kiegészítés ilyenkor is kiegészíti őket 2-3 karakter bevitele alapján, nem kell az embernek a körmét legépelni.
Fájloknál arra is törekszek, hogy mindig legyen valami értelmes kiterjesztés, akkor is, ha Linuxon nem szokott számítani (nincs is kiterjesztés, az a név része), hogy mi a kiterjesztés. Pl. valaki itt nemrég leszólt, hogy a pain text, nem forráskódos fájloknak .txt kiterjesztést adok, mikor az felesleges, meg windowos berögződés. És ez a két utóbbi érv igaz is, én akkor is szeretem látni a kiterjesztést, mert később, évek múltán is látni fogom külön megnyitogatás nélkül, hogy mi volt benne, és nem tévesztem össze kiterjesztés nélküli shell scriptekkel, binárisokkal. De tőlem lehet .text vagy .doksi vagy .szöveg vagy akármi, csak kiderüljön micsoda, és ne legyen összetéveszthető más tartalommal, pl. plain text fájlnál .doc kiterjesztés nem jó, mert arról azt gondolhatja később valaki, hogy még a docx előtti időkből származó MS Word doksi, és a .tex kiterjesztés is megtévesztő, mert az meg a *TeX/*LaTeX forrásfájlok kiterjesztése.
-
Shyciii
veterán
Ez nem igaz. Double Commander és a PCmanFM is így rendezi sorba. És hogy jól emlékszem-e gyorsan felraktam mindkettőt újra, és nekem mindkettő így jeleníti meg a mappákat:
1
2
8
10
11
20
Double Commander beállításai között külön rendezéset lehet beállítani fileokra és mappákra is több fajtát. -
Shyciii
veterán
válasz
vargalex
#7438
üzenetére
Kéne, de nem kapja meg. És az is feltűnő volt, hogy eddig külsős megoldásból 3-at is láttam, és egyik sem csak udev-es megoldással csinálta meg. Gondolom nem véletlenül. Gyakorlatilag mindegyik csak arra használta az udev-et, hogy egy szolgáltatást restartoljon, ami meg egy scriptet indít, és scriptben kezelték le. Nekem is csak így működik rendesen. Sőt most hogy találtam végre egy fuse-t használó mtp-s programot, ami nem csak olvashatóvá teszi az mtp tartalmát, hanem írhatóvá is (simple-mtpfs, jmtpfs pl nem engedi írni, hiába adom meg opcióként akár -o rw-vel, vagy umask-al, vagy owner a saját useremmel), így azt is beleteszem majd ebbe a scriptbe szerintem, ha meg tudja különböztetni az udev azt hogy usb-vel rádugom a telefont és aközött, hogy be is kapcsolom az mtp-t rajta. Mert mindkettőnél egyelőre csak azt látom, hogy usb-s actiont ír ki, vagyis eléggé félrevezető. Ha nem tudja az sem baj, mert egy gombhoz rendeltem az mtp felmountolását és a vifm megnyitását pont abba a mappába, úgyhogy használható az is.
-
Lenry
félisten
válasz
anorche1
#7445
üzenetére
"bash color prompt"
erre keress rá, de ez külön művészeti ágegyébként a
~/.bashrcPS1kezdetű sorát kell izgatni
én pl a legtöbb gépen más színt igyekszem beállítani, hogy ezzel is elkülönüljenek, ha több gépre vagyok belépve, illetve nálam a root promptjában aroot(usernév) általában piros. -
anorche1
őstag
válasz
vargalex
#7443
üzenetére
Nem a verzioval van a gond. Manjaro alatt lefrisitettem (arra, amin arch -on is van), illetve archon downgradeltem (arra, amin manjaro volt), ujra is inditottam a gepeket, de archon tovabbra sem volt jo, manjaron igen.
Egy masik kerdesem is lenne kozben. Kde konsolban hogy lehet beallintani, hogy a
[felhaszanalonev@gepnev]mas szinu legyen mint az, amit irok, vagy ami a programnak a kimenete?
Settings/Edit Current Profil/Appearence alatt megtalaltam a temakat, meg engedi szerkeszteni az altaluk hasznalt szineket, de sajnos egyszerre valtozik minden szoveg szine (foreground sor elso oszlopban talalhato szinulesz minden). -
vargalex
félisten
válasz
anorche1
#7441
üzenetére
Nem lehet, hogy ez éppen egy bug az aktuális verzióban és a Manjaro-ban egy régebbi található? Több bug-ot is láttam ezzel kapcsolatban, pl. ezt. Ennél azt írja, hogy Natural sorting beállítás nem jut érvényre azonnal, hanem csak akkor, ha újra megnyitod a beállítások ablakot.
-
vargalex
félisten
-
anorche1
őstag
Mindenkinek:
Koszonom a trim -re adott valaszokat, bekapcsoltam a szolgaltatast.
Frawly -nak
Elinditottam egy manjaro kde live -ot, es tessek, tudja:
Szoval valahogy biztos meg lehet csinalni, nem hinnem, hogy ez a manjaronak sajat fejlesztese lenne a dolphinban.
Plusz ma reggel ujra telepitettem a arch -ot, tegnap este feltelepitettem az osszes kde applicationt, feleslegesen, ma mar csak a szuksegeseket, es egyik telepitesnel sem volt jo.
-
ztsoft
őstag
Ha már udev, nekem is van egy hibám, amire még nem találtam megoldást. Van egy udev rules, 69-disk.rules néven,
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_SERIAL_SHORT}=="877EC5BLT", RUN+="/usr/bin/hdparm -B 254 -S 0 /dev/%k"
tartalommal, egy ideig jól is működött. Pár hete viszont feltűnt, hogy a HDD kapcsolgat a laptopban, ellenőrizve az adatot, az alap értéket kaptam (128), a fenti rules nem fut le.
Lekérdezve a systemd-udev service-t, ezt kapom eredményül.
● systemd-udevd.service - Rule-based Manager for Device Events and Files Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static) Drop-In: /usr/lib/systemd/system/systemd-udevd.service.d └─50-rc_keymap.conf Active: active (running) since Sun 2020-11-29 10:36:13 CET; 9h ago TriggeredBy: ● systemd-udevd-kernel.socket ● systemd-udevd-control.socket Docs: man:systemd-udevd.service(8) man:udev(7) Main PID: 228 (systemd-udevd) Status: "Processing with 24 children at max" Tasks: 1 Memory: 29.9M CGroup: /system.slice/systemd-udevd.service └─228 /usr/lib/systemd/systemd-udevd nov 29 10:36:13 arch-acer mtp-probe[259]: checking bus 1, device 3: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7" nov 29 10:36:13 arch-acer mtp-probe[259]: bus: 1, device: 3 was not an MTP device nov 29 10:36:13 arch-acer systemd-udevd[240]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. nov 29 10:36:14 arch-acer systemd-udevd[255]: Using default interface naming scheme 'v245'. nov 29 10:36:14 arch-acer systemd-udevd[255]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. nov 29 10:36:14 arch-acer systemd-udevd[248]: Using default interface naming scheme 'v245'. nov 29 10:36:14 arch-acer systemd-udevd[246]: Using default interface naming scheme 'v245'. nov 29 10:36:14 arch-acer systemd-udevd[246]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. nov 29 10:36:14 arch-acer systemd-udevd[245]: Using default interface naming scheme 'v245'. nov 29 10:36:16 arch-acer systemd-udevd[248]: controlC0: Process '/usr/bin/alsactl restore 0' failed with exit code 99.
Az utolsó sorra rákeresve a neten, de nem találtam érdemi információt. Valami ötlet, hogy merre felé keresgéljek.
-
Frawly
veterán
válasz
anorche1
#7423
üzenetére
Beleteheted a discardot, ha akarod. A kolléga félig írta csak jól, Archon van fstrim systemd service, azzal is működőképes (ilyenkor nem kell discard), de figyelni kell, hogy alapból az sincs bekapcsolva, neked kell systemctl enable fstrim segítségével bekapcsolni, részletekért lásd a belinkelt Arch Wiki cikket. Tehát vagy-vagy módszer, rád van bízva melyik szimpatikus, melyiket használod, discard mount opció vagy fstrim service. Az SSD TRIM-ezését bármelyik megcsinálja normálisan. Mindegy melyiket választod, elég annak futnia, nem kell a kettő párhuzamosan.
#7423 anorche1: rossz hírem van, ezt nem tudja. Még a Delphinnél sokkal komolyabb fájlkezelők sem, mint a Double Commander Qt, vagy Krusader vagy hasonló kétpaneles fájlkezelők, amiket mégis élből jobban ajánlok. Ha zavar ez a rendezési mód, át kell nevezned az 1 nevű fájlokat 01-re, a 2-es nevű fájlt 02-re, erre vannak tömeges átnevezési módszerek regexp alaján, szintén lásd pl. Double Commander. Én erre Vifm + vim megoldást használok, de lehetne shell scriptet is írni, ami ls | grep | mv segítségével nevezi át.
-
Lenry
félisten
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. -
Shyciii
veterán
Ez így ebben a formában nem teljesen igaz. Van egy ilyen funkció, de alapból nem fut. Tehát aki felteszi az Arch-ot, és abban reménykedik hogy hetente lefut, az ráfázik egy idő után. Ahhoz hogy ez a funkció működjön a telepítés után, ahhoz engedélyezni kell a szolgáltatását.
-
Archttila
veterán
Termeszetesen azonnal az alkalmazas altal szallitott konfigot kerestem, de mint kiderult, az meg a regi (fejbol talan 0.9.8 alatti) verziokhoz jo, az ujhoz a githubon talslhato guide szerint kell eljarni.
Eszem agaban nem lenne ezeket csak ugy, random levadaszgatni a netrolValoban nem volt konnyu az rtorrent-et konfigolni az elejen, de mar ertem a logikajat, (basedir stb) es mint irtad csak egyszer kell megcsinalni es ez a lenyeg
Az mpd+ncmpcpp parost csak azert nem rakom fel, mert szerkesztgetes kozbeni alkalmi zenehallgatasra teljesen jo a mocp, egyeb multimedias igenyeim (ezen a pici vason) nincsenek.
-
Lenry
félisten
válasz
anorche1
#7426
üzenetére
nem kell a discard az fstabba
Arch-on a systemd hetente intézi a discardot (periodic trim), így nincs szükség a folyamatos trimet kapcsoló fstabos megoldásra.
ez ilyen vagy-vagy dolog, nem érdemes mindkettőt bekapcsolnia relatime-ot is hagyhatod, mára az az alapértelmezett beállítás, lényegesen kevesebb terheléssel jár, mint a régi atime, de megmarad a funkcionalitás, amit a noatime-al elvesztenél
-
Frawly
veterán
válasz
anorche1
#7421
üzenetére
Ja, feltűnően gyors, a jóhoz meg könnyű hozzászokni. Meg frissebb is, mint a Manjaro, ez is előnye. Pedig a Manjaro is relatíve új verziós csomagokat használ a disztrók többségéhez képest, meg nem olyan lassú, főleg, ha pl. Debian/Ubuntu-alapú disztrókkal hasonlítod össze. Pl. a pacman már régóta a leggyorsabb csomagkezelő (pl. a függőségi fát is nagyon villámgyorsan állítja össze a többi csomagkezelőhöz képest), de mióta zstd-csomagtömörítésre álltak át, azóta meg valami hihetetlen dimenzióban veri az összes többit. Főleg mikor mutatod Windows usereknek, hogy Archon mennyi egy terminálos pacmanos rendszerfrissítés (átlagos, de nagyobb), kb. 1-2 perc (jó, netsebességtől függ), abból a letöltést leszámítva a tényleges telepítési idő kb. 5-10 mp. SSD-n, nem hiszik el, mert ugyanez Windowson tart SSD-vel is 10-30 percig, mármint egy hasonló kaliberű frissítés.
A pacmant jelenleg csak az inteles Clear Linux csomagkezelője veri sebességben, de az csal, nem egész csomagokat tölt le és telepít, hanem csak a csomagok közötti deltát, különbségeket tölti le, telepíti, így nagyságrenddekkel kevesebb adatot kell megmozgatnia, eleve letölteni is sokkal kevesebb, és ez utóbbi a szűk keresztmetszet.
Pont tegnap este olvastam egy másik fórumot, hogy az userek mint szenvednek egy nem is olyan új Ryzen mobil APU-ba épített AMD IGP driverrel (meg itt ezen a fórumon is egy régi AMD R9 GPU-val), Ubuntu meg Debian alatt, mindenféle PPA-kal, meg backports kernellel vergődnek, Arch-alapú disztrón meg minden alapból van annyira friss, hogy ez nem gond (simán megy DXVK, Proton, stb.), meg a forráskódból pörgetés sem, mert rendelkezésre állnak a legújabb dev csomagot, nem úgy, mint Ubuntun, hogy csak x verzióval előttiek. Főleg akkor sajnálom ezeket a usereket, amikor ilyen Stockholm-szindróma mentén védik a megszokott disztrójukat, amit csak megszokásból használnak, hogy de jó, az ő disztrójuk enterprise grade, meg stabilabb, meg LTS, meg mit tudom én mennyivel hosszabb támogatási idő, meg release party-t is tartottak a legutóbbi kiadás megjelenésekor. Ja, támogatottabb meg stabilabb. Lenne, ha menne rajta az, amit futtatni akarnának, és nem kéne vergődni vele. Közben meg mi tudjuk, hogy a gyakorlatban az Arch-vonal a full rolling létére semmivel nem instabilabb, sőt, még azt is megkockáztatom, hogy kevesebb a probléma vele, mert Ubuntun, Minten előfordul olyan, hogy frissítés után nem bootol a GRUB, meg drivergebasz vagy rossz X.org konfig miatt nem tölt be a grafikus felület, meg disztrófrissítést nem él túl az a nagyon stabil rendszer (pl. mikor 18.04-ről 20.04-re frissítenek), ilyenbe Archon sose futottam bele, hogy egy rendszer frissítés után ilyen teljesen elemi szinten boruljon meg. Volt, hogy 1-2 csomag telepítése-frissítése hibával meghiúsult, meg 1-2 alkalmazás frissebb verziója crashelt vagy kisebb bug fordult elő vele (semmi mission critical), de ezekre is mindig van gyorsan közzétett instant workaround (downgrade, upgrade még frissebb AUR-os gites verzióra, konfigfájl átírása vagy újragenerálása, pacman átparaméterezése, felesleges fájl vagy rossz symlink kézi törlése, jogosultsági probléma kézi kiigazítása), meg nagyon gyorsan jön a javító frissítés is, néha még órák sem telnek el közötte, így aki nem pár óránként frissítőmániás, mint én voltam régen, az javarészt bele sem fut még ezekben sem, mert mire rendszerfrissítést indít el, már a javított csomagok települnek neki, persze ilyen javított csomag is évente olyan kevésszer fordul elő, hogy egy kezén megszámolja ezeket az ember, lásd. archlinux.org News szekciója, és bár ott nem írnak minden ilyenről, de nincs lényegesen több incidens azoknál, amik fel vannak ott tüntetve. Ennyit a nagy instabilitásról.
-
Frawly
veterán
Annyit még hozzátennék, hogy a fontconfignak többféle része van, és grafikus felületfüggő is. KDE-nek van erre beépített megoldása, a vezérlőpultjában kéne megnézni elsőnek. A nagy DE-knek ez a legfőbb előnye, hogy aki nem annyira haladó, azoknak is leszállítanak mindenféle saját grafikus beállítólehetőséget.
Minimalista rendszereken viszont többféle helyen kell szerkeszteni, azon linkek alapján, amit te is betettél. Lényegében ennek a fajta fontkonfignak három eleme van:
1) font config (első Arch Wiki-s link)
2) a fenti megoldás nem támogató X.org-os programoknak a .Xresources fájlban (szintén ugyanannak az Arch Wiki cikknek a vége felé írnak róla)
3) alkalmazásszinten is szükséges lehet állítani (pl. Winetricks-szel Wine-ban)
4) nem negyedik elem, csak megjegyzem, hogy Wayland alatt meg a WM/DE gondoskodik a font simításról, bár a 2)-es pontot kivéve itt is ugyanazok a pontok játszanak.Firefoxhoz nem kötelező a Liberaton fontot feltenni, azt a megoldást is lehet választani, hogy az ember felrakja a saját fontjait (én pl. DejaVu, de ki mire gerjed, fel lehet tenni Ubuntu, Terminus, Droid, Roboto, Opensans, MS fontokat is), és beállítja azt Firefox-ban, a Beállításoknál, hogy a fallback fontokat azzal renderelje, pl. DejaVu Sans.
Egyébként meg ez Archon eleinte szokatlan lesz, hogy ami Manjaro-n alapból ment, meg jó volt, ahhoz Archon varázsolni kell. Ez nem azért van, mert az Arch szar, meg a felhasználókat jól meg akarják szopatni, hanem szándékosan default konfiggal jönnek az alkalmazások, és defaulton nem a disztró saját beállítását értem, hanem az egyes alkalmazások fejlesztőinek a defaultját, ahol lényégében semmi nincs testre szabva, semmi extra nincs feltéve, se feltémázva. Ez azt okozza, hogy nincs semmi beállítva, mert az Arch nem akar találgatni, hogy mi a jó a felhasználónak, arra számítanak, hogy haladó user rakja fel, aki úgyis testre szab magának mindent, és nem akarják kristálygömbbel előre találgatni, hogy milyen beállítás, téma, stb. lesz jó neki. Azért meg nem akarnak egy csomó csomagot feltenni (pl. Octopi), meg csomó konfigot beállítani (pl. pont ez a szóban forgó font config), hogy aztán a felhasználónak azzal kelljen kezdenie az Arch-telepítést, hogy egy csomó csomagot le kell szedjen, meg mindent át kell újra állítgasson.
Sokszor egyébként gépfüggő is a fontbeállítás. ThinkPad X220-amnak elég gyopár HD TN kijelzője van, ami kicsi is (12 col), azon muszáj volt bekacsolni a max. RGB fontsimítást, legerősebb fokozatú Hintinget. Érdekes mód erre az új laptopon nem volt szükség, mert azon már rendes, 15,6 colos FullHD IPS kijelző van, ami a finomabb felbontással, kisebb pixelekkel eleve úgy rendereli a fontokat, hogy nem kell akkora korrekció.
A másik, ami Archon feltűnő lesz, hogy több frissítés lesz, mert nem tartják vissza a verziókat egyel, mint a Manjaro. Ha az ember bekapcsolja Archon a Testing tárolókat, akkor meg még több frissítés lesz.
-
Lenry
félisten
válasz
anorche1
#7418
üzenetére
ebbe én is belefutok mindig, amikor új gépre rakom fel az Archot.
első körben fusd át a Wiki idevonatkozó részeit
Font configuration
Firefox#Font troubleshooting
Rondák a betűk a Feuerfuchsban -
anorche1
őstag
Sziasztok!
A mai napon hatra hagytam a manjarot, es beleptem az arch -ot hasznalok koze, de sajnos-nem sajnos, a kde -t nem engedem el.
Az elso szembetuno kulonbseg, hogy valahogy manjaro alatt szebbek voltak a fontok. A rendszer alatt is, de foleg firefox alatt nagyon szembetuno. Hogy tudnam elerni, hogy ugy nezen ki mint manjaro alatt?
-
Frawly
veterán
válasz
Archttila
#7409
üzenetére
Egyébként ezzel a minimálosítással is vigyázni kell, nem szabad túl intenzíven erőltetni. Ez egy fejlődési folyamat, fokozatos, több állomással, nem nagyon lehet siettetni, erőltetni. Idő kell, míg megtalálod mindenre a terminálos alternatívát, megtanulod bekonfigolni, megszokod, rááll a kezed. Ez nem megy 5 perc alatt, hogy csettint valaki egyet, és akkor onnan minimalista, annak is vannak fokozatai. Én is fokozatosan haladok, mai napig találok még optimalizálni valót a rendszeren, nemrég dobtam ki a pavumixert, qbittorrentet, csiszoltam egy-két alkalmazásindító scriptemen, stb.. Anno a vim-nek is nagyon sokszor neki kellett futni, pálcika WM-eket is nehezen szoktam meg, nehéz volt bekonfigurálni a neomutt-ot és a hasonló megoldásokat.
-
Shyciii
veterán
Amíg KDE-t használtam, addig én is azt hittem, hogy gyors. Egészen addig míg nem kezdtem egyre "feljebb" lépkedni.
Acer Aspire 5-öm van Core i3-7130U 2.7GHz, 3MB L3 cache-el 4GB rammal, intel UHD videókártya (csak ezt használom), és van egy nvidia geforce mx130-as is, de sose működtetem. Bár nekem is SSD-m van, de nem NVMe-s, csak egy mezei hiper olcsó kingston.
Amúgy nekem a boot kevesebb, mint 5-7mp, olyan 4mp, és nem a grub-tól, hanem kompletten a power gomb megnyomása utána...A programokra sem várok 1-2mp-et hogy elinduljanak. Nálam az azonnali elindulás, az azonnali elindulás. Kivéve a Chromium. -
Frawly
veterán
Ez ilyen, ezért nem szabad egy márka vagy gyártó fanjának lenni, meg termékeket márkamegszokásból venni. Azt kell megvenni gyártói névtől függetlenül, ami épp a jobb vétel. Régen én is főleg Intelt vettem, de nem márkafanságból, hanem vagy mert az volt a jobb vétel akkor, vagy mert a használt gépeim azzal jöttek, főleg, mióta laptopokat használok inkább. De az AMD mindig is szimpatikusabb volt, azonos árban nagyobb teljesítményt tudott, mint az Intel, és általában az újabb generációk is beletehetők ugyanabba a lapba, foglalatba, nem kell generációnként lapot cserélni alatta. De ez régen is így volt, késő 90-es évek, kora 2000-es években, pl. mikor az AMD a K6 sorozattal Pentium Pro, P2 teljesítményt nyújtott Celeron árában, Ahtlon-nal P3 teljesítményt nyújtott Celeron árában, vagy AthlonXP-vel P4 teljesítményt Celeron árában, aztán a P4-eket elkezdte verni az AMD64, a PentiumD-ket az Athlon x2, bár eddig az időszakig egy ponton elvérzett mindig az AMD, a lapok, chipsetek gyengébbek voltak alá. A Phenomok se voltak rosszak, de ott az Intel átvette előbb a Core2-vel a vezetést (Duo, Quad), majd a Core i vonallal, de 2017-től a Ryzen-nel nagyon komolyan visszaküzdötte magát az AMD, most így 2020-ra már mindenben verik az Intelt. De ez még Intel fanoknak is jó, mert ha a Ryzenek nem diktálnának ilyen kemény versenyt és fejlesztési tempót, akkor az Intel még mindig 2 mag 2 szálat adna a Pentiumokkal, 2 mag 4 szálat adna az i3-akkal, 4 mag 4 szálat az i5-ökkel, 4 mag 8 szálat az i7-ekkel. De így szépen elkezdte duplázni a magokat, aztán a szálakat is, meg behozták az i9 vonalat, beindult a verseny. Ennek pedig főleg a végfelhasználó látja előnyét, mindegy melyik márkát veszi, melyik modellt, melyik gent, újat, használtat, az árak a fejlődés miatt fokozatosan mennek le, főleg akkor, ha valaki nem a legújabb gent veszi.
-
Frawly
veterán
válasz
Archttila
#7410
üzenetére
Ez a baj, ha más konfigját veszed át, főleg, ha nem 1:1-ben. Célszerű ezért mindig az alkalmazáshoz szállított default konfigból elindulni, ami általában a /usr/lib/alkalmazásnév/ mappában van, ritkábban a /usr/share/alkalmazásnév vagy /usr/share/doc/alkalmaznév elérhetőségi úton és ezt a default konfigot módosítani saját igény szerint, fel lehet használni más konfigjából is sorokat, de nem 1:1-ben, hanem csak ihlet szintjén.
Konkrétan az rtorrent default konfigja ezen az elérési útkon kéne, hogy legyen, elvileg, mert nálam nincs ott:
/usr/share/doc/rtorrent/rtorrent.rcEz az rtorrent ilyen, nem felhasználóbarát, nehéz konfigolni, könnyű elrontani, elég, ha valahonnan egy / jel vagy idézőjel, zárójel hibádzik, nem lesz jó az egész konfig. Cserében viszont egyszer elég megcsinálni, utána a konfigfájlt elmentve és visszahúzva örökkévalóságig működik.
Az mpd + ncmpcpp nem rossz páros, mert igaz, hogy több függősége van, de többet is tud, mint a moc meg a cmus, és a függőségek közül a legtöbb apró, pár KB-os csomag. Van pár nagyobb, de azok sem baj, ha fent vannak faad2 (ez aac fájlok kezelésére van, nyílt aac kódek), python (sok minden használja ezt az v1-eset is, igaz az újabb progik már a v3.x-es verziót használják), fluidsynth (ez MIDI soundfont támogatáshoz, lejátszáshoz kell elvileg), fftw (ez a viusaliser modulhoz kell). Egyedül három dolgot nem látok indokolnak, libnfs, smbclient, igaz ezek azért vannak ott, hogy hálózati megosztásból is tudjon lejátszani, és a libgme, amiről fogalmam sincs micsoda, pacman -Qi vagy -Si segítségével el lehet olvasni. A lényeg, hogy ezeknek a függőségeknek a 99%-a kell amúgy is multimédiás dolgokhoz.
Ezeknek a csomagoknak a nagy részét bármilyen multimédiás program, lejátszó, konvertáló, kódek behúzza, nálam pl. az ffmpeg, meg az mpv nagyon kell, behúzta ezeknek a nagy részét, amit írsz, pythonon is alapul egy csomó progi, fluidsynth-et kézzel kellett felraknom a Re-Volt játék RVGL natív portjához.
Én egyébként azért nem szeretem annyira az mpd + ncmpcpp párost, mert nekem túl bonyolult, túl nehezen konfigurálható. Ha már így megküzdöttél az rtorrent-tel, nem akarlak elkeseríteni, de a fenti páros konfigja egy nagyságrenddel nehezebb, mert annyival bonyolultabbak, ráadásul két konfig is lesz, egyik az mpd-hez, a másik a klienshez. Rohadt bonyás, nagyon sok billkombót kell fejben tartani, egyszerűen nem bírok hozzászokni. Pedig jó cucc, nagyon sokat tud, jól lehet scriptelni, mindenféle kijelző és távirányítós/hotkey modulokat írni hozzá pálcika WM-ekhez, panelekhez, de cserében nekem túl összetett, majdnem egyetemi tárgyként lehetne oktatni. Ezért szoktam a cmus-nál maradni, alapokat az is tudja, billentyűparancsa kevesebb van, könnyebbem megtanulható a kezelése, könnyebben konfigolható, kisebb, kevesebb függősége van.
-
Archttila
veterán
Működik az rtorrent
elírtam az elején a basedir-t, így nyilván a többi már nem ment neki illetve a Create instance directories alatt módosítottam a watch szekciót, és most már nem hozza a létre a két subfoldert sem.
A watch directories alatt szintén kivettem a két load/start elérést, és csak *.torrent -et adtam meg neki.
A többit majd belövöm később
-
Archttila
veterán
mpd ncmpcpp
Nekem ennyit nem ér... marad moc. Alkalmi zenehallgatásra tökéletes. $ > sudo pacman -S mpd ncmpcpp[sudo] password for alucard:resolving dependencies...looking for conflicting packages...warning: dependency cycle detected:warning: cifs-utils will be installed before its smbclient dependencyPackage (43) New Version Net Change Download Sizeextra/audiofile 0.3.6-6 0.31 MiB 0.12 MiBextra/boost-libs 1.72.0-2 8.15 MiB 1.69 MiBextra/chromaprint 1.5.0-3 0.11 MiB 0.04 MiBextra/cifs-utils 6.11-1 0.19 MiB 0.08 MiBextra/faad2 2.10.0-1 0.50 MiB 0.15 MiBextra/fftw 3.3.8-3 4.42 MiB 1.17 MiBextra/fluidsynth 2.1.5-2 0.55 MiB 0.19 MiBextra/hwloc 2.2.0-1 1.15 MiB 0.38 MiBcommunity/jansson 2.13.1-1 0.13 MiB 0.03 MiBextra/ldb 1:2.2.0-1 0.63 MiB 0.17 MiBextra/libao 1.2.2-5 0.18 MiB 0.05 MiBextra/libbsd 0.10.0-2 0.34 MiB 0.16 MiBextra/libcddb 1.3.2-6 0.13 MiB 0.04 MiBextra/libcdio 2.1.0-2 0.82 MiB 0.23 MiBextra/libcdio-paranoia 10.2+2.0.1-2 0.14 MiB 0.06 MiBextra/libgme 0.6.3-1 2.21 MiB 0.50 MiBextra/libinstpatch 1.1.5-1 1.03 MiB 0.25 MiBextra/libmikmod 3.3.11.1-4 0.53 MiB 0.17 MiBextra/libmms 0.6.4-3 0.07 MiB 0.03 MiBextra/libmpcdec 1:0.1+r475-3 0.08 MiB 0.03 MiBcommunity/libnfs 4.0.0-4 0.57 MiB 0.11 MiBcore/libnsl 1.3.0-1 0.17 MiB 0.05 MiBextra/libshout 1:2.4.4-1 0.14 MiB 0.05 MiBcommunity/libsidplayfp 2.0.2-1 0.43 MiB 0.11 MiBextra/libupnp 1.14.0-1 0.66 MiB 0.16 MiBextra/liburing 0.7-2 0.05 MiB 0.03 MiBextra/lmdb 0.9.27-1 0.44 MiB 0.07 MiBextra/mpg123 1.26.3-2 0.91 MiB 0.33 MiBextra/openal 1.21.0-1 1.28 MiB 0.42 MiBextra/openmpi 4.0.5-2 8.52 MiB 2.73 MiBextra/portaudio 1:19.6.0-7 0.30 MiB 0.08 MiBextra/python 3.8.6-1 49.29 MiB 10.22 MiBextra/smbclient 4.13.2-1 24.33 MiB 5.53 MiBextra/taglib 1.11.1-4 1.38 MiB 0.28 MiBextra/talloc 2.3.1-3 0.14 MiB 0.04 MiBextra/tevent 1:0.10.2-1 0.15 MiB 0.04 MiBcommunity/twolame 0.4.0-2 0.22 MiB 0.07 MiBextra/wavpack 5.3.0-1 0.38 MiB 0.14 MiBextra/wildmidi 0.4.3-3 0.22 MiB 0.08 MiBextra/yajl 2.1.0-4 0.18 MiB 0.04 MiBextra/zziplib 0.13.71-1 0.24 MiB 0.05 MiBextra/mpd 0.22.3-1 2.51 MiB 0.70 MiBcommunity/ncmpcpp 0.8.2-12 2.29 MiB 0.56 MiBTotal Download Size: 27.45 MiBTotal Installed Size: 116.49 MiB:: Proceed with installation? [Y/n] -
Lenry
félisten
"Mondjuk az igaz, hogy én i3-at nem vennék"
ma már én sem.
én döntök a cégben az informatikai beszerzésekről és töredelmesen bevallom, hogy a saját hülyeségem, hogy eddig Intelt vettünk. egyszerűen nem foglalkoztatott az AMD, ha kellett egy gép, akkor kinéztem, hogy melyik Intel CPU felel meg a felmerülő igénynek és azzal rendeltem a gépet.
aztán most nyáron vettünk egy Ryzen 5 4500U-s laptopot és a hajam letettem attól, amit a GPU-ja 4K-ban tud, meg nem sokkal később kellett egy fejlesztői gép és körbenéztem az AMD-s oldalon: 6 mag 12 szál 60k-ért?
Inteléknél ugyanez 100 fölött van.
azóta most csak AMD-s gépeket veszek, de idő, amíg átbillen a mérleg...
mindig megtartom a CPU dobozokat, az Inteles piramisban olyan 40 doboz van, az AMD-s most jól láthatóan kilencnél tart
bocsi a hosszú OFF-ért
-
Archttila
veterán
Elképzelhető, hogy jó lesz amit javasoltál, viszont a 25. sorban valami nem tetszik neki.
rtorrent: Error in option file: ~/.rtorrent.rc:25: Bad return code.
Kiemeltem a 25. sort:## Create instance directories
execute.throw = sh, -c, (cat,\
"mkdir -p \"",(cfg.download),"\" ",\
"\"",(cfg.logs),"\" ",\
"\"",(cfg.session),"\" ",\
"\"",(cfg.watch),"/load\" ",\
"\"",(cfg.watch),"/start\" ")Próbáltam úgy módosítani a 24. és 25. sort, hogy a ne hozza létre, ne használja a start/load foldereket, de sajnos nem sikerűlt. Annyi lenne a lényeg, hogy csak és kizárólag a /home/alucard/Downloads/ mappa alatt figyelje a *.torrent fájlokat, mivel böngészőből automatikusan minden ebbe a mappába zuhan be, és ha ezt módosítom, akkor csak a torrent miatt állandóan browseolni kell... felesleges.
Ha ez megvan, a többit már én is be tudom állítani. (DHT, max peer stb)bemásolom a konfig elejét az instance layout-tal együtt:
## Instance layout (base paths)method.insert = cfg.basedir, private|const|string, (cat,"/mnt/PiDirve1/")method.insert = cfg.download, private|const|string, (cat,(cfg.basedir),"Downloads/")method.insert = cfg.logs, private|const|string, (cat,"/home/alucard/.local/share/rtorrent/log/")method.insert = cfg.logfile, private|const|string, (cat,(cfg.logs),"rtorrent-",(system.time),".log")method.insert = cfg.session, private|const|string, (cat,(cfg.basedir),".session/")method.insert = cfg.watch, private|const|string, (cat,"/home/alucard/Downloads/")## Create instance directoriesexecute.throw = sh, -c, (cat,\"mkdir -p \"",(cfg.download),"\" ",\"\"",(cfg.logs),"\" ",\"\"",(cfg.session),"\" ",\"\"",(cfg.watch),"/load\" ",\"\"",(cfg.watch),"/start\" ") -
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
Az 5-7 mp-es bootidő valóban nem rossz, azt nem tudom, hogy minimalistább megoldással mennyit gyorsulna, nagyon gépfüggő is, és nem csak a procitól függ, hanem SSD-től is. Az i3-9100F szerintem nem olyan rossz proci, simán hozza a korai genes i5-i7-esek szintjét, mert igaz, hogy csak 4 mag, 4 szál, de több cache, magasabb IPC, magasabb órajel, újabb utasításkészletek, PCIe 3.0 sávok és a DDR4 nagyobb sávszélessége, stb.. Szóval az i3 név megtévesztő, desktop Intel prociknál újabb genből, 8-10. gen nem olyan rossz, annyit fejlődtek mára a procik, hogy még egy ilyen alsóbb kategóriás is veri a néhány generációval korábbi felső kategóriásakat. A még újabb i3-10100 pl. a tesztek alapján az i7-7700K szintjén van, igaz az már 4 mag 8 szál, de ez a 9100F is simán hozza szerintem az i5-6600 és i7-4770 szintjét.
Mondjuk az igaz, hogy én i3-at nem vennék, az i3-9100 megjelenése idején már a Ryzen 1600 is elég olcsó volt, az nem csak olcsóbb (lap is olcsóbb alá), de 6 mag, 12 szál, háromszor annyi cache, magasabb frekis RAM-ot is támogat, bár kisebb IPC, kisebb CPU órajel, de a lap is olcsóbb hozzá, meg az AM4-e foglalatot tipikusan később olcsón felbővítheted Ryzen 5800X-ig minimum (ha B450, B550, X470, X570-es chipsetes), a Ryzen 5900-5950X már lapfüggő, hogy mit bír a VRM. Meg átlag felhasználásnál, ami nem használ túl sok magot, nem nagyon érezni a különbséget a Ryzen 1600 vs. i3-9100F, játékoknál is határeset, hogy mivel nézzük, mennyire érzékeny a frekire az adott játék. De a Ryzen mindenképp jövőtállóbb platform.
-
Lenry
félisten
"Harmada-negyede boot és lag a progik betöltésénél, háromszor-négyszer olyan gyors leállás"
heti egyszer indítom újra a gépet, akkor is nagyjából 5-7 másodperc alatt jutok el a Grubtól az asztalig, a maradék 167,999 órában meg folyamatosan be van kapcsolva.
programok indítása szintén 1-2 másodperc.
és ez nem egy überhyper gép, hanem egy négymagos i3, annyi, hogy NVME-s SSD-n van a rendszer meg a /home is, de nem hiszem, hogy ez akkora truváj.
tehát ennek fényében kérdem, hogy valójában mi jelentősége lecsupaszítani mindent*, meg a huszadik DE-t felrakni, mikor egy aktuális modern gép röhögve elvisz egy KDE-t"hogy van indítómenü, meg asztali ikonok, mindent egérrel csinálok, stb.. Ez annyira mélyen be tud ivódni az emberben"
egyetlen ikon sincs az asztalomon vagy a tálcámon, a leggyakrabban használt programokat Win+1, Win+2, stb kombókkal indítom, minden másra ott a
MasterCardAlt+F2ne érts félre, senkit nem akarok semerre orientálni, csináljátok nyugodtan, csak pár hsz-t visszaolvasva úgy éreztem magam, mint amikor 128MB RAM-om volt a 466-os Cerka mellett, aztán a fentebb felsoroltak valóban számítottak, és azt hittem itt is valami ilyesmiről van szó.
* mármint nyilván azon túl, hogy van, aki szeret ezzel pöcsörészni
-
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.
-
Shyciii
veterán
-
Archttila
veterán
Este kiprobalom, koszi!
A Bspw nekem is tetszik. Azt hittem valami lehetetlensegig bonyolitott valami de nem, pont ellenkezoleg, egyszerubbnek es atlathatobbnak tunik a konfigja mint mondjuk az xmonad-nak.
Egyelore marad a Sway, mert nagyon tetszik a X mentes elet.
Ossze sem lehet hasonlitani a jelenlegi rendszerem sebesseget az elozovel. A Manjaro Xfce edition kb felkajalja a teljes Pi-t, itt meg kb szaguld minden. Ha teszek ala OC-t akkot meg plane. Szoval teljesen elegedett vagyok vele, pedig egy Ryzen 3900x rol jottem, gondolhatod A terminalos dracula colour-al kapcsolatban igazad van, tenyleg belerondit a kinezetbe, szoval ezen lehet valtoztatok, bar annyira nem gaz, foleg mert mc ala is van dracula kinezet, a htop meg még az elmegy kategoria...
Sed-el nem barmoltam bele, hanem azzal generaltam nullarol a konfigot. Elvileg ez a helyes metodus. (GitHub)
-
Frawly
veterán
Most a Berry WM-et teszteltem (ez is X.org WM, nem Wayland), ez egy bspwm mintájára működő, minimalista WM, de nem tiling, hanem stacking, de épp úgy a saját command interface-ére épül, meg sxhkd-re. Ehhez képest szerintem még használhatatlan állapotban van. Pl. ha floaing ablakok között egérmutatóval váltanék, akkor a fókuszt kapó ablak sokszor a háttérben marad, nem hozható az előtérbe. Nem kezel taskváltást. Nem lehet neki beállítani, hogy új program indulásánál az ablakot maximális (de nem teljes képernyős) módban indítsa. Ezen a szinten ez még felejtős, nincs készen a hétköznapi használatra, kár érte, mert majdnem ott lenne, 1-2 apróságot leszámítva, de azok még nagyon hiányoznak belőle. A következő nekifutásom bspwm-mel lesz.
-
Frawly
veterán
válasz
Archttila
#7400
üzenetére
Ezt én így oldanám meg, de a külső drive-nak nem tudjuk az elérési útját, így azt /kulso/-ként adom meg:
# Instance layout (base paths)
method.insert = cfg.basedir, private|const|string, (cat,"/kulso/")
method.insert = cfg.download, private|const|string, (cat,(cfg.basedir),"Downloads/")
method.insert = cfg.logs, private|const|string, (cat,"/home/usernev/.log/")
method.insert = cfg.logfile, private|const|string, (cat,(cfg.logs),"rtorrent-",(system.time),".log")
method.insert = cfg.session, private|const|string, (cat,(cfg.basedir),".session/")
method.insert = cfg.watch, private|const|string, (cat,"/home/usernev/watch/")Az user mappájának szándékosan írtam konkrét elérési utat, /home/usernev/ formájában, a ~/ is működne, de ha másik userrel lépsz be, akkor másik mappában fogja ezeket keresni.
A mappákat kézzel érdemes létrehozni az rtorrent használata előtt. Konfigfájlba meg nem érdemes sed-del belebarmolni, mert nem látod mit csinál, mit mire írt rá. Kézzel nagyobb munka, de ott tudod nyomkövetni mi mire lett átírva, mi nem működik.
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).
Annyit korrigálnék csak rajta, hogy én nem azt írtam, hogy a Wayland miatt gyorsabb a Chrome hanem azt, hogy a 87-be már hivatalosan is támogatva lesz ez a ficsör. 
Az ARM-es FF ehhez képes egy kövület. Uccu neki kapcsoltam is egy VA-API-t és áhhh, nem akarom elhinni amit látok, valami eszméletlen mennyire más élmény mint a róka. Erősebb, x86 hardware-en nem jön ki a különbség, de itt...
Inteléknél ugyanez 100 fölött van.
Új hozzászólás Aktív témák
Hirdetés
BoB- GYÖNYÖRŰ iPhone 13 Pro 128GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3084, 95% Akkumulátor
- HUAWEI MateBook 13 2020 - Kijelző nélkül - I7-10510U - 16GB - 512GB SSD - Win11 - MAGYAR
- GYÖNYÖRŰ iPhone 12 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS2904, 96% Akkumulátor
- MikroTik CCR1009-7G-1C-1S+ Cloud Router
- Thomson Streaming Box 240 TV okosító / Számla / Garancia /
Állásajánlatok
Cég: FOTC
Város: Budapest