-
Fototrend
Arch Linux topik
Új hozzászólás Aktív témák
-
ubyegon2
nagyúr
Belefér, de szét van szórva, a Linuxos programok topik mintájára nem lenne elvetendő ötlet egy helyen kezelni a témát, egy jó összefoglalóval az elején. Így gyakorlatilag fragmentált nagyon és senki nem talál semmit, hanem kérdez egyből.
Ez a téma ugyanúgy érdekelheti a Debianosokat, Fedorásokat, mint az Archereket, Gentoosokat (lehet, hogy egyes szám elég lett volna itt)
A Wayland WM-es kalandjaimat a Linux OFF topikba szoktam írni a magam részéről, mivel ott semmi nem OFF.
Na látod! Akit érdekel a WM téma, örömmel olvasná ezeket is.....
Na mindegy, csak egy ötlet volt.
-
Shyciii
veterán
Frawly
KDE-s Wayland? Most a Waylandnek nem az lenne az értelme, hogy egy egységes szabvány legyen, és mindenki azt használja? Most akkor ezt is mindenki csűri csavarja, és nem lesz egységes?
A LightDM-re az Arch Wiki azt írja, hogy támogatja a Wayland-et: https://wiki.archlinux.org/index.php/LightDM
Én élvezem a testreszabást. Jobban, mint egy agyontelepített kész DE-t használni. Engem az éltet, hogy bütykölhetek. Épp ezért tértem át Openbox-ra. Előtte megnéztem, hogy pl ki miket valósított meg Openbox, i3 alatt, és amik tetszettek, azokat egyenként a saját rendszeremen is megcsináltam. Volt amihez 2-3 perc alatt lehetett megoldást találni, és volt, amihez kellett fél óra is. A hosszabbak javarészt a notebook léte miatt voltal. Ilyen pl a fedél lecsukásakor zárolja a rendszert. Ezt teljes valójában meg sem találtam sehol az én felállásomhoz. De azt megtaláltam, hogy mi és hogyan vezérli a fedél lecsukásának eseményét. Az meg elég volt ahhoz, hogy módosítsam az én képemre.
[ Szerkesztve ]
-
Shyciii
veterán
Én Gnome-nak anno 2x adtam esélyt. Mind a kétszer gyorsan elbukott. Olyan érzésem volt, mintha olyan embereknek csinálnák, akik még életükben nem láttak számítógépet, tehát rettentően egyszerű, szájbarágós, átkonfigurálhatatlan. Ebből a szempontból a KDE jobb volt. Egészen addig, mig el nem kezdett foglalkoztatni a minimalista rendszerek, mert akkor igen gyorsan feltűnt, hogy azaz én világom. Gondolkoztam, hogy mielőtt UEFI átállás miatt komplett rendszer, sőt komplett SSD gyalulás volt a GPT miatt, hogy előtte felrakom az i3-at is, de ab abszolút minimalista tiling rendszerek már nem jönnek be nekem annyira. Egy egyszerű 15"-os notebookon nem tudnám az előnyüket kihasználni, nem sok minden fér el egy képernyőre. Viszont azért az ablakok gombbal való helyezgetése, nagyítása, kicsinyítése, szétosztása 2-vé megtetszett, úgyhogy azért azt megoldottam Openbox alatt.
Közben eszembejutott, hogy elfelejtettem, hogy az előző változatban a swappiness-re mennyit állítottam be, úgyhogy most kapott egy 30-as értéket. SSD + 4GB RAM memória + 2GB SWAP (ezt még sosem léptem túl), szerintem ezzel nem lövök bakot. Főleg úgy, hogy a legtöbb memóriát akkor foglalom, mikor egyszerre közel 60db gépre RDP-zek be a Remminával.[ Szerkesztve ]
-
Shyciii
veterán
Igen tudom a +memória lenne az igazi, de ebben az évben kivitelezhetetlen lesz (autó motorjának és váltójának felújítása (ez most volt), nyaralás, magánműtét, motoros vizsga, motor + cuccok megvétele). Szal most minden másra kell költenem, de nem a notebookra.
Azért egy átlag user mikor belép egy üres Openboxos felületre, valszeg programhibára fog gyanakodni, mert egy nagy szürkeséget lát. Egyedül jobb clickre jön elő egy menü, ami 90%-ban kamu dolgokat ad ki Onnantól kezdve vagy vadászik AUR-ból GUI-s programokat amikkel lehet ezt-azt állítani, vagy szépen kézzel szerkesztgetni az xml alapú fileokat. Ezutóbbit éri meg, mert az elején ahogy néztem 1-1 frontend-et csináltak pár funkcióhoz, de nem az igaziak. Érdemesebb megtanulni az xml fileok felépítését, meg egy kis python nyelvet. Amúgysem árt, mert ha követjük a minimalizmust, akkor a tálca ami mondjuk legyen polybar vagy akár tint2 ahhoz úgyis megint config fileokat kell szerkesztgetni, és megint csak xml vagy python, aztán jön a conky, dettó érteni kell a nyelvét, úgyhogy a GUI-s állítóknak ezen a szinten javarészt leáldozott.
Nagyon szeretem az Openbox-ot, de már egy jó ideje nincs fejlesztve, és félek, hogy ahogy halad előre a Linux, egyre kevésbé lesz kompatibilis vele, és a végén oda jutunk, hogy nem lesz már stabilan müködőképes. Pedig most zseniálisan stabil, egyszer sem fagy be, lassul be. KDE, Gnome, XFCE, Deepin mind-mind volt valami zűr (fagyás, nuku reakció) mikor anno probáltam. -
Shyciii
veterán
És a legnagyobb baj, hogy a fejlesztőjében nincs is hajlandóság, hogy komolyabban hozzányúljon, pedig sokan nyaggatják.
Amúgy nem tom hogy itt hányan használják a Remmina programot távasztalra, de most írtam a fejlesztőknek, hogy tegyenek bele egy új funkciót, mely azoknak lenne hasznos, akik újratelepítik a rendszert, vagy egyszerre kell több passwordöt változtatni, mert bár van ilyen funkció benne, de figyelmen kívűl hagyja azt, hogy valaki a szerverhez való user/password különböző, ha használ RD Gateway user/password-öt. Pl nálam is. Úgyhogy kézzel kellett egyenként változtatnom vagy 40db szervernél így. Rettentő korrektek. Még aznap visszaírták, hogy köszönik az ötletet, és már látható is, hogy az 1.4-es verzió roadmap-jében már szerepel is a kérésem.
-
Shyciii
veterán
Bizony a két színnél több nincs. Hálistennek én ezt preferálom, nincs szükségem nagyobb "csicsára". Viszont az már aggaszt, hogy a DPI állítását nem támogatja. FULL HD-s 15,6"-os notin ez még nem olyan nagy baj, de azért pl Chromiumnál szükség volt a megjelenített betük esetén a 120%-os beállításra, hogy kellemes legyen olvasni. Ezt is említették neki, de a DPI-t se óhajtja belerakni. Szal félek. hogy pár éven belül annyira elmaradott lesz az Openbox, hogy már a stabilitásából is veszni fog, és akkor kereshetek helyette mást. Márpedig ha jól tudom, hogy kifejezetten ilyan WM nemigen van. Mármint olyan, hogy a Tiling és a DE-k között helyezkedik el ilyen kellemesen, és stabilan működik.
-
eddie1978
aktív tag
Úgy tűnik, hogy marad. Minden működik amit eddig próbáltam. Appimage-ből tudom használni a Goldencheetah és a Hugin programot is. Ez nagyon tetszik. Gyorsabb sokkal a működésük is. A Goldencheetah 2-3 másodperc alatt indul és stabilan. Mindig betölti az edzés adatokat. Arch Xfce alatt sokkal lassabb volt és sokszor újra kellett indítanom, hogy betöltse rendesen amit kell. Hugin is gyors bár az alapból is gyorsult az utóbbi hónapokban.
Szerintem ez bárkinek ajánlható napi használatra. Nagyon egyszerű kezelni. Ami az őrületbe kergetett az Xfce alatt, hogy mindig átált a billentyűzetkiosztás ha ablakot váltottam. Ez itt most nincsen.
Amitől tartottam, hogy az Xfce mint lightweight de után a Gnome lassabb lesz. Nos nem. Pörög szépen. Simán van olyan gyors ha nem gyorsabb.Érezhetően gyorsabb össz globál mint a korábbi Arch telepítés.
Amint írtam a telepítés next next ok reboot és használható. Pár perc az egész. Számomra sokkal átláthatóbb mint a céges Win10.
Ami nem ok, lehet codec hiány, az a Google Photos és a Vimeo video lejátszás nem megy. Photosnál nem működik az MPV lejátszás, míg a Vimeo-nál igen.
Ellenben Youtube alacsonyabb CPU terheléssel megy mint az előző rendszeren a Chromium alatt. Itt sincs HW decoding Firefox alatt sem.
Viszont most vettem észre, lehet eddig is volt csak nem figyeltem, hogy cicereg a gép.Ami még jól működik és Xfce alatt nem volt jó az a kijelző fényerőszabályzás. Itt lemegy nullára a jelzőcsík de a fényerő minimumra állítódik. Xfce alatt a jelzőcsík nulla állapota lesötétítette a kijelzőt teljesen. Ezt úgy tudtam kikerülni, hogy teljes fényerőre fel, majd onnan csavartam le minimumra. Akkor jó volt.
Lehet, hogy amiket írtam, simán megoldhatóak de nincs kedvem/időm pöcsölni már. Eszköz a gép nekem már és nem cél, hogy piszkáljam.
Akku:
A lemerítés feltöltés ciklus már többször megvolt. Nem nagyon változott. Tegnap pont láttam ahogyan 34%-ról 6%-ra esik egy pillanat alatt. Ez van. (Kacérkodom egy Ipad Pro 11 256GB változattal a video/kép szerkesztés miatt. Elég meggyőző amit a neten mutatnak.) Bár a Shotcut sokat fejlődött tavasz óta, de fényévekre van a Youtube linken lévő videótól. Akkor még egy sima crossfade is megakasztotta a szerkesztőben visszajátszva az anyagot. Most ez folyamatos. Stabilabb is lett. Alakul.
[ Szerkesztve ]
-
vinibali
őstag
gyakorlatilag a desktop initrd és vmlinuz fájlokat hívom meg tök normál syslinux-os parancssorral. szerintem betölti a "NAS"-ról a memóriába ezeket az image-eket és onnan kellene simán futnia.
BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/
-
Frawly
veterán
Ezt még nem volt időm tesztelni, mármint a blokkméret alapján történő alignálást, de már előre rájöttem, hogy hülyeség lesz.
Tegyük fel, hogy nincsenek blokkméret alapján alignálva a partíciók. Ez csak a partíciók első és utolsó blokkját befolyásolja lényegében. Ez pedig kevés ahhoz, hogy sebességbeli hátrányt vagy élettartamnövekedést hozzon.
Nem véletlen, hogy csak ilyen ködös német fórumok írnak erről a blokkméret mentén alignálásról, és ehelyett midenki a sztenderd 1 megás partícióeltolást használja, amit a particionálóprogik és telepítők alapból alkalmaznak.
Persze ki fogom próbálni, mert nem kerül semmibe, de már előre látom, hogy nincs értelme, nem javít majd semmin. Nem is egy nagy áldozat, csak felesleges.
-
Frawly
veterán
Ezt egy kicsit bővebben kifejtem, mert nem érthető.
Tehát az SSD-ket ún. lapméret alapján szokták alignálni. Az SSD-n a NAND cellák NAND lapokba vannak rendeződve. De egy darab cellát nem lehet írni/olvasni (az SSD vezérlője nem képes rá), hanem csak egy egész NAND lapot (akkor is, ha csak 1 cellát érint majd a módosítás, olvasás). Ez a lapméret jellemzően 4KB volt a régi SLC-MLC-s SSD-ket, egy ideig még a TLC-seken is, de a modern 3D NAND-on már általában 16 KB vagy még több.
Emiatt a legtöbb particionálóprogi 1024K eltolással particionál, mert az maradék nélkül osztható 4K-s, 8K-s, 16K-s, 32K-s, ..., 512K-s, 1024K-s lapmérettel is, megfelelve a jövőbeni SSD-k igényének is.
Na most itt ebben a topikban valaki német fórumok javaslata alapján felvetette, hogy egy még nagyobb egység, a blokkméret alapján kéne alingálni. Ugyanis a NAND lapok egy még nagyobb egységbe, ún. blokkban is kezelhetők, ennek törléskor, trimeléskor van előnye. A blokkméret általában elég nagy, ilyen több MB-os, SSD-nként eltérő, modern 3D NAND-okon magasabb, mint korábbi 2D-seken, ilyen 6-30 MB nagyjából. Tehát egy blokkban ~1000-es nagyságrendű lap van.
De itt jön a logikai bukfenc. A fájlrendszerek által kezelt logikai szektorok 0,5-4K-sak jellemzően, ez meg is felel, maradék nélkül osztható a 4-16K-s lapmérettel, és az 1024K alignálással, mert így a lemezműveletek nem lógnak át laphatárokon. De tegyük fel, hogy nem blokkméret alapján vannak alignálva a partíciók. Ekkor a partíciók első és utolsó pár szoktora, fizikai lapja átlóghat blokkhatárokon, de ez csak ezt a pár szektort, lapot érinti. De a közöttük lévő szektorokat nem, mert azoknak a lapmérete/szektormérete maradék nélkül osztható a blokkmérettel, így nem lesz olyan köztes lap/szektor, ami blokkhatárokon nyúlna át.
Vegyük például az én átlagos felhasználásomat. Egy régi 3D TLC-s SSD-m van, 16 KB-os lapmérettel, 24 MB-os blokkmérettel (1 blokkban 1536 NAND lap van), és 4KB clusterméretes ext4 partíciókat használok rajta, 512 bájtos logikai szektormérettel. A partíciók 1024K-n vannak alignálva. Ez azt jelenti, hogy a partícióim első 23 megabájtja (1472 lapja vagy 5888 logikai klusztere vagy 47104 logikai szektora) átlóg blokkhatárokon. Az ezek után lévő többi szektor, lap nem lóghat át blokkhatáron, ami a tárterület 99,99%-át jelenti.
A gyakorlatban tehát ezzel annyit bukok, hogy ezeknek a szektoroknak a törlése lassabb egy nagyon minimálisan, talán már ez sem mérhető. De mi annak az esélye, hogy pont az ezekre eső blokkot érinti a törlés? Nagyon minimális. Szóval a gyakorlatban nincs semmi értelme blokkméret alapján alignálni, felesleges önszopatás. Nem nagy áldozat, mert maximum 23 MB veszteséggel járna az első partíció előtt a kihasználatlan terület, de nekem pl. nem tetszene, hogy emiatt nem feltétlenül lennének egész GB-tal osztható partícióméreteim. Ez utóbbi akkor jön jól, ha szétcsesződne a partíciós tábla (bár GPT-n ilyenkor van belőle több másolat), könnyű rekonstruálni a partíciós táblát.
Persze továbbra sem lehetetlen, mert csinálhatnám úgy, hogy partícióméretek ne csak 1 GB-tal, hanem 24 GB-tal legyenek oszthatóak (pl. az első partíció 48 gigás, a második 240, a harmadik 480, stb.), de ez felesleges matek, meg helypocsékolás az első partíció előtt. Ez ilyen tipikus német precízkedés, hogy 0,00000001% előnyért szopjuk, hogy elméletileg is maximálizáljuk a lehetőségeket. Nehogy egy krumlihéjnyi valami is pocséka menjen.
Arról nem is szólva, hogy az adott SSD blokkmérete elég nehezen deríthető ki adott esetben. Az SSD gyártók fel sem tüntetik, hanem be kell azonosítani a NAND típusát (ha ezt sem találni meg online, akkor szét kell szedni az SSD-t, vagy leszedni róla az M.2 matricát, ami azonnali garivesztés, és megnézni milyen NAND van rajta), majd a NAND gyártójának valami részletes technikai spec sheetjéből nyomozható ki. Tényleg nem éri meg vele szívni.
[ Szerkesztve ]
-
félisten
-
őstag
Igen, sajnos a radeon 6670-el nem fér össze valamiért az arch konzol, google kidobott pár arch-os találatot erre de megoldás nincs Sajnos a mikrokód betöltése sem szünteti meg a hibát, néhány alkalommal fekete ahogy kell a konzol, de kikapcs és másnapi bekapcs után szürke konzollal indít megint. Különösen telepítéskor kellemetlen, nem jó a szemnek Feltelepített rendszeren nem annyira zavaró már. Ez a hiba azthiszem a display managerre is hat, ha feltelepítek valamilyet, sddm-et próbáltam régebben, mert kde hez ezt ajánlják, akkor elég sűrűn elhasalt a DM, le kellett szedjem mert nem tudtam vele bejelentkezni, el sem indult vagy összeomlott. De ugyanaz a DM kubuntunál rendesen működik ezen a vason....
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
őstag
Talán chromium-dev csomaggal megoldódna a videó és egyéb gyorsítás, viszont ott meg nem működik a google fiókkal szinkronizálás, de ez legyen a legkisebb gond.
Csak kellene csinálni egy bináris csomagot valakinek rendszeresen, kellene egy build szerver amin automatikusan fordulnak a chromium-dev csomagok arch-ra.-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
őstag
Igazából a kíváncsiság vezérelt hogyha felrakom az ubuntu alá forgatott chromium-dev verziót akkor működni fog e a hardveres videó gyorsítás, mert kubuntun a chromium-dev -el simán megy, és ahogy sejtettem arch-on is simán megy a videógyorsítás chromium-dev verzióval. Nomeg az ubuntus chromium-dev felrakásával fordítási időt is akartam spórolni, mert van ugyan az aur-ban chromium-dev de csak forrásból lehet feltenni, chromium fordításra meg horror időket írnak a neten ilyen alap procikkal ami egy átlagembernek van.
Egyébként meg az X4 860K, de gondolom a legtöbb mai alap proci is csak kihajtja rendesen vga nélkül is az 1080P-t, a 860K kihajtja, szóval nekem felesleges lett volna dev-chromium felrakásával bíbelődnöm de hajtott a kíváncsiság. A linuxos firefoxban sincs hw videó gyorsítás, elvileg mostanában rakják majd bele. Ha neked is elmegy az 1080p youtube cpu-ból akkor felesleges dev chromiummal bíbelődnöd szerintem. De ha kíváncsi vagy hogy nálad is működik e a hw videó gyorsítás akkor hajrá!Arch-on ezzel a patchelt aur-os chromium-vaapi-bin -el van a gond, hogy a patchet nem megfelelően alkalmazzák nem aktualizálják az aktuális mesa-nak megfelelően, és az arch fórum topikban amit linkeltem ezt szóvá is tették. Az kellene itt is mint ubuntun, kellene egy build szerver amin mindig lefordulnak a legújabb chromium-dev buildek, ezt az arch közösség szerintem meg tudná finanszírozni.
[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
A kalandok folytatódnak. Most frissült a SwayWM, ugyanaz a verzió (1.2), de újabb build (-2 helyett már -3). Erre most már el sem indul a chromium bináris, azt mondja terminálban:
[863:863:0930/042000.321493:FATAL:memory_linux.cc(42)] Out of memory.
Trace/breakpoint trap (core dumped)Természetesen van elég memória, 14,5 GB szabad a 16 gigából, egy keveset eszik az IGP, meg 600 megát az egész Linux, kernel, systemd, SwayWM, Firefox több füllel. Szerintem még az IGP 1 gigás memóriájából is szabad vagy 900 mega.
Szerk.: az Arch bugtrackere is hozza már, más is jelentette 23 órája. Állítólag a Mesa 19.2 okozza, ahogy már sejtettem, de szerintem nem csak az, mert azzal nekem legalább elindult, ha tearingelt is. A Sway frissítése tett be neki végleg.
[ Szerkesztve ]
-
őstag
Néztem htop-al a különbséget, firefoxnál ahol nincs hw videó gyorsítás 40-50% között terhelődtek a processzor magok youtube 1080P 60FPS videó lejátszásakor, chromium-dev -nél ugyanez a videó 15% prociterheléssel ment. Nálam fenn van mind firefoxban mind chromiumban a h264ify plugin, ez kényszeríti a youtubeot hogy h264-ben renderelje a videókat vp9 helyett. A vga-m csak h264 dekódolást támogat, de szoftveres dekódolásnál is jól jön a h264 ify, mert a legtöbb procinak jobban fekszik a h264 mint a vp9. Szerintem te is rakd fel a h264ify-t ha még nincs fenn.
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
_NCT
őstag
Köszi szépen a választ! Tegnap felcsesztem magam és váltottam Manjaro-ra, mert szeretnék Arch vonalon maradni, de annyira nem fontos, hogy mindig megkapjam a legújabb frissítéseket. A stabilitás fontosabb, kernelből is lts kell vmware miatt. Mondjuk az az én balf@szságom hogy nem vollt beütemezve backup legalább a root-ról.
[ Szerkesztve ]
-
wwenigma
Jómunkásember
Amikor a file-okat bemozgatom utana jonnek az egyéb hibák pl. :
rs.c:2739:6: error: implicit declaration of function ‘rate_control_send_low’; did you mean ‘rate_control_set_rates’? [-Werror=implicit-function-declaration]
Steam: http://bit.ly/1rRuf8p , Origin: wwenigma -- | -- Jiayu F1 / G3C / OT995 cuccok: http://bit.ly/1w44CI2 -- | -- ZTE V5 Red Bull -> http://bit.ly/1mgtfrd -- | -- Xiaomi RN3SE -> http://bit.ly/2r8DlV7 -- | -- Live Stream: twitch.tv/wwenigma
-
wwenigma
Jómunkásember
Ujraraktam, sajnos nincs változás. Azért szeretném felrakni mert alapból nem látja és nem tudom előcsalogatni , egy 9260NGW kártya egy PCIe átalakitoban, elméletileg ehhez nem kell CNVi még. A BT része mukodik, az USB-n csatlakozik.
Steam: http://bit.ly/1rRuf8p , Origin: wwenigma -- | -- Jiayu F1 / G3C / OT995 cuccok: http://bit.ly/1w44CI2 -- | -- ZTE V5 Red Bull -> http://bit.ly/1mgtfrd -- | -- Xiaomi RN3SE -> http://bit.ly/2r8DlV7 -- | -- Live Stream: twitch.tv/wwenigma
-
vargalex
félisten
Jó lett volna, ha frissíted a repo-t a
pacman -S
előtt. Így nyilván nálad még a cache-elt verziót jelentette. A linkelt hírben egyébként metapackage-t írnak, nem package-t és ez az infó jött RSS feed-ből is.
Ahogy a hír is mondja, eddg a base egy group volt, most viszont metapackage lett.Alex
-
F34R
nagyúr
van ha aktiv az xsel, vagy xclip.. egyebkent meg nincs.. [link] meg ugyszint akkor tudod hasznalni ha a terminal emulatorban van clipboard tamogatas. egybkent guirol terminalba siman ment eddig is, vica versa voltak gondok. A gvim meg egy gui-s frontend extrakkal. Nem is kerdes, hogy ezert mukodnek benne az altalad emlitett dolgok. Nalam ez valtozo mi van fent, legendas Distro hopper vagyok.
[ Szerkesztve ]
-
vargalex
félisten
Engem soha nem zavart a clipboard támogatás hiánya. Kijelölök egy szöveget és középső gombbal (vagy touchpad esetén a 2 gomb egyidejű nyomásával) beillesztem. Nem akarom én nézegetni a vágólapot, nem kell többszörös tartalom, stb.. Mindig az utoljára kijelöltet akarom beilleszteni és ez megy oda-vissza a sima alap vim-el is.
Alex
-
vargalex
félisten
Ugyan nem írta a kolléga, hogy milyen CPU-ról van szó, de nyilván 1 mag futott 100%-on, kérdés az milyen sebességre képes.
Mégpedig valószínűleg pont azért, mert SSD-ről meglehetősen gyorsan lehet olvasni, így valóban az ntfs-3g terhelte. Persze az elért olvasási sebessegről sem tudunk semmit...Alex
-
-
vargalex
félisten
Az emlékezetemben nekem már úgy élt, hogy az AMD procikhoz külön csomag van. Most jutott eszembe ez a hozzászólásod, így megnéztem gyorsan a microcode wiki history-t. Jól emlékeztem, az a jó pár hónapja egészen pontosan 2018 augusztus 26-án volt.
Nyilván azóta ránéztem már az oldalra, ezért emlékeztem...Alex
-
Shyciii
veterán
Az a baj, hogy nekem notebookom van, így nem tudok belerakni még egy SSD-t, mert nincsen hely. Saját SSD-mről másolva 200GB-nyi egy fileos adatot ugyanarra az SSD-re nekem is megeszi a procit, illetőleg a proci terhelés a conky szerint 35% körül van, de az egérkurzoron látni, hogy baromira belassult a rendszer. Ez viszont a SATA csatoló egyértelmű hibája, mert ebből a szempontból nemigen van előrelépés a PATA-hoz képest. USB-s külső SSD van, de ugye ott is az USB korlátozza le.
-
Shyciii
veterán
Én újra kipróbáltam a saját ssd-mről ssdm-re másolni egy 14GB-os filet, de ugyanaz. Conky és htop is átlag 27%-os cpu terhelést mutat minden magra, de közben az egérkurzort mozgatva rettentően akadozik. Viszont így elgondolva ezt 2-3 hónapja biztos nem csinálta, mert kb akkor szerveztem át a winyót, és helyezgettem ide-oda cuccokat, és közben tudtam dolgozni, szal itt valamelyik frissítés után lett nekem ilyen. Mindegy, ritkán van ilyen
-
Shyciii
veterán
Double Commander-t használok
Kipróbáltam neked terminal alóló, és ugyanaz a jelenség. Viszont itt szembetűnőbb volt még egy dolog. Semmi gond nem volt egészen addig, míg az SSD cache-e be nem telt. Ahogy betelt, onnantól kezdve akadozik a kurzor, miközben a proci most 22% átlagt mutatott. És így viszont már nagyon ismerős jelenség. Semmi bug nincsen, hanem az SSD a "szar".
Ugyanis van egy másik tapasztalatom kb 2 évvel ezelőttről. Vannak olyan szervereink, amik RAID1-es köteget használnak Samsung 850Pro SSD-vel. No ott láttam ezt a jelenségget először. Nagy file másolásakor amíg a cache nem telik gyors, és utána drasztikusan leesik a teljesítmény, de olyan szintre, hogy ha valaki távasztalozott arra a szerverre, akkor ki is esett onnan. Amióta már a az SSD-s szerverekben Intel S35 és S46-al kezdődő típusokat használunk, azóta semmi ilyen gond nincsen. Egyszerűen vannak SSD-k, amik szarok olyan nagy file-ok írásában, amik nagyobbak, mint a cache-e. -
Shyciii
veterán
Nah nekem Kingston A400-as van Mondjuk anno azért vettem, mert olcsó volt. Már nem is emlékszem, hogy hány éves.
Sok általános weboldalon én is mindig azt olvastam, hogy a Samsung 840 Pro és 850 Pro jó SSD, de sajnos amit mondtam, azt megerősítette a Rackforest, és a Doclernet is. Ha nem ismered őket, akkor mindketten hostingot végeznek, és hát mi is ezt tapasztaltuk. Otthoni használatra biztos jók ezek a Samsungok, de nagyobb másolás esetén bukováriak. És akkor még ott a trimmelési gondjuk. Mondjuk erről csak akkor olvastam, mikor elkedzem linuxozni. Viszont most olvasom vargalextől, hogy a 850 Pro is érintett ebben. Hihetetlen, hogy ezt képtelenek megoldani.
Amúgy én egy ideje szemezgetek a WD Black SN750-es SSD-vel. Persze M.2-essel. Mondjuk még nem néztem meg, hogy a notebookomba betehető-e, befér-e. -
ubyegon2
nagyúr
Nem az online TRIM érintett ebben a dologban? (a 800-as sorozat amúgy más rég kikerült a blacklist-ból) Erre a gyűlölt systemd egyébként rég nyújt megoldást, de azelőtt is lehetett ütemezett TRIM-et használni. Sok disztró főleg Arch alapúak még default discard parancsot alkalmaznak FSTAB-ban, nekik érdemes odafigyelni, aki meg pure Archot használ, csak tudja, mit hogyan kell alkalmazni.
Egyszóval az nyilvánvaló még mindig szerintetek is, hogy a Samsung 800-as sorozatnak semmi gondja nincs a TRIM-mel, kivéve 2 tipust, aminek az online TRIM ATA parancs(discard) okoz gondot?
Ez így korrekt? Vagy megint nem jól értelmezek valamit?
[ Szerkesztve ]
-
Laszlo733
aktív tag
Telepítettem az autoconf -ot, de utána így is hibára fut a yay -S gksu
Hunk #20 succeeded at 2876 (offset 5 lines).
Hunk #21 succeeded at 2888 (offset 5 lines).
patching file Makefile.am
patching file libgksu/Makefile.am
Hunk #1 succeeded at 27 with fuzz 2.
patching file libgksuui/Makefile.am
Hunk #1 succeeded at 10 with fuzz 2 (offset 1 line).
patching file libgksu/Makefile.am
Can't exec "aclocal": Nincs ilyen fájl vagy könyvtár at /usr/share/autoconf/Autom4te/Fil
eUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
==> HIBA: Hiba történt a prepare()-ben.
Megszakítás...
Error making: libgksu
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen