- Honor 200 Pro - mobilportré
- Milyen okostelefont vegyek?
- Poco F3 - a mindenes, de nem mindenkinek
- Android alkalmazások - szoftver kibeszélő topik
- Érintésnélküli fizetési megoldások - PayPass via NFC
- Telekom mobilszolgáltatások
- Samsung Galaxy S20 és S20+ duplateszt
- Poco X6 Pro - ötös alá
- Szimpatikusnak tűnik a T Phone új generációja
- Samsung Galaxy Watch6 Classic - tekerd!
Hirdetés
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Honor 200 Pro - mobilportré
ma AI portrémóddal támad a Honor, csúcskategóriába kúszott árazással.
-
Demót kapott a Steel Seed (PC)
gp A Steam Next Fest keretén belül bárki kipróbálhatj a készülő játékot.
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
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.[ Szerkesztve ]
-
anorche1
őstag
Ha esetleg mas is keresne, mert en a neten nem talaltam meg:
Kde desktop effect sebesseg allitas: ~./config/kwinrc fajl, AnimationDurationFactor=ertekkel lehet allitani."It never gets easier, you just go faster." Greg LeMond
-
Frawly
veterán
válasz vargalex #7442 üzenetére
A queque-d (NCQ) TRIM és annak tiltott állapota nem függ attól, hogy discard vagy fstrim-mel van-e hasznával. Az NCQ vs. nem-NCQ TRIM épp úgy megy mindkét megoldással párosítva. Plusz a kernel ATA quequed TRIM blacklistjén lévő SSD-k elég régiek, már kapni sem lehet nagyon őket, nem valószínű, hogy valaki belefut modern rendszeren.
A Dolphin-ra nem tudok mit mondani, ezek szerint tudja (bár ha fájlokról van szó, nem mappákról, akkor én nem vagyok benne biztos, hogy akkor is menni fog neki), csak locale probléma volt. Nekem eddig ezt a fajta rendezést egyik fájlkezelő se tudta (még a fájlkezelők non plus ultrája, a Total Commander se), egyik OS alatt se. Igaz nagyon korán, még a DOS-os időkben ráálltam, hogy bevezető 0-kkal toldom meg, mert úgy minden alatt működik. Meg szerintem doksiknak, mappáknak nem is a legjobb ilyen "1" és "10" nevet adni, mert visszanézi az ember pár hónap, pár év múlva, hogy az ilyen pöcs nevű fájlokról, mappákról fogalma sem lesz, hogy mi a rákra szolgáltak, egyenként meg kell nyitogatni, vagy valami view-er programmal átmenni rajtuk. Ehelyett célszerű rendes beszédes nevet adni mindennek, rendesen kiírva, ez már nem CP/M, DOS, meg FAT12-16, hogy 2-8 karakteres nevekbe kell beleférni. És a hosszú, beszédes fájlnév, mappanév még akkor se probléma, ha valaki CLI-ből használja a rendszer, terminálból, konzolból, SSH-ból, mert a Tab-os kiegészítés ilyenkor is kiegészíti őket 2-3 karakter bevitele alapján, nem kell az embernek a körmét legépelni.
Fájloknál arra is törekszek, hogy mindig legyen valami értelmes kiterjesztés, akkor is, ha Linuxon nem szokott számítani (nincs is kiterjesztés, az a név része), hogy mi a kiterjesztés. Pl. valaki itt nemrég leszólt, hogy a pain text, nem forráskódos fájloknak .txt kiterjesztést adok, mikor az felesleges, meg windowos berögződés. És ez a két utóbbi érv igaz is, én akkor is szeretem látni a kiterjesztést, mert később, évek múltán is látni fogom külön megnyitogatás nélkül, hogy mi volt benne, és nem tévesztem össze kiterjesztés nélküli shell scriptekkel, binárisokkal. De tőlem lehet .text vagy .doksi vagy .szöveg vagy akármi, csak kiderüljön micsoda, és ne legyen összetéveszthető más tartalommal, pl. plain text fájlnál .doc kiterjesztés nem jó, mert arról azt gondolhatja később valaki, hogy még a docx előtti időkből származó MS Word doksi, és a .tex kiterjesztés is megtévesztő, mert az meg a *TeX/*LaTeX forrásfájlok kiterjesztése.
-
Frawly
veterán
válasz anorche1 #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.
[ Szerkesztve ]
-
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.
Alex
-
anorche1
őstag
Mappa nevhez:
Sorozatrol van szo, season 1, season 2, season 1x.... Itt volt a kavarodas.Mas:
Ha el szeretnek indulni a minimalizmus utjan, mi a legkonnyebben hasznalhato, legkonnyebben beallithato, legfelhasznalobaratabb minimalista wm?
[ Szerkesztve ]
"It never gets easier, you just go faster." Greg LeMond
-
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?[ Szerkesztve ]
"It never gets easier, you just go faster." Greg LeMond
-
Siriusb
veterán
systemd kérdés:
timer-rel időzitve futtatok egy .service unit-ot (user szinten). Miként tudom elkerülni, hogy ne rakja be a log-ba az indítást/befejezést minden egyes alkalommal, amikor lefut?
-
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
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?[ Szerkesztve ]
"It never gets easier, you just go faster." Greg LeMond
-
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
[ Szerkesztve ]
-
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.
-
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 Killed
Dec 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:0
A pieces.memory.max.set = 1000M (elvileg a fizikai RAM fele ajánlott, de nekem a negyedével is elszáll)
[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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/pikaur
mappá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.[ Szerkesztve ]
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
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.
[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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 -si
parancssal fordíthatod és telepítheted a letöltött verziót.
Alex
-
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. -
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.
-
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 = 1000M
max_memory_usage = 512M
download_rate = 8192
upload_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)
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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.
[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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...
-
Lenry
félisten
válasz Shyciii #7480 üzenetére
A raspberryOS gyakorlatilag egy ARM alapú Debian, a Debian tárolókban pedig még csak 83-as Chromiumnál tartanak, de biztos vagyok benne hogy le lehet valamilyen repoból szedni frissebbet is
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Frawly
veterán
válasz Archttila #7479 üzenetére
Nekem ezek a számok nem tűnnek rossznak, szerintem nem annyira brutál memófoglalás. Az is igaz, hogy nem mutattál free -m kimenetet (látszódjon a shared, cache is), meg azt se értem, hogy a htop-ban a RPi4 memóriájából miért csak 3,3 GB látszik, mikor 4-nek kell lennie? Nem 32 bites rendszert futtatsz 64 bites helyett? Mert a 32 bit megmagyarázná a korábbi forráskódból forgatási problémáidat is. Vagy 64 bites az, és az RPi integrált GPU-ja vesz le a rendszermemóriából. Bár memóriád így is van szabadon, a háttérben fut minden, komplett grafikus felület, terminálok, progik, MiniDLNA, torrent, stb., ahhoz képest nem valami sok a 438 MB-os fogalás, majdnem 3 GB szabad memória van, ilyen felállásban én nem sok értelmét látom a swapnak. Bár betehetsz, de akkor arra figyelj, hogy még véletlen se HDD-ről fusson, meg SD kártyáról, meg eMMC tárolóról, hanem rendes SSD legyen alatta. Nem baj, ha csak valami olcsó, SATA3-as szutyok, de rendes desktop vagy M.2 SATA vagy hasonló SSD legyen.
Gigabites net kihajtásának ez az ára egyébként, ha tényleg több szálon van hajtva, akkor meg is van, hogy az rtorrent-nek is miért volt magas a CPU használata. A több szálas gigabites torrent már sokat tud enni egy szabvány windowsos PC-n is, mind memóriából, mind prociból.
Ez a Chernobyl sorozat szerintem nem valami jó, bár azt se értem, hogy egy Trinity-kiadásnak hogyan lehet epizódonként 25 gigás mérete, még 4K-ban sem kéne annyit foglalnia. Én is elkezdtem nézni ezt a Chernobylt (épp így talán Trinity Blu-Ray 1080p-s felbontás), és ugyan pl. a korszak jól van benne ábrázolva, emberek, épületek, ruhák, stb., de az egész történet el van torzítva benne, szakmai helytelenségekkel, meg csak marék szereplővel dolgozik, mintha csak azok vettek volna részt mindenben. Az egész annyira el van rugaszkodva a valóságtól, hogy szerintem időpazarlás megnézni.
A linkeden a faszinak a gondját meg szerintem nem bug okozza, hanem a külső HDD-je haldoklik vagy nem kap elég delejt, mert valami ócska kínai táppal hajtja, vagy nem aggat rá külön tápot, az USB foglalatból meg nem tud elég naftát felvenni.
-
Frawly
veterán
válasz 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.
-
Lenry
félisten
Az egész annyira el van rugaszkodva a valóságtól, hogy szerintem időpazarlás megnézni.
az megvan, hogy ez nem egy dokumentumfilm?
azt pl külön elmondták, hogy rengeteg embert sűrítettek 1-1 szereplőbe, mert dramaturgiailag így lett nézhetőGvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
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.
[ Szerkesztve ]
-
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.Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
free -m
total used free shared buff/cache available
Mem: 3394 644 157 159 2593 2548
Swap: 0 0 0
6.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...[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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.
-
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.[ Szerkesztve ]
-
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.
-
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ó[ Szerkesztve ]
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Ismét köszi a részletes választ! 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.
[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
-
Siriusb
veterán
KDE használókhoz lenne kérdésem: krunner-ben fájlkeresés nem működik, nálam van probléma, vagy valami frissítés kavart be? Pl. invoice.pdf-re akarok keresni, csak egy üres sort dob fel, amit aktiválva "Malformed URL" az üzenet.
-
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.
-
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 ]
Új hozzászólás Aktív témák
- Politika
- Szünetmentes tápegységek (UPS)
- Betelik a pohár: nagy igény lenne a gyorshajtás-ellenes technológiára
- Robogó, kismotor
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Háztartási gépek
- E-book olvasók
- Kés topik
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- Trollok komolyan
- További aktív témák...