log69 blogja

Szórakoztam ffmpeg-gel, és ezt találtam a manual-ban:

       * You can transcode decrypted VOBs:

               ffmpeg -i snatch_1.vob -f avi -vcodec mpeg4 -b 800k -g 300 -bf 2 -acodec libmp3lame -ab 128k snatch.avi

:)

Flashblock és Noscript sem szükséges hozzá. Ha kikapcsoljuk a javascript- és a plugin használatot minden oldal esetében, akkor e kettőt felajánlja minden oldalnál a jobb felső sarokban a könyvjelző csillag mellett, és 3 kattintással engedélyezhetjük a javascript-et vagy a plugin (pl. flash) használatot egy oldalnak.

Ezen kívül tényleg gyors.

Egy betűmérettel kapcsolatos kérdésem volt, amely már megoldott - köszönet a segítségnek.

Tényleg jó lett ez a böngésző, és tetszik. Jó hogy a jobb egérgombra az első menüpont az új tab, és nem az új oldal. Ugyanitt van Incognito lehetőség is, illetve egy kijelölés is megnyitható új tab-ban.

Elérhetőek már napi frissítésű build-ek is a Live-ból:
http://live.debian.net/cdimage/daily-builds

vagy esetleg:
http://live.debian.net/cdimage/daily-builds/squeeze/current/i386/iso-hy…

Betették a Chromium böngészőt a testing-be. Ma jött.

SL4A = Scripting Layer for Android (előzőleg Android Scripting Environment vagy ASE)
http://code.google.com/p/android-scripting/

Ez egy szoftver réteg az Android platform és a script nyelv között, mely segítségével nagyon egyszerű kiterjesztést írni az Android platformhoz. Az alábbi nyelveket támogatja: Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell

Engem speciel python érdekel, ennél egy import android betölti a teljes android modult. Az SL4A telepítésével és a python modul telepítésével egy rakás minta program is telepítésre kerül.

Sajnos abba hagyja a fejlesztője a BSDAnywhere további kiadásait, mely egy OpenBSD-re épülő Live CD rendszer volt.

"BSDanywhere as a project has been ceased as of now. There will be no new releases any time soon. I am now directly involved with OpenBSD and will put all my efforts into the OpenBSD project instead."

Egyik C-ben írt progimat át akarom konvertálni ISO C90-es formába, amely GCC-nél a -pedantic kapcsolóval értelmezhető. Írtam rá egy szkript-et a // jellel kezdődő kommentek átkonvertálására.

Kicsi szivatós volt a dolog, mert pl. a \ jeleket és a tab-okat teljesen kikapta a progim, ezért azt ki kellett trükköznöm.

Esetleg megírhattam volna még python-ban, de mivel úgy néz ki csak egyszer kell nekem, most több időt nem ér.

----
[code]
#!/bin/bash

NUM=$( echo hello | md5sum | grep -ioE "^[^ ]*" )
NUM2=$( echo hello2 | md5sum | grep -ioE "^[^ ]*" )

if [ -z $1 ]; then echo error: file name missing; exit 1; fi

Pont erre kerestem lehetőséget az elmúlt 2 napban, hogy követni tudjam a testing ágban történő változásokat tömör infó formájában, erre a csoda meg is jött e-mailben tegnap :)

A hírlevélből:

"Jörg Jaspert announced a new service for users of Debian's "testing" branch: thechangelogs of packages migrated to the testing branch [25] are now aggregated and available in a single file. This makes it easier for "testing" users to review changes in specific packages before they install them. The files are available from all mirrors in thedists/testing directory, and are rotated on a daily basis, being kept about two days. There's also always a symlink to the latest one [26]."

Ez a fórum bejegyzésem alapján arra jutottam, hogy írok inkább egy saját script-et a problémámra.

Az alábbi volt a feladat amit magamnak állítottam: nagy (10 GB > méretű mbox fájlokban akartam gyorsan keresni, index-elt adatbázis alapján).

Úgy oldottam meg, hogy a script-em 2 paramétert fogad: 1) mbox fájl 2) keresett kulcsszó

A script-em átkonvertálja az mbox fájlt apró fájlokra maildir formátumba mb2md-vel, majd ezt leindexeli namazu-val, a végén rá keres az adatbázisra namazu-val a kulcsszó alapján.

