log69 blogja

Előző bejegyzésem folytatásaként tovább kísérleteztem AppArmorral. Azt akartam kideríteni, hogy mi van ha egy meglévő (pl. gyárilag szállított) szabályt úgy akarok kiegészíteni, hogy csak bizonyos mappához ne férjen a folyamat.

AppArmort alapból tiltó (default deny) módon szállítja Ubuntu. Az általáunk "deny" előszóval ellátott szabályok pedig az engedő és tiltó szabályok sorrendjeitől független mindig tiltásra kerülnek. Tehát egy dologban biztosak lehetünk: ha implicit módon tiltunk valamit, azt más szabály nem tudja feloldani.

Ubuntu 13.04-en tesztelem AppArmor-t és játszadozok vele (Ubuntu howto itt). A CLI tool-ok tetszenek és gyorsan tudtam nekem megfelelő szabályt csinálni több programhoz.

A gyárilag szállított Firefox profilt használja valaki huzamosabb ideje? Mi a tapasztalat vele? A profilját átnézve elég engedékeny, valszeg majd csinálok a jövőben egy szigorúbb verziót és talán megosztom itt.

Ha valaki nem használta volna még AppArmor-t, röviden összefoglalom hogy mire jó és hogyan tudjuk használni a gyárilag szállított profilokat vagy generálni sajátot.

http://worldofgnome.org/rhel-7-is-shipping-gnome-shell-in-classic-mode/

http://lwn.net/Articles/557218/

Net szerte sokan keresnek egyszerű 2D támogatást Ruby-hoz, de nincs igazán olyan, amelynél a futtatási környezet telepítésével ne lenne komolyabb szívás (pl. Gosu vagy Rubygame meg hasonlók). Akár egyszerűbb fizikai szimulációkhoz, akár egyéb algoritmusok szemléltetéséhez hasznos lenne pedig.

Sok időm ráment, mire megtaláltam a megfelelő megoldást. Ezután létrehoztam egy Screen osztályt, mellyel könnyen bekapcsolhatunk egy SDL képernyőt és nagyon egyszerűen rajzolhatunk rá.

Git tárolómban megtalálhatók a példa kódok sdl_testX.rb néven, melynek elején kommentezve olvasható a futtatási környezet telepítése.

gem install pry
pry

Ha valakit mélyebben érdekelne a különbség (elsőre nem teljesen egyértelmű hogy mikor érdemes szimbólumot használni):

http://stackoverflow.com/questions/11447537/using-ruby-symbols
http://www.robertsosinski.com/2009/01/11/the-difference-between-ruby-sy…
http://www.troubleshooters.com/codecorn/ruby/symbols.htm

https://blog.heroku.com/archives/2013/3/6/matz_highlights_ruby_2_0_at_w…

Statisztikát akartam látni egyik git repómhoz. Fedorán találtam a hivatalos repo-ban egy python megoldást:

su -c "yum install gitstats"

gitstats ~/.git ~/output

firefox ~/output/index.html

Operát használtam mobilon sokáig, mert úgy tudtam ez az egyetlen böngésző, amely újra tudja tördelni a szöveg részeket a nagyítás mértékének megfelelően, hogy szöveg olvasáskor ne kelljen vízszintes irányban is görgetni sokat. Tegnap megnéztem FF-ot és fantasztikusan jó cuccot csináltak belőle, ráadásul tud tördelni (külön kell bekapcsolni). Chrome-hoz, a beépített böngészőhöz és Operához viszonyítva is megfelelőbb számomra.

Operához képest az előnyök szerintem:
- érzésre sokkal gyorsabbnak tűnik minden (S3 telón), mind a nagyítás, görgetés, visszaugrás
- egy oldalhoz nem csak 1 felh.név / jelszó párost tud megjegyezni, hanem a desktop böngésző mintájára akármennyit, ez kényelmetlen volt Operán
- vissza ugrásnál nem kell kétszer visszát nyomni, hanem azonnal az előző oldalra ugrik - ugye ez Operán úgy néz ki, hogy vissza ugrik az előző nézetre a legutolsó nagyítással megjelenítve, majd ezután megnyomva még mindig ugyanazt az oldalt fogja mutatni default nagyítással, és csak még egyszer megnyomva a vissza gombot fog az előző linkre menni

Megoldás:

http://kparal.wordpress.com/2012/12/03/gnome-3-6-gnome-online-accounts-…

Vagyis:

• Open Seahorse, filter your passwords for “GOA”, you should see one or two items of “Gnome Online Accounts password” type. Delete them.
• Re-login to Gnome session.
• Open Online Accounts and log in to your Google account. It will fail.
• Create an application-specific password for your Google account in the web browser.
• Open Seahorse, filter your password for “GOA”, you should see a single item. Open it and display the password. It will be very long, find the following section: 'password': <'your_password'>.

Weboldalamhoz színeket állítok össze. Csoportokba rendeztem az összetartozó színeket, ezekből van pár db. Mivel meguntam, hogy különböző módon passzoló színeket találjak ki, ezért sózott hash alapján generálok az alapértelmezett színekből véletlen színeket, ahol a só maga a unix time. Ezt az időt a Title-be is kiíratom, így tudom milyen értéknél kaptam ezt a véletlen design-t.

Így most csak nyomkodom a frissítés gombot és keresek egy nagyon színes, de mégis összepasszoló kombinációt. Nagyon érdekes kombók jönnek ki, olyanok is amit valszeg soha nem raktam volna össze. Leginkább emócionálisan döntök és jegyzem le magamnak az input sót. Ha pár dolog nem passzol, azon így már könnyebben variálok színenként.

Annak, aki szeretne Ruby-val ismerkedni, néhány link:

http://www.techotopia.com/index.php/Ruby_Essentials
http://rubymonk.com

Innét:
http://www.ruby-lang.org/en/documentation/

Fedora 18-tól integrálva van a tracker fájl indexelő szolgáltatás keresés funkciója a Gnome Shell-be. Ha keresünk, akkor nem csak az app neveket dobja, hanem a találatokat fájl tartalomra is.

Úgy látom hogy alapból csak a /home/user/Desktop mappa van indexelve, a sima user home nincs. Nem tudom hogy csak nálam maradt régebbről valami beállítás, vagy ez az alapértelmezett. Én az egész lemezem tartalmát indexeltetem, de ehhez a tracker-preferences kell, amely a GUI beállító felület. Nincs alapból telepítve.

Megoldás:

# gui beállító telepítése
su -c "yum install tracker-ui-tools"
# /home/user mappa engedélyezése a Locations tabon
tracker-preferences
# reset db
tracker-control -r
# indexelés újraindítása
tracker-control -s
# esetlegesen a folyamat figyelése
tracker-control -F

Fedora 18-on futtatott KVM alatt akartam a virtuális guest-eknek engedélyezni a host-on a https portot. Libvirtd egy virbr0 nevű bridge interface-t hoz létre a host-on.

F18-on az új Firewalld cseréli le Iptables-t. Hoz több dolgot, például interface-enként lehet állítani a zónákat - melyek nem mások, mint külön profilok a tűzfal beállításokra. Alapértelmezett a public, de van pl. work. Mindegyikben más portokat és átirányításokat engedélyezhetünk. De ezek interface-ekhez vannak rendelve.

Nem találtam meg hogyan lehetne virbr0-hoz is beállítani a zónákat. Az "Options / Change Zones of Connections..." menü egy olyan ablakot dob fel, ahol a Network Manager-ben létező interface-ekhez lehet állítani.

$SAFE = 2

Bővebben itt egy jó leírás.

http://repl.it

Megjelent.

Körülnéztem a neten és nem igazán találok olyan megoldást, amely Ruby kódot olvashatatlanná tesz és még akár nyílt forráskódú is. Van fizetős megoldás, olyan ami C-re konvertál meg byte kódra, de nem tetszenek. Olyat szeretnék, aminek az eredménye továbbra is megetethető a standard Ruby interpreterrel. Ha valakinek maximális elrejtés kell, annek esetleg ez játszhat.

Valszeg lefejlesztem Ruby-ban. Habár sokak szerint nem ér semmit, szerintem mégis.

Lenne kedve valakinek beszállni az ötletelésbe hogy hogy lenne érdemes? A következőkre gondoltam:

Most jött levlistán az infó, miszerint a Helios spin fejlesztői (mely egy Scientific Linuxra épülő verzió azzal a különséggel, hogy szállítják vele ZOL-t (ZFS on Linux)) kérvényt írtak, hogy SL szállíthatná alapból ZFS-t, és így még jobban minimalizálhatnák az upstream-től való különbözőségüket.

Eredmény: egy idő óta köztük tartó beszélgetés alapján a mai naptól SL szállítja ZOL-t az sl-addon repóban.

(SL 6.4-től lesz sl-addon repó, jelenleg 6.4 RC1 alól printeltem az infókat)

További infók:
http://zfsonlinux.org
https://github.com/zfsonlinux/spl

Lazy enumerators

Kellett kis idő hogy megértsem, de durva jóság. A lényege az, hogy ha az adatunkon (jelen esetben egy tömb elemein) olyan műveleteket akarunk végre hajtani, ahol a tömbök elemei több számításon és konverzión átesnek, akkor spórolhatnánk időt úgy, hogy csak azokat az elemeket és csak akkor számoljuk ki, amit a tömbre hivatkozás kíván. Főként ha az elejétől a végéig olvasnánk a tömbünk elemeit és olyan az algoritmusunk, hogy nem megjósolható előre, hogy mennyi elemet is kell kiszámítani, akkor már kézenfekvővé tenné az ötletet, hogy a sok adatból csak annyit számoljunk ki, amennyit kell - főleg ha a számolás drága.

Mi várható Red Hat Enterprise Linux 7-ben és mikorra? Gnome 3, BtrFS, LVM snapshot és a béta ISO-k 2013 első felében várhatók, a végleges pedig a másodikban. Bővebben itt.

Eredeti hivatkozás itt.

Személy szerint várom Gnome 3-at, a BtrFS pedig csalogató lesz, de kíváncsi leszek hogy Red Hat ajánlani is fogja-e vagy csak "technology preview" lesz.

Ha meg szeretnénk vizsgálni, hogy a program kódunk mely részei mennyi időt igényelnek a futáshoz, akkor Profiling techinkára van szükségünk. A cél a kódunk optimalizációja úgy, hogy felmérjük, mely programrészek a legidőigényesebbek és ezeket adott esetben átírjuk vagy újraírjuk.

Ruby-nak van beépített profiling megoldása. A "-r profile" paramétert megadva az interpreter kinyomtat az stderr kimenetre a program futása után egy statisztikát, melyben minden egyes sor egy külön metódust ábrázol és megmutatja, hogy mennyi ideig tartott a futása és mennyiszer lett meghívva.

Lambda megoldás Ruby-ban, vagyis sorba rendezés többszörös feltétel alapján (sajnos elég pocsék a Ruby dokumentáció és nem látom dokumentálva, 1.8.7+ verziókkal tesztelve és működik):

Array.sort_by{|var| [cond1, cond2, cond3, ..., condn-1, condn]}

Példa:

a = (1..10).map{|x| x = rand(2000)+10}
a.sort_by{|x| [x.to_s[1], x.to_s.length, x]}

Vagyis veszünk pár darab véletlen számot és sorba rendezzük őket elsődlegesen a második karakter alapján, másodlagosan a szám karaktereinek száma (string hossz), harmadsorban pedig a szám nagysága alapján.

SL / CentOS rendszerhez Epel repo-ban megtalálható cucc (~50 kb), Debian / Ubuntu-n is megtalálható csomagban. Ha nem akarunk a bonnie++-val szívni, akkor még jó is lehet egy gyors disk sebesség teszthez:

# write test
spew --write -b 16k 1000m testfile
WTR:   460834.89 KiB/s   Transfer time: 00:00:02    IOPS:    28802.18

# clear disk cache
su -c "echo 1 > /proc/sys/vm/drop_caches"

# read test
spew --read  -b 16k 1000m testfile
RTR:   195574.33 KiB/s   Transfer time: 00:00:05    IOPS:    12223.40

Érdekes lehet még ez a kapcsoló:
[code]
-r, --random (Read/Write buffers to random offsets)