locsemege blogja

25 kV RMS

Értem én, hogy extrém sport, kell az adrenalin, legyőzzük a légellenállást, turbulenciát, gyorsulásokat, meg mindent. Ez csak a mechanikai vonatkozása. Aztán ott van 0:31 és 0:43 körül még némi probléma. A kerámia szigetelőkön álló tápsín, a srác fejétől centiméterekre lévő felsővezeték. A tápsínt átlépi, mintha pusztán fizikai akadály volna. A vonat kasznija földpotenciálon, a felsővezeték, meg az a rúd úgy 25 kV-on, ami pillanatértékben másodpercenként 100-szor 35.4 kV-ot is elér.

Fresh player hogyan Fedorához

Lehet, lerágott csont, volt erről már szó, egy kérésnek teszek eleget ezzel a bloggal, s jó lehet akkor is, ha valaki szereti a kész megoldásokat.

Arról van szó, hogy Firefox-hoz az Adobe flash-plugin a 11.2-es verziója után már csak biztonsági frissítéseket kap, ugyanakkor a Google Chrome pepper flash pluginja és a Firefox közé létezik egy wrapper, amellyel újabb flash implementáció is elérhető Firefox alá.

A leírás Fedora 20-hoz és 21-hez biztosan jó, ezekhez kipróbáltam. A korábbi dokumentációkhoz képest nem nagyon fog új információt tartalmazni, inkább csak azért írom le, hogy magyarul, Fedorához legyen összeszedve, hogyan kell ezt csinálni. x86_64-re szól a leírás, de minimális módosítással i686-ra is jó lesz. Így érzésből, ahol lib64-et írok, ott 32 bites verzióban lib lesz.

zswap.enabled=1 --> zswap.zpool=zsmalloc

Legalább is Fedorán. Tehát, aki a 3.16-os sorozatú kernelben tömörített swap-et használt, az figyeljen oda arra, hogy Fedorán változott a kernel konfig, ezért az eddigi

zswap.enabled=1

mellett

zswap.zpool=zsmalloc

kernelparaméterre is szükség van a 3.17-es kernel sorozattól. Én is onnan tudom, hogy nem működött, jeleztem a bugot, lezárták notabug-gal a hibajegyet, s megmondták a fejlesztők a helyes megoldást. :)

Mount pointra immutable flag

Már másodszor fordult elő az utóbbi másfél hónapban, hogy a még meg sem jelent Fedora 21 valamiért nem csatolta fel a /home és /var alá a megfelelő LVM kötetet. Ilyenkor konzolig eljut, be tudok jelentkezni root-ként, tudok logot nézni, amiből kiderül mi a baj, az mondjuk már nem, hogy miért. Viszont az oprendszer egyes alrendszerei az értelemszerűen üres /var alá létrehoznak alapértelmezetten alkönyvtárakat, már, ha nem találják. Igen ám, csak ezzel baj lesz a legközelebbi indításkor, mert nem üres alkönyvtárra kellene mount-olni.

Amiért nem szeretem a közgazdászokat

Olvasom ezt a cikket, és közben bosszankodom, mert szerintem hibás következtetéseket vontak le belőle.

Azt mondja, csináltak egy pilot projectet Magyarországon úgynevezett okos mérőkkel, és nem váltotta be a hozzáfűzött reményeket, mert nem változott a projectben résztvevő magyar családok fogyasztási szokása. S mindezt azzal indokolja, hogy a rezsicsökkentés az oka, mert az pazarlásra ösztönöz. Bezzeg a fejlett Nyugaton megtakarítást értek el az okos mérőkkel.

top

Jaj, szegény én! :) Indítok egy top parancsot, aztán látom ám, hogy színes, a 4 CPU mag mindegyikéhez önálló sor tartozik progress bar-ral, a folyamatok fa struktúrában látszanak. Ahhoz, hogy legalább valamennyire is hasonlítson a régire, az 1Vz szekvenciát kellett nyomnom. Talán tegnapi frissítéssel jött.

rpm -qf `which top`
procps-ng-3.3.10-2.fc21.x86_64

Tudom, a Debiant használókat ez csak egy szűk évtized múlva érinti... :D

Még szerencse, hogy 'W'-vel lehet menteni a konfigot.

profile-sync-daemon

Nagy jóság, ilyesmit már csináltam magamnak, csak bénán, mert ennek systemd-vel kell indulnia, leállnia, én meg nem írtam hozzá unit file-t. Ez a szerkezet viszont megvalósítja ezt. Feltelepítettem, rögtön találtam is benne hibát, kijavítottam, patch-et elküldtem. :)

A hiba az volt, hogy a SELinux context-et nem másolta, így viszont nem fért hozzá a tmpfs-en lévő egyes saját profil file-jaihoz a böngésző. A SELinux context-eket is másolni kell RAM-diskre, így most jó.

Ja, hogy miről is van szó? Induláskor a böngésző profilt tmpfs-re RAM-diskbe rakja, symlink-et csinál rá, leálláskor pedig visszaírja HDD-re. Ha jól tudom, időnként csinál mentést. A lényeg, hogy ezáltal gyorsabb a böngésző, nem kell HDD-re várni, valamint nem nyúzza az SSD-t a gyakori írással.

Fedora 21

Pre-alfa állapotban van, de egy hirtelen ötlet alapján feltettem a gépemre. Eddigi tapasztalatok:

- sonata mpd kliens elhasal
Attempt to unlock mutex that was not locked
Aborted (core dumped)

- a Firefoxban a HUP fontjain nincs élsimítás, eddig más fontoknál nem látom ezt a problémát

- valamiért úgy tűnik roppant lassú a wireless hálózatom, a kernel 3.16.1-es. Ezt azért tesztelni kell, mert lehet szolgáltató, szerver, bármi. Az gyanús, hogy bárhonnan töltenék le, nagyon lassú

- a Xorg.bin a root nevében fut, holott talán sima felhasználóként kellene. Ennek viszont lehet, vannak feltételei, így utána kéne olvasnom

Seren

Ez is VoIP alkalmazás, csak terminálban fut, ncurses felülete van. Kipróbáltam, igen jó hangja van, helyesebben szólva széles tartományban konfigurálható a bitráta, így eldönthetjük, hogy legyen-e szép hangunk, benne a nagyobb frekvenciás harmonikusokkal, vagy inkább kis sávszélességet egyen. Ha felépítettük a kapcsolatot, akkor tudunk chat-en üzenni, linket küldeni a partnereknek. Addig nem, mert pont-pont kapcsolatot valósít meg, nincs közbenső szerver, így azt sem tudná, a chat üzenetet milyen IP-címre küldje. Alapértelmezetten a 8110-es UDP porton várja a hívást meg a hangot, így a tűzfalon ezt kell beengedni, illetve NAT mögé forwardolni.

IHU

I Hear U, valami ilyesmit régóta keresek. Fedora 20-on elindul a statikus build, kell neki a libXmu.i686 csomag. Visszahurkolva localhost-ra, működik, bővebb tapasztalatom nincs vele. A pulseaudio-t kellene meggyőzni, hogy csináljon visszhang elnyomást. Talán a PULSE_PROP környezeti változó segíthet, de ennek még utána kell járni.

Kár, hogy nem fejlesztik már. Jó volna kipofozni, pulseaudio-val kompatibilissé tenni. Most is az, de csak az ALSA kompatibilitási felületen keresztül.

Hibernálás után újraindulás megint megjavítva

Valamiért az alaplapom olyan, hogy hibernálás esetén alapbeállításokkal ugyan leáll, de kb. 1 s elteltével visszakapcsol a gép.

Korábban erre a problémára találtam megoldást, ami viszont újfent nem működött manapság, hiszen már ezt is a systemd csinálja.

SSD-re költözés tapasztalata

Az éjszaka egy munkagép kapott az eddigi 4 GiB helyett 8 GiB RAM-ot, egy 128 GB-os SSD-t, egy nVidia kártyát. Eddig alaplapi Radeon volt használva. Az oprendszer 64 bites Fedora 20, újratelepítést szerettem volna megúszni, egyébként sikerült is. Látszólag igen könnyű egy ilyen költöztetés, de azért vannak buktatói.