Minden esetben hash alapján tárolom a temp könyvtárban az eredményeket, hogy többszöri futtatáskor is csak egyetlen egyszer kerül leindexelésre az egész anyag.

http://www.fractalism.com/fractals/alien.htm
http://www.fractalism.com/fractals/kaleidoscope.htm

brutál szépek!

szerk.: számomra ennyi elég hogy elhigyjem, a világon minden lehetséges, és hogy az emberi képzeletem nagyon korlátolt ;)

Feleségem vett ilyen szőnyeget. Miért pont ne ilyet..?

(a színek sz.rok, mert nincs vakum)

Nézegetem Debian 6-ost.

VBox-ban egy alap telepítés grafikus felület nélkül. Kb, 670 MB lett. Ez után egyetlen xfce4 metacsomag telepítése.

Már az új esemény vezérelt init script megoldással megy. Ami érdekel, az a változások a számomra szükséges szolgáltatásokban.

Számomra pozitívumok:
- jó a konzol font, vannak ékezetes karakterek is (habár ez ezelőtt is meg volt)
- Xfce alap témája tetszik, GTK és WM is elmegy, főleg Lenny után ;)
- hála égnek csak egy Xterm van X terminálnak és nem telepít ezen kívül mást - aki akar úgyis fel tud tenni, de nem bánom ha nincs fent ami nem kell
- xfce4 csomag után a grub grafikusra váltott, ez is elmegy, a téma sem rossz szerintem, igazából úgy vagyok vele hogy csak csúnya ne legyen, a többi ok :)
- alapértelmezetten van joga az alap (telepítéskor megadott) nem rendszergazdai felhasználónknak a leállításhoz, újraindításhoz, altatás stb. - ez szintén nem így volt Lenny-nél, ott a powerdev csoporthoz hozzá kellett adni
- alapból működik vele a "Mouse integration" 3.2.4-es VBox-szal (Lenny backports), ez mellékes, a 32-es kernel miatt van gondolom
- ennél az xfce verziónál is van alapból "Open terminal here" menü, és Xterm-mel nyitja meg a helyet
- a kilépés menü tartalmaz altatást és hibernálást

screen használatakor néha előfordul, hogy Ctrl+A 's'-t nyomok, amely "megfagyasztja" a terminált.

Végre rátaláltam a gentoo wiki-ben, hogy lehet kikapcsolni véglegesen:

.screenrc fájlba:
bind s

Ez a wiki szerint a régebbi terminálok "hozadéka":

"causes the parent terminal to freeze (a relic of old terminals which might get "overloaded" with input and need some way to immediately stop screen changes)."

Ezzel már nincs szükség Ctrl+A 'q'-ra a feloldásra.

Biztos ismeritek a 3A+1 problémát. Ha van köztetek matematikus, meg tudná mondani, hogyan áll ma ennek a bizonyítása? Vagyis hogy mindig lefut az algoritmus 1-re?

Az algoritmus annyi, hogy ha a szám páros, akkor osztjuk 2-vel, ha páratlan, akkor meg szorzzuk 3-mal plusz 1, és innét megint előlről, amíg nem lesz az eredmény 1.

Általános iskolában találkoztam a problémával, egy jó fej matek tanárom volt, ő adott egy könyvet amiben benne volt. Most valahogy felmerült, mert láttam egy site-on BOINC-kel kapcsolatban.

Kíváncsi lennék van-e új eredmény? :)

Egy hasznos valós idejű hálózati elemző progira bukkantam: pktstat. Hasonló a Linux-os iftop-hoz és iptraf-hoz, csak ez áttekinthetőbb kimenetet ad nekem. tcpdump nem helyettesíthető, de ha egy gyors rálátás kell az interface-en átfolyó adatok irányáról és mennyiségéről, akkor jól jöhet.

Az új kapcsolatokat kiemeli vastaggal, és mutatja az aktív letöltéseket is GET-et jelölve. A '-t' opcióval top szerű üztemmódban mutatja bps szerint sorba rendezve a kimenetet.

FreeBSD-n megtalálható ports-ban és Debian-on is csomagban. Itt egy minta kimenet (az IP-k nem valósak):
[code]
pktstat -t -n -i eth0

