yoursoft blogja

Linux energiabeállítások

Jelenleg KDE Neon van az otthoni laptopomon + kénytelen voltam felrakni egy Win10-et is, hogy frissítsem a bios-t.

Ez egy Lenovo Ideapad 3 32G RAM-al.

A Win10 szinte alapból feltelepített minden drivert, a Lenovo Vantage már csak a hálókártya drivert frissítette.

A Linux alatt jelenleg 6:57 percet ír ki a hátralévő akku időnek, míg Win10 alatt 4:43 percet kb. ugyanakkora töltöttségnél (65%).

 

De mi is kellett ehhez?:

 

Powertop telepítése

cat << EOF | sudo tee /etc/systemd/system/powertop.service
[Unit]
Description=PowerTOP auto tune

[Service]
Type=idle
Environment="TERM=dumb"
ExecStart=/usr/sbin/powertop --auto-tune

[Install]
WantedBy=multi-user.target
EOF

---
systemctl enable powertop.service

 

TLP telepítése

sudo apt-get install tlp tlp-rdw
(Thinkpadokon - nekem nem aktuális:
sudo apt-get install tp-smapi-dkms acpi-call-dkms)

 

TMP memóriába

sudo cp -v /usr/share/systemd/tmp.mount /etc/systemd/system/
sudo systemctl enable tmp.mount

 

auto-cpufreq

https://github.com/AdnanHodzic/auto-cpufreq

Ezt forrásból telepítettem a leírás szerint. A snap valamiért nem működött. Valószínűleg elbénáztam valamit.

 

Ami maradt még kérdés:

A Vantage-ban Win10 alatt be lehet állítani, hogy csak 50-60%-ig töltsön a laptop, ha felette van nem fogja tölteni az akkut. A hálózati áramot használja, de nem tölti az akkut. Azaz az akku csak önkisülést végez. Ez kíméli az akkut ha hálózatról használjuk.
Itt csak az a gondom, hogy Linux alatt nem találtam még meg a ki-be kapcsolóját. Bár nem is nagyon kerestem.

Win10 alatt bekapcsoltam és jelenleg ez a beállítás aktív Linux alatt is.

DBeaver bug jelzés

Nemrég jeleztem egy hibát:

Ha pl. szerkesztettél az editorban, de túllépted a 200-as limitet és emiatt újabb 200 rekordot töltött be, akkor hiába nyomtál rá a Save buttonra, bár úgy csinált mintha, de nem mentette a változásokat.

A javítás december elejére várható.

KDE több évtizedes bug

Végre javítják talán a klipper több évtizede meglévő desktop fagyását.

Küldtem be Nekik példa állományt. Kicsit erőszakoskodnom kellett, hogy ne keverjék el a jelzésem.

Most úgy tűnik az 5.23-asban javítják.

Kár, hogy közben munkahelyet váltottam és itt win-t kell használni. :(

Vissza KDE-re

Oregonnak igaza lett, ismét KDE van.

Gondolkodtam az OpenSuse-n, ki is próbáltam. De a céges beállítások gyorsan kellettek, így visszamentem Neon-ra. Ha lesz időm lehet majd kipróbálom. Szimpatikus volt.

Nem volt különösen bajom a Cínnamon-al sem. De valahogy már nem volt annyira otthonos.

Annyi változott, hogy most back-in-time-ot használok TimeShift helyett.

KDE Neon-ról vissza a Linux Mint-re

No, Csütörtök este valami frissült Neon alatt, majd lefagyott a rendszer.

Újraindítás után egy friss, ropogós home könyvtár fogadott. Magyarán: eltűnt elég sok dolgom.

Nem mondom, hogy nem lehetett nálam is hiba, hiszen mint kiderült volt régebben néhány apt-s frissítésem is, ami Neon alatt nem normális. Így voltak akadásaim az oprendszerrel.

KDE Neon

Pár nap használat után.

Összességében elégedett vagyok.
Az elején a mivel rengeteg beállítás van, így sokkal jobban testreszabható, de több idő el is ment vele. Így jár aki mindent testre is szeretne szabni, amit lehet.
Memóra is indítás után úgy 380M körül van (kb. 5 perc várakozás után is). Ez is rendben van.

Egy-két apróság van:
- numlock nem kapcsol be boot után, hiába állítom be - Erre az a gyanúm, hogy mivel rengeteg dolgot lehet állítani, lehet, hogy egy másik beállítás keresztbe tesz.
- Képernyők háttere diavetítésben csak külön-külön sikerült. Együtt nem változnak.
- Magyar fordítások hiányosak, de átraktam angolra. Így ez is rendben.

UPDATE 2019.10.27

- A numlock egy frissítés után működik.
- Ami még tetszik: Pgadmin3 (gtk2?) végre normálisan jelenik meg a Cinnamon-hoz képest.

Kubuntu 19.10 vs. KDE Neon (18.04)

Eddig Cinnamont használtam. Olyan atom stabil volt, hogy már-már unatkoztam.
Egyedül néha 1-2 ablakváltásnál volt gondom.

Tegnap feltelepítettem a Kubuntu 19.10-et. Ebben elég sok gondom akadt. Pl.
- Az Alt+F1-re felugró panel menü gyorsgombot letiltottam (IntelliJ-ben gyorsbillentyű). Következő boot-nál viszaállt.
- Nem tudtam feltelepíteni a megszokott SSH kliensem (sem PAC, sem asbru)

Feltelepítettem a KDE Neon-t. Eddig minden működik.

Ami csalódás volt mindkettőnél:
VirtualBox-ban kipróbálva a kezdeti memóriaigényt sikerült lenyomnom 300M környékére. Itt mindkettőnél a kezdeti 480-550M környékén mozog.
A Cinnamon ~ugyanezen beállításoknál emlékem szerint olyan 600-700M között mozgott.

KDE-re áttérés

Kb. ugyanazt sikerült beállítanom, mint Cinnamon alatt.

RAM-ból így alapból 430M körül eszik, míg a Cinnamon 750M körül. Ezt nem tudom, hogyan lehet tovább csökkenteni. Oracle VirtualBox-ban alapból 280M körül evett friss indítás után.
Valamit kihagyhattam, amit ott még elvégeztem.
Kikapcsoltam az érintőképernyőt, kompozitort. Ezek ettek viszonylag sok erőforrást.

Amik még zavaróak:
- egyes alkalmazásoknál (pl. RamBox), ha kitűzöm a tálcára, akkor csak elindítás után jelenik meg a rendes ikonja.
- SQL Developer ikonját hiába tűzöm ki, elindítás után új ikont nyit.
- localizáció nem teljes, lehet inkább angolul használom majd emiatt

Chromium / Firefox állandóan ír 2.

Végül ezek szerint a leírások alapján:

https://easylinuxtipsproject.blogspot.com/p/speed-mint.html

https://easylinuxtipsproject.blogspot.com/p/first-mint-cinnamon.html

Most még az Opera és a Firefox van versenyben.

Viszont váratlan mellékhatás lett, hogy a Cinnamon sem ír napi 2-4G-ákat az SSD lemezre, valamint a többi alkalmazás is elcsitult. Ez szerintem a tmpfs memóriába helyezésének köszönhető.
Jelenleg a tegnap esti újraindítás után, kb. jó ha összesen mindenki együtt írt max. 150MB-ot a lemezre.

Chromium / Firefox állandóan ír valamit

Most ez a kérdés izgat.
Miért írkálnak ezek folyamatosan disket?

Találtam olyasmit, hogy így menti el az egyes fülek állapotát mindkettő böngésző 15 sec-enként. Ha jön egy összeomlás, akkor vissza tudjanak tölteni.

Ez eddig szép és jó lenne, de ha nem csinálok semmit a böngészőben, akkor miért nem jegyzi meg, hogy "nincs változás / nem kell írni".
A Chromium az elsődleges böngészőm, így az kb. 1.2GB-ot írt ki reggel óta olyan 30-40 füllel (igaz a great suspend tab miatt olyan 3-4 fül van aktívban). A Firefox meg egy füllel (reggel óta nem is használtam) olyan 290MB-ot

Meltdown / Spectre javítás hatása (Java)

Hát ez eléggé visszadobott :-(

vmWare, ubuntu 16.04
Tomcat start: viszonylag nagy mennyiségű serializált adat betöltésével (~800 MByte)
kernel frissítés előtt: 54 sec
kernel frissítés után: ~300 sec
kernel frissítés után (patch kikapcs: pti=off): 78 sec

KVM, ubuntu 16.04
Tomcat start: viszonylag nagy mennyiségű serializált adat betöltésével (~800 MByte)
kernel frissítés előtt: ~80 sec
kernel frissítés után: ~140 sec

LXC, ubuntu 16.04, (Itt a host is biztosan patchelve van)
Tomcat start: viszonylag nagy mennyiségű serializált adat betöltésével (~800 MByte)
kernel frissítés előtt: ~80 sec
kernel frissítés után: ~150 sec

Win10 viselkedési anomáliák

Volt egy kis gondom a win10-el. A startmenü keresési eredményein hiába kattintgattam a bal egérgombbal és hiába próbáltam billentyűzetről ugyanezt, nem akartak elindulni az alkalmazások.

Sok mindent próbáltam.
Próbáltam letiltani / engedélyezni a Cortanát, ellenőriztettem a rendszerfájlokat, újratelepíttettem az alkalmazásokat, letiltottam alkalmazásokat, újraindítgattam a win-t stb.

Végül az alábbi megoldást találtam a neten:
1. létrehoztam egy másik helyi felhasználót.
2. beléptem a másik felhasználóval, és letöröltem a \users\problémás_felhasználó\AppData\local\packages\Microsoft.Windows.Cortana*-ot.
3. Visszalépve az eredeti (hibás) felhasználóval meggyógyult

MikroVps vs Vultr és CloudFlare

Ha megpróbálok egy nem nyitott porttal csatlakozni a domain-hoz, akkor a CloudFlare kijelzi, hogy Frankfurton keresztül szeretne csatlakozni a böngészőm.

Az elmélet ez alapján az volt, hogy ha Frankfurtban van a szerver is, akkor gyorsabb lesz az elérés.

Mivel a Vultr VPS-ekről sok jót hallottam, így gondoltam tesztelek egyet.

Amit most látok:
Nem lett gyorsabb az elérés. Google analytics sem mutat változást a sebességben és a webpagetest sem. Valamint a próba oldallekérések sem voltak gyorsabbak (inkább lassabbak).

Amit még teszteltem:

sysbench --test=cpu --cpu-max-prime=50000 --num-threads=10 run
sysbench --test=memory --memory-total-size=1G run

CloudFlare 2

Tehát mint írtam a javascript késleltetési trükkök valóban leviszik az oldalbetöltési időket.
A dolognak viszont van hátulütője is:
1. Analytics script - később töltődik be, e miatt egy csomó mindent nem mér. Kevesebb látogatót mutat, több a visszafordulók aránya stb.
2. Adsense scriptek - ugyancsak később töltődnek be, így kevesebb a kattintás is.

Ezeket ki lehet kapcsolni a CloudFlare-nél (Rocket).

Ezeket nem használom a továbbiakban.

Viszont találtam optimalizálandót a saját kódomban.
Az egyik az volt, hogy végigszaladtam a dom-fán és kattintási eseményeket rendeltem hozzá egyes elemekhez. Ezt kicseréltem egy globális figyelőre, ha valamin kattintanak, vizsgálom, hogy milyen elemen kattintottak, ha érintettek az ügyben kezelem, ha nem visszaadom a kezelését.
Meg volt még néhány apróság.
Így olyan >10%-ot sikerült lefaragnom a betöltési időből.

CloudFlare hála Neked

Sokat tanultam a CloudFlare-től.
Bár valószínűleg nem fogom használni. Azért hálás vagyok a tapasztalatokért.

Ebben a témában ajánlották: hup.hu/node/131348

Most éppen az oldalletöltési időket tanulmányozom.
Azt észrevettem, hogy amikor be volt kapcsolva csökkentek az oldalletöltési idők.
Csodálkoztam rajta, mert annyira nem éreztem gyorsnak a szervereiket.
Jobban megnézve ezt a Rocket Loader végzi.
Ha jól sejtem a következő zajlik le:
A CloudFlare kicseréli a type="text/javascript"-et type="text/rocketscript"-re.
Így a böngészők csak elolvassák, és sokkal gyorsabban érnek el így az onload eventig. Majd ezután alakítja csak vissza a scripteket rendes javascriptté.
Ha jól sejtem a google is az onload időket méri, így sorol előrébb SEO szempontból is.

Két varázsbot / 2

Másnap pirkadatkor valóban a folyóparton járt már a két fiú. Ott lapultak a híd jobb parti pillére mögött, ahol tizenhét évvel ezelőtt Karakán apja akarta magára vonni az ártó szellemek figyelmét. A Szőke Tündér itt egy hosszú, hol kiszélesedő, hol elkeskenyedő szigetet ölelt körül, melynek fái közt dió is akadt. Karakán egyszer meg is dézsmálta őket, holott tudta jól, az már a farkasemberek birodalma, akik alaposan elhúzták volna a nótáját, ha rajtakapják. A sziget mögött a bal parton egy falu romjai meredeztek az ég felé. Csak két házon volt tető, s a templomtornyán. Köröskörül állt még néhány kőfal, egy-egy megroppant csűr, de semmi több.

Két varázsbot / 1

A két varázsbot (Molnár Géza) / 1

Karakán diót evett, ehhez most már nem fért kétség. Ült fenn a sziklapárkányon, közvetlenül a búvóhelyükként szolgáló barlang felett, egy öklömnyi kővel törve fel a kemény csonthéjakat, s nagy élvezettel ropogtatta a csemegét. Zolta valamivel feljebb lapult a szikla tetején, alig pár karnyújtásnyira barátjától, és azon töprengett, vajon ezúttal sikerült-e észrevétlenül megközelítenie.

Zolta sok mindenhez értet. Jól lőtt, biztos kézzel dobott célba, lándzsával, kelevézzel, csatacsillaggal, de akár kővel. Ügyesen forgatta a kardot és a csatabárdot, de az igaz tudománya egészen másban rejlett. Oly hangtalanul, oly csendesen suhant, mint a lágy, nyáresti szellő, mely lombot sem rezdítve lendül fáról fára, ágról ágra, levélről levélre, vagy mint az őszi köd, mely a semmiből bukkan elő, s mire az ember észrevenné, már körül is ölelte őt. Igen, a fiú észrevétlenül tudott a közelébe férkőzni szinte bárkinek és bárminek. Az emberekkel nem igen akadt gondja. A legélesebb fülű harcost is oly könnyedén cserkészte be, mintha csak egy fatörzsről lenne szó. Ugyanígy volt a házi állatokkal is, bár néhány lóval meggyűlt a baja. Fecske például harminc-negyvenlépésnyi távolságról már kiszúrta, de ez még így sokkal jobb volt, mint amire bárki más képes lett volna a törzsből. Egy szó, mint száz, Zolta ügyes volt, e téren a legügyesebb, ezt mindenki tudta róla, de hogy mindez mit is jelent a valóságban, a beavatása napján mutatta meg. Amit addig tett újgyakorlatok voltak csupán, de amit akkor: maga a egytiszta művészet. Egy tíz-tizenöt állatból álló rudlit kerülgetett. Az őzek lenn gyűltek össze a kerítésnél. A tavalyi széna maradványát szemezgették. Egyet kellett volna kiemelnie közülük, s így csak egy nyílveszőt vihetett magával. Egyetlen egyet. Ám ő kockáztatott.
Lőtávolba érnie nem volt nagy kunszt, ezt bármelyik korabeli fiú megtette volna. De ő többet akart, így hát közelebb merészkedett. Sokkal közelebb. Kinézett egy fiatal bakot. Úgy tervezte, néhány lépésnyire megközelíti, majd egy jól irányzott lövéssel leteríti. Ha ügyes, és szerencsés is egyben, az állatok nem ugranak el. Igazából arra számított, a többiek majd felkapják a fejüket, körbekémlelnek, beleszimatolnak a levegőbe, s neki épp elég ideje marad, hogy az egyikük szembe vágja a csatacsillagot. Ha a terve beválik, biztosan megszerzi a nevét, ha kudarcot vall, vár három évet a következő lehetőségre.

nginx ajp module

https://github.com/yaoweibin/nginx_ajp_module

Egy kicsit kísérleteztem vele, majd találtam néhány hibát (ékezetek az url-ben, néha eldobta a kapcsolatokat, sok zerro buffer size alert).
Jeleztem a hibákat a fejlesztőnek, aki nagyon gyors és rugalmas volt. Javította a hibákat.

Gyorsabb is lett így a tomcat nginx páros, mint a sima nginx http proxy-val.

Egyszer, ha lesz időm kimérem, hogy gyorsabb-e mint az apache httpd tomcat páros.

update:
A fejlesztő blogjában van egy teljesítmény teszt mod_jk vs nginx ajp:
http://translate.google.com/translate?u=http%3A%2F%2Fyaoweibin2008.blog…

A Lenovo T400-asom nem indul :-(

Tegnap este még használtam, majd készenléti állapotba helyeztem.
Ma reggel nem világított a készenléti állapot ledje.
Hálózatra rádugtam, majd próbáltam indítani, de csak fekete képernyőt látok :-(

- Próbáltam a belső / külső monitorok között váltani, de arra sem reagál.
- próbáltam a telepet kivenni, majd visszarakni arra sem reagált.

Elég sok mindenem volt rajta, bízom benne nem halt teljesen le :-(

Firefox vs Chrome

A most divatos javascript benchmarkok nem igazán tudnak lenyűgözni.
Ezekben is hol az egyik, hol a másik győz.
Most, hogy a Firefox egész Chrome-os külsőt kapott gondoltam megnézem inkább, hogy egyes oldalak mennyi idő alatt töltődnek be.
Mindkét böngészőnél CTRL + F5-el töltöttem be az oldalakat és mértem a betöltődés idejét (firebug net panel illetve Chrome beépített net panel). 1-2 másodperccel a Chrome volt a győztes minden alkalommal.
Pl. DistroWatch.com
FF: 7.63s / 9.9s
C: 6.67s / 7.16s

Hát sajnos az új FF nálam ebben nem nyert, így marad egyelőre a Chrome. :-(

Chrome is kezd bughalmaz lenni

Frissült a Chrome 7-es verzióra.
Csodálkozva tapasztaltam, hogy nem játsza le a hangokat a dictzone.com-on.
Ez úgy látom nem csak engem érint, hanem szinte mindenkit aki dinamikusan kezel flash-t javascriptből.

Küldtem egy bug reportot, még a dev verziónál erről:
http://code.google.com/p/chromium/issues/detail?id=58542#makechanges

Most látom, hogy nem javították ki a "végleges" 7-es verzióra. :-(