Koszonom a segitseget.

Felment minden. Mate lett telepitve. Eddig szep es gyors, de 2 dologgal kapcsolatban van kerdesem.

Az elso, h Ubuntu Maten megszoktam, h a panelen a kis cpu freq applet mutatja nekem az aktualis sebbeseget, de most csak a minimumot mutatja (400Mhz). Valamit fel kellene meg rakni, h "tudja olvasni" ?

A masik, pedig, h az aksi ikon melle ki lehet varazsolni a %-os kijelzest. Ugyszint ubuntu Mate-n szoktam meg, de itt nem lelem.

Ezeket passzolom, már sok éve nem volt fent nálam MATE. Itt korábban is csak azért írtam azt példának, mert a kolléga is azt akart magának telepíteni.

Próbálj jobb klikkel hatni rá. Igazából ezt Live Mint MATE alatt kéne megnézni, hogy mivel lehet állítani, gyanítom, hogy semmi nem kell hozzá feltenni, de a neten nem sok értelmeset írnak róla.

Korábbi kimenetet minek betenni? Archon nem érdekes, amit az inxi Minten írogatott.

Mivel kérdezted a wifi típusát és a Mint alatt készült kimenet is ugyanazt a típust mutatja, mint bármely OS alatt, de lehet, hogy azt mondod, hogy Arch alatt még ezt is másképp csinálja!

Még egy darabig nem lesz lelkierőm ennyit olvasgatni/gépelgetni a tiszta telepítéshez, viszont kábelt bedugva és wifit hardveresen lekapcsolva újratelepítettem az ArchmD-t és most már futnak a scriptek is. Ha minden fenn van, majd csak megoldódik a wifi kérdése is.

Azért csinálom ezt, mert ahhoz ez a féltiszta telepítés elég, hogy lássam, milyen a futása az old laptopon, mert ha nem jobb, mint a most futó legjobb XFCE Chrome-mal, akkor nem szenvednék fél napot, ha jobb, akkor egyszer már érdemes lesz nekiállni/ülni.

Addig is köszi a helpet, mostmár tuti, hogy fogok még jönni! Így jártatok!

Kirakja az ember es megy, de itt nem akar. Neten en sem talalok semmit ezekről...

Conky lesz ebből sztem

A mate csomagcsoport mellé a mate-extra csomagcsoport összes tagját is feltetted, ahogy a kollégának írtam? Mert a mate-extra csoportban benne van a mate-applets csomag, amiben benne van a mate-cpufreq-applet és a mate-cpufreq-selector. Sőt, utóbbi csomagban még a battstat-applet is benne van, ami a másik gondod is megoldja elvileg.

Ez ilyen türelemjáték, hogy mit kell feltenni. Pont azért nem először írom azt, hogy aki Minthez szokott, amibe minden bele van készítve alapból, annak az Arch egy kicsit meredek lesz elsőre. Nem kell azonnal kétségbe esni, ha ment Mint alatt, itt is menni fog, csak nem szabad feladni.

[ Szerkesztve ]

Nofene. A github-on levo mate csomagot raktam fel. Ezt az extrat, h tudom felrakni ?

sudo pacman -S mate-extra

Kár volt git-ezni, Archnál is alapszabály, hogy lehetőleg a tárolót használjuk. Főleg, hogy a csomagok is elég frissek benne, ez nem Debian, hogy az ezer éves csomagok helyett muszáj külsős csomagot feltenni, meg Gitből fordítgatani.

Kovettem a videot Linux Mind-on. Elso telepites, orultem, hogy sikerult

-------

Felraktam az extra csaomagot, de semmi valtozas.

[ Szerkesztve ]

100-display-manager-and-desktop-v1.sh

idézet a srciptből
sudo pacman -Syyu
sudo pacman -S lightdm lightdm-gtk-greeter lightdm-gtk-greeter-settings --noconfirm --needed
sudo pacman -S mate mate-extra --noconfirm --needed
sudo systemctl enable lightdm.service -f
sudo systemctl set-default graphical.target