Gyakran szükségem van arra, hogy a több helyen dinamikus IP címmel kapcsolódó notebook-oknak és más klienseknek be tudjam azonosítani az IP címüket ha nincs mód statikus beállításra, és így be tudjak lépni SSH-val, vagy VNC vagy akármivel, mert én is mindig máshol kapcsolódok a notimmal. Tegyük fel reverse kapcsolatra sincs praktikus lehetőség.

Írtam egy script-et, amely nmap-pel le-scan-neli a hálót, majd az arp táblából beazonosítja a MAC címekhez tartozó host neveket. Az nmap csak broadcast ping-et küld, tehát nem csinál port scan-t.

A kimenet egy normál 'arp -n' parancs kimenet, elején az IP címmel, a végén zárójelben a MAC-hez tartozó host névvel. Nem kell root jogosultság a futtatáshoz. A listát pedig bővítem folyamatosan a script elején.

A Debian Live Projekt kiadta pár napja a Debian soron következő 6-os, Squeeze kódnevű verziójára épülő live rendszerét. Bejelentés itt. Letöltés itt (i386) és itt (amd64).

Az image-ek ún. hybrid ISO-k, melyek dd-vel egyszerűen pendrive-ra másolhatók.

Egy build log hiba oka után kutatva véletlenül találtam erre az oldalra, ahol egy imho alapos és érdekes összehasonlításról található egy írás BSD és Linux szemszögéből, akár érdekelhet mást is:

http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php

Holnap péntek déltől 3 napig Árok Party Ajkarendeken.

Ma fedeztem fel egy hasznos bash beépített változót.

$_ a kiadott parancs paraméterei közül az utolsót tárolja mindig. Itt található egy bővebb leírás a "Special parameters" résznél.

tehát mappa létrehozásánál ha bele is szeretnénk lépni az új mappába, akkor elég ennyi, és nem kell újra gépelni mindig a path-t:

mkdir /home/user/akarmi
cd $_

vagy másik eset pl:

mv /ez/a/fajl/amit/masolok.txt /es/ide/masolom/eppen/ide/
cd $_

pv parancsot dd-hez szoktam használni folyamat jelzőnek:

dd if=/dev/sdx bs=1M | pv > hdd.img

Viszont nem tudtam, hogy gyakorlatilag cat parancsként funkcionál önmagában. Tehát az alábbi tömörítésnél:

gzip file

így is lehet:

pv file | gzip > file.gz

Így rendesen ki tudja írni a hátra lévő időt is. Ezen kívül semmit nem lassít a folyamaton.

A man doksinak az első példája egyébként hasonló, csak én nem olvastam..

dash-ben nincs $RANDOM változó.

Miért kell ennyire beújítani? Egy script-et írtam, ami megy Debian alatt, Ubuntu-n viszont nem. Kiderült nincs $RANDOM, mivel 9.10-en dash az alapértelmezett shell.

Ha valakinek kellene dash-hez:

RANDOM=`seq 0 32767 | shuf | head -n1`

Meg akartam nézni, hogy milyen egyéb fájlok vannak telepítve a rendszerembe, hogy ha a megjelenő 6-os verzióra frissítek, akkor átlássam hogy mit kell adot esetben újra fordítani, vagy ismét felrakni csomagból (ha már elérhető onnét is).

Egy nagyjáboli áttekintésre ad lehetőséget, hogy melyek a nem csomagok által létrehozott "idegen" fájlok. Nálam ilyen volt pl. az msn-pecan lib-je. (Leginkább a plusszként megjelenő futtatható binárisok és lib-ek az érdekesek, de így látszanak pl. az /etc-ben az eltávolított csomagok régi config fájljai is stb.).

Szerk.: a találatok leszűkítése érdekében érdemes lehet kivenni a .pyc-re végződő fájlokat is a listából.

http://android-dls.com/wiki/index.php?title=Compiling_for_Android

Régóta nem implementálják unzip parancsba a character kódolás támogatását, ami Linux-on pl. akkor gond, ha egy Windows-on készült ékezetes fájlneveket tartalmazó .zip-et kell kibontani, amelybe nem unicode-os fájlnevek kerülnek. 7zip esetenként elhasal, unzip pedig ugye a latin kódolás szerint hozza létre a unicode-os rendszeremen a fájlneveket.

Itt van egy szál arról, hogy létezik egy patch archlinux-on, amely egy -O és -I kapcsolót add hozzá be- és kimeneti karakter kódolás állításának lehetőségéhez.