Beépítve az alkatrészek, BIOS-ban kitiltva az alaplapi VGA, majd boot. RAM megvan, hurrá. SSD partícionálása a javasolt módon, laphatár, miegymás. Hagytam partícionálatlan szabad helyet, sokat. Az sdb1 4 GiB a /boot-nak, az sdb2 60 GiB a /-nek, amin csak az oprendszer lesz, ez LVM. Utána pvcreate, vgcreate, lvcreate, laphatárra alignment, majd ext4-re formázás. /boot remount readonly, majd rsync -avHAX HDD-ről SSD-re a /boot-ot. Az SSD-t noatime,discard opciókkal csatoltam.

Számrendszerek és a bevezető nullák

Egy apró kellemetlenség, amit bash-ben könnyű elkövetni, nekem legalább is sikerült. Alkönyvtár neve ilyesmi:

20140024.123

Ebből az első 4 számjegy az év, utána a pontig az, hogy az év hanyadik napja van. Igen ám, de ha ez nullával kezdődik, a bash oktálisan értelmezi, így aztán a 0008-ra hibát fog dobni. Amire nem, az is helytelenül lesz feldolgozva.

Így aztán le kellett csippentenem a vezető nullákat. Amíg nem kaptam hibaüzenetet, elkerülte a figyelmem.

Heisenbug

Most, hogy kedden lesz már béta, csináltam frissítést:

cat /etc/system-release
Fedora release 20 (Heisenbug)

Néztem a boot.log-ot, hibátlanul indult az összes daemon.

Sajnos egy függőségi hiba miatt átmenetileg meg kellett váljak az mpd-hez használt sonata kliensemtől. A probléma így néz ki:

Thunderbird message list csíkozás

Fogalmam sincs mitől, de az egyik frissítéskor eltűnt a soronként változó háttérszín a Thunderbird message list-ről. Akkor csináltam egy CSS-t, amivel meg az volt a baj, hogy ha az üzenetbe kattintottam, elmúlt a kijelölés, így nem látszott, melyik levélnél tartok a nézelődésben. Most megcsináltam. A chrome/userChrome.css file tartalma:

Fedora live készítése

Régóta problémám, hogy jó volna, ha lenne a zsebemben egy boot-olható live linux pendrive-on. Néztem már kész példányokat, de mindegyikkel volt valami bajom. Túl régi csomagokból áll, nem azok a programok vannak benne, amelyeket szeretnék, nincs saját felhasználói profil, effélék. Ezekre a gondokra saját készítésű live linux alkalmas.

Elindultam hát erről az oldalról. Mivel azt szerettem volna, hogy régi gépen is fusson, amit csinálok, így a 32 bites x86 architektúrát választottam. Praktikusan, hogy bátran kísérletezhessek, VirtualBox-ba telepítettem egy 32 bites Fedorát. Az erőforrások kímélése érdekében Openbox környezetet választottam fbpanellel.

Hibernálás után újraindulás, megoldva

Valamikor, talán a 2.6.33-as kernel tájékán - nem vagyok benne biztos - elmúlt a gépem hibernálhatósága. Jött az új kernel, s innentől kezdve leállás után kb. 1 másodperccel bekapcsolt a gépem. Ez egy MSI K9A2 CF alaplap, nem mai darab már, de stabil, megbízható. A BIOS a legfrissebb, amit a gyártó kiadott hozzá. Addig keresgéltem a neten, míg egy 2008-as Arch fórumban megtaláltam a megoldást. Létrehoztam a

/etc/pm/config.d/defaults

Logout script Xfce környezetben

Zenehallgatásra MPD-t használok, mert csak. Ugyanakkor a PulseAudio hangszerver felhasználónként indul. Ezzel az a gond, hogy belép az egyik felhasználó, elindul a hangszerver, autostart scriptből indul az MPD, csatlakozik a hangszerverhez. Kijelentkezéskor jó volna kinyiffantani az MPD-t és a hangszervert, hiszen ezek nélkül a másik felhasználó belépésekor indul ugyan hangszerver másik példánya, de a másik felhasználó MPD-je már nem a második hangszerverhez szokott kapcsolódni. Arról nem is beszélve, hogy ha több MPD fut, hova csatlakozik vajon a Sonata kliens? Tehát kellene logout script.