Ha ezt felraktad, akkor fenn van nálad is a mate-extra.

Keress rá a csomagkezelőben, ott kell lennie.

Felraktam az extra csaomagot, de semmi valtozas.

Ettől még a panel-appletet hozzá kéne adni a panelhez.

Frawly

A kolléga arra gondolt, amit a core telepítés után használni kell: https://github.com/ArchMergeLinux/amd-mate, itt vannak a scriptek. Amúgy ugyanaz a verzió, mint az Archos linkeltben.

[ Szerkesztve ]

ez nem Debian, hogy az ezer éves csomagok helyett muszáj külsős csomagot feltenni,

Ennek azért fuss majd neki még egyszer szerintem, mert így elég nagy baromság!
(a mate-extra itt community repoban van, ennyit súgok)

Amúgy nálam működik az újabb telepítés, a wifi is. Kicsit majd belakom és tesztelem, hogy jobb-e valamiben, mint a Mint XFCE.

Más:
Szerkesztenem kellett a GRUB-ot, de nem engedi az update-grub-ot, hogyan lehet GRUB-ot frissíteni?
A processor.nocst opciót alapvető beraknom.

[ Szerkesztve ]

grub-mkconfig -o /boot/grub/grub.cfg - GRUB

azzal mi a baj hogy community-ben van? nem tudok szamokat de szerintem igy nez ki core < extra < comm.
de amugy mar pl firefox nyelvi csomag is comm.-ben van.

Official repositories

[ Szerkesztve ]

Vigyázat, csalok!

A panelhez hozza tudom adni, de csak 400Mhz-en csucsul.
Csomagkezeloben az xfce-cpu-freq aplet az ott van, de mate-cpu-freq-t nem latom.

Nem kell nekifutni, most kipróbáltam a saját rendszeremen, a sudo pacman -S mate-extra működik, húzná a mate-t is vele. A lényeg, hogy nem az AUR-ban van, amihez yaourt kell. Nem kell gitezni, fel kel tenni. Ahogy írtad, az általa feltett script is felteszi, akkor meg csak hozzá kell adni az appleteket a panelhoz.

Az Arch Mate, Arch Xfce sanszosabb gyorsabb, fürgébb lesz, mint a Mint Xfce. Archon update-grub helyett grub-mkconfig -o /boot/grub/grub.cfg futtatása van.

A /usr/lib/mate-applets/mate-cpufreq-applet indításával próbálkozz, de csak simán is el kéne indulnia mate-cpufreq-applet indításával (nem mate-cpu-freq a neve, ahogy írtad).

Egyébként kezdem úgy látni, hogy nem jó ötlet ez az ilyen-olyan scriptek mentén telepítés, itt szívtok vele párhuzamosan.

[ Szerkesztve ]

Elindulni elindul, csak nem mutat mast a 400Mhz en kivul. Ha atalitom %-ra, akkor meg 11%-on tanyazik. Olyan mintha nem akarna/tudna olvasni, h mennyi az annyi.
Conky viszont megy es mutatja rendesen, de annal meg a problema, h ha el van idnitva akkor a brisk menu nem jon elo.

Köszi a grub-os parancsot. sikerült is, reboot megvolt

azzal mi a baj hogy community-ben van?

Semmi baj nincs ezzel, csak Frawly kolléga Debianos példájára írtam, hogy ott külsős csomagokkal kell operálni. Hát itt is, már ha community. Nekem amúgy tényleg mindegy, csak ez a trendy derégiekadebiancsomagok néha már fák. Ott is vannak friss csomagok akár az experimental repoban, de a stable-ban régiek, nem rolling disztró, ezt mindenki tudja.

Érdekes, hogy elég sokat olvastam eddig a wikijét az Archnak, lehet, hogy most is kéne néha. Erre az update-grub parancsra nagyon ráállt a kezem.

(#5013) Frawly

Félreértettél, lást itt fenn.

Egyébként kezdem úgy látni, hogy nem jó ötlet ez az ilyen-olyan scriptek mentén telepítés, itt szívtok vele párhuzamosan.

Én csak annyit szívok, mint más Arch alapúval tenném. :-) Viszont fél nappal hamarabb telepítettem.

(#5015) berojocy Lehet, hogy nincs sok köze hozzá, de én mindig csinálok egy sudo sensors-detect futtatást terminalból.

[ Szerkesztve ]

A community nem külsős, hanem hivatalos Arch tároló.

A Debian-nál az experimental itt a testing repoknak felel meg, a communityben rendes stabil csomagok vannak.

De ezt a kört már kétszer is lefutottuk itt a PH-n. Valamiért nálad nem nagyon akar felülíródni ez a fals információ.

Wikiben sok minden le van írva, a grub-al kapcsolatos parancsok is. Nem itt kell összegyűjteni az alapvető információkat ha valaki Arch-ot szeretne használni - szerintem.

[ Szerkesztve ]

You may corrupt the souls of men, but I am steel. I am doom.

Nem jo. Atnyalaztam az Arch Wiki-t, es annyit talaltam, h terminalba ezzel a parancsal lehet "nezni". Ilyen fel megoldas...
watch grep \"cpu MHz\" /proc/cpuinfo

Nem nekem irtad, de a Mate telepiteshez hozza szolnek. Ma a delelottom rament, h bedurrantsam a wifi-t a laptopon. Elso dolgom az volt, h a wiki-t neztem es probaltam lepesrol lepesre. utana google, majd videok youtubon. Ezek utan irtam ide. A vege az lett, h sikerult, es mukodik. Ennyivel is okosabb lettem. Szerintem az mindegy, h hogyan es honnan van segitseg, a lenyeg, h tanul az ember. Az tiszta sor, h nem egy plug&play rendszer, de pont emiatt kell segiteni az ujoncnak.

De ha mar segitsegrol is irtal, akkor kerlek, ha van valmi otleted a fentebb irt problemamra, akkor megkoszonnem.

Ebben a Mate-es cpu appletben állítani is lehet a cpu governor-t?

You may corrupt the souls of men, but I am steel. I am doom.

Power save meg performance van.
Performance fel küldi maxra, es 3600MHz en tartja folyamatosan.
Az elsőnél vissont skalazodik úgy ahogy kell, de nem mutatja.
Ubuntu Maten működött rendben, vissont itt csak 400 Mhz ir, mikozben "ugralnia" kéne.
Conkyban és a fentebb írt paranccsal tudom nézni, de ezek nem a legjobb megoldások.

Igazából Archon ez a core, extra, community elnevezések csak csomagellenőrzés komolyságára utalnak. A core a legszigorúbb, ott tesztelik legszigorúbban a csomagokat, csomag maintainerként oda a legnehezebb bekerülni, ott várják el a legnagyobb megbízhatóságot. Ettől függetlenül a community sem instabil, a core-ba csak néhány csomag van, ami az alaprendszer telepítéséhez kell, más nem is fog belekerülni, pl. a mate, mivel nem szükséges az alaptelepítéshez. Sokszor ugyanazok a maintainerek készítik a core és community csomagokat is, ha megnézed, így valójában minőségi szintkülönbség nincs közöttük. Ez csak alapfilozófia, hogy a core csomagok fontosabbak, még nagyobb figyelmet kapnak.

Igazából ezzel az egésszel nem kell foglalkozni, vannak a hivatalos tárolók, onnan a pacman-nal telepítesz, és van a nem hivatalos AUR, ahonnan AUR-os progival, tipikusan yaourt, de fel lehet tenni mást is. Ennyit kell észben tartani.

Archon is van stating, meg testing, ezekkel sem volt még negatív tapasztalatom, pedig a kerneleket innen szoktam szedni. Ezek a Debian testing, unstable-nek felelnek meg, de a gyakorlatban stabilabbak ezek. Archon nem nagyon fogsz találkozni beboruló, instabil, bugos csomaggal, még staging/testing tárolóban sem. Ha néha van is bug, az nem attól van, hogy a csomagkészítő hányja el a dolgokat, hanem a fejlesztő a git/dev ágba belefejleszt valamit friss feature-t, amit nem tesztel eléggé, és amíg nincs hibajavító kiadás, addig becsúszhat bug (ez is rettenet ritka, mint a fehérholló, stable tárolókban pedig elő sem fordul). Erről nem az Arch tehet, az Arch maintainer csak azt tudja csomagolni, amit az adott progihoz az eredeti fejlesztő fejleszt, azt nem látja előre, hogy a fejlesztő hagyott-e benne bugot (bár nyilván teszteli a gépén, meg testingben, meg stagingben mielőtt a stable tárolóba kerül, de az egész folyamat sokkal gyorsabb, mint a Debian/Ubuntu-vonal esetében). Az Arch alapfilozófiája, hogy vanilla csomagokkal dolgozik, nem nagyon módosítanak semmit a forráskódon, ahogy Debian/Ubuntu-vonalon (és ez jó, mert nem hekkelnek bele disztróspecifikus dolgokat, ami az életet bonyolítja). Az Arch csomagkarbantartói is épp úgy gitből húzzák az új verziókat, és az AUR-ban lévő pkgbuild scripthez hasonlóval forgatják le meg készítik a csomagokat. Igazából az egész folyamat teljesen megbízható, egy nagyon kipróbált rendszert járattak be a csomagkészítők. A gyakorlatban azt tapasztalatom, hogy az adott csomaghoz tartozó pkgbuild scriptet annyira tökélyre csiszolják, hogy ha leszeded, és kézzel újrafordítod (az a gitből a legújabb verziót fogja lehúzni), akkor az is normálisan fog működni, csak a verziószámot nem szabad elfelejteni átírni rajta, meg ha vannak verziófüggőségei más csomagoknál, akkor azoknál a verziószámot feltüntetni.

Igazából az Arch csak annak nem való, aki nagyon kezdő/türelmetlen, vagy a gépén valami olyan speciális zárt drivert (hulladék hardverhez) vagy zárt progit kell használnia, ami régi csomagverziókra korlátozzák be, és emiatt nem frissíthet, utóbbi emberkéknek találták ki a Debiant meg a CentOS-t. Ilyen zárt hulladékokat egyébként is kerülni kell, ha egy mód van rá. Nem csak az Arch miatt, más korszerű disztróknál is ugyanez áll fenn.

Ezért fontos a nyílt forráskód. Stallman, Torvalds meg a többiek nem azért találták ki ezt az egész GNU, free, opensource, GPL mantrát, mert ingyenélő hippik, akik be vannak szívva, meg mindent ingyen akarnak, humanitárius adakozóként azt akarják, hogy falu végén, fejkendős Mari néni unokájának is legyen ingyért valami a celeronjára, ha nem telik neki Windowsra meg MS Office-ra, hanem azért, mert észrevették, hogy jogi korlátok meg a zárt forráskód visszafogják az informatikai fejlődést, amit nem tartanak megengedhetőnek, mert utána csak a függőségi, terjeszthetőségi, karbantartási szívás van azokkal, kerülgetni kell másnak a szarjait, korlátozásait és nem tudnak az érdemi fejlesztésekre koncentrálni. Igazából a saját munkájukat könnyítik meg ezzel az alapfilozófiával, meg lehetővé teszik vele, hogy más is könnyen beszálljon a fejlesztésbe. Sőt, olyan nagy cégek mint a Samsung, Microsoft, Intel, IBM, Google sem azért fizetnek kernelfejlesztőket, meg pénzelik az egész kernelt, Linuxot, mert jótékonykodni akarnak PR-ból az adójuk 1%-ával, hanem tudják, hogy nekik is jól jön, ha kiadnak egy új technikai megoldást, hardvert, platformot, akkor mindjárt lesz rá támogatott OS, szoftver, lesz egy nyílt megoldás, amihez könnyen hozzá lehet nyúlni mindenféle megkötés nélkül. Így ha pl. a Fujitsunál holnap összedobnak valami új szuperszámítógépet, új speciális kínai processzormagokkal, akkor nem kell pl. a Microsofthoz elmenniük könyörögni, hogy lécci-lécci, támogassátok már a mi non-x86 ócskavasunkat is, adjatok ki rá valamit, ha más nem alfa állapotban, itt a sarokban porosodik, összedobtunk egy kis gépecskét, 300 ezer procimag, 25 PFLOPS összteljesítmény, 240 TB RAM, lécci-lécci, hadd wordözzünk rajta mink egy jóízűt, vaskos pénzeket tejelnénk érte. Ha egyáltalán a kérésük nem süket fülekre talál, akkor is évek lennének, mire a MS elő tudna állni valami használhatóval, addigra meg már az egész projekt aktualitását vesztené. Így meg csak ráheggesztik, hozzáfejlesztik az épp aktuális Linux kernelt, és azonnal beröffen a masina, lehet tesztelni, optimalizálni, kísérletezni vele. De elég volt megnézni, mikor törtek fel ezek a mobilos ARM-es olcsó eszközök, okosteló, táblagép, a Google egyből kapott az alkalmon, nem kellett a 0-ról OS-t kitalálni hozzá, hanem azonnal nyúltak is a Linux kernelért, kihasználva annak a rugalmasságát, portolhatóságát, jogi korlátozásmentes voltát, és az Androidot így akkora sikerre vitték, amit más azóta sem tudott megismételni, magyarán bőven visszajött nekik az a pénz, amit anno a kernel támogatásába öltek.

Vagy egy másik példa, a mostani Spectre/Meltdown-sebezhetőség. Január elején publikálták, Linuxra már az első napokban megjelentek az első működő Meltdown patchek. A MS-nál először gond volt a patchekkel, aztán nekifutottak újra, aztán azzal is a gond volt, mert az Intel elcseszte a mikrokódot azokhoz a procikhoz is, amikhez egyáltalán adott ki. Aztán megint vissza lett vonva a Windows javítás, és azóta is várnak az Intelre, hogy mikor jön ki végre a javított mikrokód, amivel újra működhet és terjeszthető lesz a javítás. Erőforrásuk sincs rá, bevonni sem tudnak senkit a zárt forráskód miatt Közben meg a sötétebb oldalon teljesen más volt a hozzáállás. Nem vártak az Intelre, míg összeszedi magát, hanem lefejlesztettek saját, szoftveres megoldásokat, amihez nem kell a procira új mikrokód, a Meltdown elleni PTI már a kernelfejlesztők tarsolyában volt, de a Google is elég gyorsan előállt a retpoline technikával, meg pár hétre rá elkészült az user pointer sanitization. Így igaz, hogy linuxos vonalon is majd 30 napot kellett várni, míg minden foltozva lett egy új stabil kernelben, de egyrészt ezek linuxos szoftveres javítások kevesebbet lassítanak, mint a mikrokódos technika, plusz hamarabb is elkészültek, Windowsra még mindig nem jött ki a mai napig a végleges patch. Majd ha kijön, Torvaldsék megint lépéselőnyben lesznek, mert ők már nem hogy a patchon, de már annak az optimalizációin dolgoznak, amit addigra be is fejeznek, kijön a 4.16-os kernellel. Ha ők is vártak volna az Intelre, a mai napig nem lenne semmijük. A nyílt forráskód tette lehetővé, hogy ennyi fejlesztő ilyen gyorsan összedolgozzon, és ne kelljen függni az Inteltől. Csak hát megint ott van Gipsz Jakab, aki ezen kapva már tenné is fel a friss, javított kernelt, de oh wait, nem tudja, mert borul a rendszere, a zárt forráskodú szarja, amihez nem mer évek óta nyúlni, mert ne piszkáljuk azt, ami működik alapon még megy, és függősége van régi verziókhoz, így hiába lehetne előrelépni, vállalnia kell, hogy inkább sebezhető marad. Ugyebár az új kernellel dominósorban borulna neki minden, új kernel új systemdre és glibc-re dependel, de akkor már Xorgból is új kell, nem mennek a régi, egyedire fordított, azóta nyilvános nyílt forráskód hiányában újra nem forgatott kernelmodulok. Arch alatt meg a hobbista felhasználó kiad egy frissítés parancsot, és elégedetten használja az újdonságokat, anélkül, hogy PPA-val meg újraforgatással, disztrófrissítéssel, meg nem tudom mikkel kéne vergődnie, meg eltéesre meg feautre freezre és hasonló baromságokra várnia, hogy 1-2 év lemaradásban hadd használja már az épp aktuális verziókat.

Pont most volt gondja ebből valakinek a HUP-on, Debianon akart a szentem új Wine-t, ami nemrég jött ki, frissen, ropogósan, mindenféle új DX/Vulkan támogatással. Próbálta PPA-ból felszögelni, de teljesíthetetlen verziófüggések léptek fel. Ezeket elkezdte egyenként kézzel feloldogatni, hogy azokból is új csomagokat vadászott és forgatott, de utána azoknak a telepítése is teljesíthetetlen verziófüggésbe ütközött, amiket szintén fel kellett volna oldani, de azt már nem vállalta be, mert ennyi erővel az egészet telepíthette volna újra kézzel. Archon én akkor már kb. egy hete azt a Wine 3.akármit használtam, ami szépen lecsorgott egy pacman -Syu során olyan szép csendben, hogy fel sem figyeltem rá, probléma nélkül működött, sőt, tegnap frissült még újabb verzióra (3.3), míg máshová a 3.0-ás sem érkezett meg. Azért ez nem kis különbség.

Vagy szintén a HUP-on, még a Meltdown első heteiben indítja a topikot a szerencsétlen, hogy céges szerver, 3 tonna földdel elhantolva évek óta, megy, dolgát teszi, de most valaki véletlen átesett rajta, és ha már így belebotlottak, frissítették Meltdown ellen, és hiába zajlott le rendben a frissítés, meg volt hozzá backportolt kernel ebben a régi ágban, nem bootol. A történet lényege: CentOS 6 még 2.6.faxtudjamilyen kernel. No comment. De stabil volt, mint a beton. Míg frissíteni nem kellett. Amit nem lehet, csak ha az egész kócerájt újrarakja az ember.

De ugyanígy fogom a fejem, mikor reklámozzák, hogy ilyen olyan LTS disztró kettőezerhuszonsokig támogatott lesz. De mi a francnak? Addigra olyan régiek lesznek a csomagok, hogy érdemben nem sok mindenre lesz használható, csak muzeális használatra lesz alkalmas, arra meg főleg desktopon minek? Ha egy új böngésző nem fog rámenni, meg egy idő után már a Flasht sem lehet frissíteni rajta? Ki a ráknak szánják?

Utolsó ötlet: lm_sensors csomagot telepíteni. Mondjuk az a CPU freq állításba nem szól bele, de hátha van benne olyasmi, ami kell a kiolvasáshoz. Próbáld Mint MATE-en nézegetni, hogy miket enged állítgatni. ott hányas verzió van fent belőle, tartozik-e hozzá valami conf fájl.

Ez az applet amúgy a proci teljesítményét engedné állítgatni, vagy csak kijelezné?

Fent van az lm_sensors.
Mind a kettot tudja. Nekem foleg megszokasbol potyogott mindig a panelen. Holnap majd atnyalazom az Ubuntu Mate-t, az van usb-n.

Masik problemaval talalkoztam az elobb. Redshift nem megy. Elindul, de ki is lep. Felraktam melle Redshift Qt-t, es igy mar mukodik.

A redshift szerintem nem volt konfigolva parancssori paraméterrel vagy ~/.config/redshift.conf fájlban. Meg kell adni neki a földrajzi helyet, ahol használod (földrajzi szélesség, hosszúság, Google Mapról tudsz puskázni, meg hogy nappal és éjjel milyen színhőmérsékletre állítsa a monitort, meg a gamma világosságot, és van még egy pár beállítás). Arch Wiki Redshift cikkét most nem linkelem, nehogy Ubi Egon leszóljon, terminálban is meg tudod nézni a súgóját a man redshift segítségével.

Ilyenkor mindig terminálban kell elindítani, ki fogja írni, hogy miért nem indul. Ez minden olyan progira vonatkozik, ami grafikus felületen nem indul el, vagy elindul, de aztán kilép.

A Mate Gtk-s asztali környezet, szóval a redshift csomagban lévő redshift-gtk binárist kellett volna futtatni, bár config nélkül az sem indul el. Meg nálam az is hiányolt néhány Phyton extensiont (ezt függőségnek be kellett volna húzza, ez a csomagfenntartó hibája ráadásul), meg a dbus-t is igényli, de annak Mate-en rendbe kell lennie.

Lehet már a konfigurálással sem kell bajlódnod, mert lefutott a redshift-qt, azt beállítottad, kiírta a beállításait, és már csak futtatnod kell helyette a redshift-gtk-t.

[ Szerkesztve ]

Először terminálban nézd meg hogy cpupower-el tudod-e rendesen állítani.

You may corrupt the souls of men, but I am steel. I am doom.

Jo tudni, kovetkezonek mar ugy lesz ahogy irtad. Most mukodik rendesen, szoval nem piszkalom.

BoB: Igen tudom allitani.

Ok, de ott is ugyanezt kapod, vagy ott normálisan állítódik?

You may corrupt the souls of men, but I am steel. I am doom.

Nem allitodik at. Egyik opcio sem mutatja helyesen, az appleten belul.
powersave: 400 Mhz-et mutat
performance: 3600Mhz

cpupower config fajl-ban, ami a /etc/default/cpupower -ban nem piszkaltam. A governor-ok fel vannak benne sorova, de nem mertem be allitani...

Ha jól tudom az applet a cpupower-t használja. Ezért kérdezem, hogy terminálban a cpupower-el tudod állítani rendesen, vagy ott is csak így.

Most az applet nem érdekes.

You may corrupt the souls of men, but I am steel. I am doom.

Akkor a valasz nem.
a cpupower conf fajlban beallitottam ezeket, de semmi valtozas.
governor='ondemand'
min_freq="0.5GHz"
max_freq="3.6GHz"

Nem, rosszul tudtam. A GNOME applet-je használja a cpupower-t.

Viszont közben megtaláltam a hibát. A 4.7-es kernel óta egy új Intel processzor órajel állító került be. (intel_pstate)

A Mate freknvecia állító appletje a /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_freq fájlra hivatkozik, azonban ezt nem találja meg mivel ezzel az új meghajtóval ez a fájl már nem létezik, ezért látod hogy nem mutatja rendesen a frekvenciát.

Ezért ment ubyegon-nak, mivel neki AMD processzora van.

Két lehetőséged van. Vagy letiltod az új kernel modult és betöltöd a acpi-cpufreq kernel driver-t (ezt nagyon nagyon nagyon nem ajánlom), vagy nem használod ezt az appletet.

Helyette ott a GNOME-os applet, ami lehet hogy működik Mate alatt is.

Ennyit a Mate-ről sajnos, instant dislike.

You may corrupt the souls of men, but I am steel. I am doom.

Machine: System: TOSHIBA (portable) product: Satellite L305 v: PSLB8U-04X02F serial: X8371747Q
Mobo: TOSHIBA model: Portable PC Bios: INSYDE v: 2.20 date: 12/09/2009
CPU: Dual core Intel Pentium Dual T3200 (-MCP-) cache: 1024 KB
flags: (lm nx sse sse2 sse3 ssse3) bmips: 7981
clock speeds: min/max: 1000/2000 MHz 1: 2000 MHz 2: 2000 MHz

silentbreak

A Toshibán próbáltam ki ezt az ArchmD-t, ezen is Intel van. Jobb ezt az appletet hanyagolni, ha nem fut jól. szerintem
(nagygépre, amin dolgozom is, csak használható disztrót telepítek, sorry)

[ Szerkesztve ]

Az intel_pstate Sandy bridge-től kezdve megy.

Akkor nem azért megy nálad mert AMD, hanem azért mert túl régi a laptop

[ Szerkesztve ]

You may corrupt the souls of men, but I am steel. I am doom.

Sokkal régebben jelen van az intel_pstate. Akkor még 3.15-ös kernel volt. A linkelt hozzászóláshoz annyit fűznék hozzá, hogy nem a governor volt bugos, hanem a BIOS. Egy későbbi BIOS frissítés után minden helyreállt.

Alex

Akkor ez igy marad. Mate mar be van lakva, meg melozni is kell a laptop, szoval nincs is idom mast felrakni. Talan az xfce lenne a kovetkezo proba...
Gnome applet-et mar neztem, de nem akarom felrakni, sok gnome-os szir-szart huzna le melle.

Koszonom a segitseget mindenkinek.

Masik dolog, h valami jot is mondjak mar masfel napi Arch hasznalat utan

Front end web design-t csainalok. Minden egyes alkalommal ezek a programok futnak:
Atom; Firefox; Google Chrome; Gimp vagy Inkspace; System Monitor; Terminal, File Manager; Smplayer vagy online radio; bluetooth, Trimage

Ubuntu Mate-n kb 3.5Gb - 3.7 Gb ramot hasznalt.
Arch Mate: 2.6Gb - 2.9Gb ramot hasznal

[ Szerkesztve ]

Én úgy tudom, hogy a Core Solo, Core Nemkettő Duo, Core 2 Duo, Core 2 Quad prociknál is pstate van, meg talán már Pentium M, Core M prociknál is. Plusz Atom, meg mindenféle procinál, ami ezek után készült. AMD-hez nem értek, nagyon régen nem volt már AMD procim.

Egyébként gratula, szép megfejtés volt, erre a lehetőségre nem gondoltam volna.

[ Szerkesztve ]

Sehol senki nem ajánlotta az Archot kezdőknek. Az a Manjaro volt, amit pl. én továbbra is ajánlhatónak tartok bárkinek. Egyébként lehet Manjaro-val jobban is járnál, az is Arch alap, de felhasználóbarátabb, meg igaz, hogy pár nap eltéréssel frissítve az Archhoz képest, de épp úgy egész frissek a csomagjai. Így élvezheted az Arch előnyeit annak hátrányai nélkül.

Azért próbáld ki a Gnome-appletet. Nem olyan biztos az, hogy a fél Gnome-ot húzza magával. Meg ha még rosszabb esetben húzza is, akkor sem tölti be mindet, csak ami annyira szükséges belőle, nem hinném, hogy egy applet annyira sok memóriát megenni. Az is igaz, hogy talán Xfce-hez is van hasonló plugin.

Felraktam, de totalisan ignoralja. Szoval ez igy marad. Ha lesz idom, akkor kiprobalok egy masik feluletet (Gnome talan..). Xfce-nek van, es pl Manjaronal mukodik alapbol, Xubuntun viszont nem.

[ Szerkesztve ]

Az ArchmD-ben a szoftverközpontban csoportok/xfce-goodies-ből próbáld ki a xfce4-cpufreq-plugint, hátha működik, alig van pár függősége, talán csak az xfce-panel, de nem hiszem, hogy le kell cserélni a mate-panelt, igaz nincs sok különbség.

(#5047) berojocy

Akkor a fene se érti ezt. Nekem mindenhol működik, pedig nem is használom.

(a fenébe, csőbe húztatok! most látom, hogy ez az Arch topik, itt ne irkáljunk ilyeneket)

Azért azt meg kell jegyeznem, hogy a probléma csak nincs megoldva, hiába olvasni ezt a Kezdő topikban.

[ Szerkesztve ]

Amugy a vicces dolog, h mikor kipróbáltam a xubuntut, abban nincs benne alapbol. Igy hat felraktam a goodies-t, es miutan kiraktam a panel-re, az sem mukodott, csak csucsult a min Mhz-en.
Szoval, inkább hanyagolom, meg elek nelkule is.