Pentru cei care au utilitarele flac (pentru codare/decodare de fluxuri în format flac) și lame (la fel, pentru mp3-uri), conversia flac-mp3 a fișierelor dintr-un director se poate face într-o linie de script bash, în felul următor (sursa):

for i in *.flac; do $(flac -cd “$i” | lame -h -b 320 – “${i%.flac}.mp3″); done

După cum se observă, toată linia este de fapt o buclă de tip for, care parcurge toate fișierele *.flac (cu extensia .flac) din directorul curent. Interiorul buclei apelează flac cu flag-urile -c (trimite ieșirea către stdout) și -d (face decodare). Ieșirea comenzii flac e preluată de lame, care face encoding în mp3: -h face encoding la calitate mare, iar -b 320 setează bitrate-ul la 320Kbps.

Output-ul lui lame este făcut în fișierul ${i%.flac}.mp3. Construcția ${i%.flac} îi spune shell-ului să facă expandarea variabilei i (care conține numele fișierului flac) și să caute și să elimine extensia .flac de la coada acesteia, dacă extensia există. Apoi este adăugată extensia .mp3 la coadă.

M-am conectat cu putty la server, sa vedem ce fisiere sunt in directoarele din casuta de email. Cand am ajuns in directoarele cur si new nu am putut lista continutul lor, din cauza numarului foarte mare de fisiere. Am incercat comanda “rm -r cur”, pentru a sterge continutul directorului cur, dar nu a mers.

Cautand o solutie pentru a sterge/lista treptat fisierele, m-am gandit sa ma leg de data la care au fost accesate ultima data fisierele.

Pentru a lista fisierele mai vechi de 90 de zile, din directorul cur am folosit comanda:

find cur -mtime +90 -print | xargs ls -d

Pentru a sterge fisierele mai vechi de x zile dintr-un director puteti folosi:

find $dirname -mtime $ndays -print | xargs rm

Unul din lucrurile cu care se laudă IDE-urile fancy (Visual Studio, Eclipse, Sun Studio, NetBeans și așa mai departe) e acela că ușurează extrem de mult munca prin salvarea unor informații legate de proiect, informații printre care se află și sesiunea/workspace-ul curent. În vim m-am confruntat deseori cu situația de a închide cinci sau mai multe tab-uri cu câte două split view-uri fiecare, pentru ca mai târziu să stau două-trei minute doar pentru a le deschide.

Totuși, până una alta, vim suportă, la fel ca orice editor/mediu de dezvoltare care se respectă, sesiuni. E de ajuns un

:mksession numesesiune.vim

pentru a salva sesiunea curentă.

Mai târziu, sesiunea poate fi reîncărcată rulând din bash:

$ vim -S numesesiune.vim

sau direct din editor:

:source numesesiune.vim

… all that awesomeness without the overhead.

Vorbeam ceva mai devreme de mici probleme legate de adaptorul wireless (un Broadcom 43xx, pe Dell Inspiron 1501). Din moment ce nu am putut rula deloc ndiswrapper de această dată, am decis să mai dau o şansă driver-ului nativ, care vede access point-urile şi se conectează fără probleme în această versiune (spre deosebire de 7.10). În schimb, mi s-a întâmplat de câteva ori să am rate de transfer foarte proaste.

Problema e legată cel mai probabil de un bug. Rulând iwconfig, am observat că îmi afişa o lăţime de bandă de 1Mb/s, adică foarte puţin. Se rezolvă uşor, rulând într-un terminal:

sudo iwconfig nume_wireless rate 54M

Unde “nume_wireless” este denumirea device-ului pe linux, iar parametrul “rate 54M” forţează folosirea unei benzi de 54Mb/s. Metoda în sine nu mi se pare foarte ortodoxă. Având în vedere că de cele mai multe ori wireless-ul se conectează la viteze acceptabile, nu recomand folosirea comenzii decât în caz de forţă majoră.

Una din chestiile deosebit de enervante de care m-am lovit când mi-am pus Ubuntu a fost prezenţa sunetului de PC Speaker (incredibil, unele laptop-uri au aşa ceva) în ecranul de login de la X11, în ciuda debifării opţiunii „enable system beep” din gnome. Jucându-mă cu diverse aplicaţii (mai exact alt window manager), am observat că ele pot introduce acel beep şi în cadrul textbox-urilor, astfel că dacă apăsam backspace sau săgeţile într-un textbox gol, speaker-ul începea să urle, lucru cam neplăcut la 1 noaptea, când lumea vrea să doarmă. După o şedinţă serioasă de google, am ajuns la o concluzie.

În principiu, există două variante de a scoate la capăt problema:

1.Se pare că system-wide, pc speaker-ul e activat de un modul de kernel numit pcspkr. Cu alte cuvinte, un sudo rmmod pcspkr rezolvă problema. Mai mult, încărcarea modulului odată cu startarea sistemului poate fi oprită prin editarea fişierului /etc/modprobe.d/blacklist, în care se adaugă linia:

blacklist pcspkr

2.O metodă alternativă ar fi dată de comenzile:

xset b off
xset b 0 0 0

Cele două comenzi sunt strâns legate de serverul X11, deci trebuie adăugate într-un fişier xinitrc, eventual la sfârşitul fişierului /etc/X11/xinit/xinitrc.

Personal, recomand prima variantă, deoarece e o metodă cât de cât ortodoxă de a înlătura problema. Cu toate astea, în cazul meu şi a doua funcţionează la fel de bine. Pentru cei care au dat peste problema respectivă pe Windoză, le recomand acest tutorial. Pentru cei care caută chiar mai multe metode pe Linux, forumul Ubuntu găzduieşte o discuţie detaliată pe tema asta.

Să presupunem că $client_ip dorește să acceseze $external_ip – sau un nume de domeniu asociat IP-ului, pe care îl vom nota cu $nume_domeniu – pe portul 80. Ce se va întâmpla în acel moment? Dacă router-ul dispune de NAT Loopback (și are facilitatea activată), atunci el va face forwardarea din interior către $server_ip, interpretarea acestuia fiind „$client_ip, deși este din interiorul rețelei, vrea să acceseze server-ul intern ca și cum s-ar fi conectat din exteriorul rețelei”. În caz contrar, router-ul nu va face forwardarea, ci va răspunde la fel ca în cazul în care este accesat pe $router_ip:80, deci va interpreta cererea astfel: „$client_ip dorește să se conecteze la mine pe portul 80”.

Anumite routere, cum ar fi modelele WRT54G de la Linksys pot să facă NAT Loopback (eventual cu firmware-ul DD-WRT instalat). Alte routere/modem-uri fac asta implicit (fără ca utilizatorul să poată specifica alt comportament), iar altele nu știu deloc să facă NAT Loopback, de exemplu modem-urile VDSL de la Romtelecom (de acestea din urmă lovindu-se subsemnatul). Există câteva workaround-uri posibile pentru ca un site din rețeaua internă să poată fi accesat :

1. Modificarea fișierului “hosts”: soluție viabilă pentru un server care nu găzduiește un număr mare de domenii și pentru o rețea cu un număr mic și fix de calculatoare (Atenție! Pentru clienți interni mobili: laptop-uri, netbook-uri etc., soluția poate cauza probleme la conectarea ulterioară din exterior). Pe mașina (sau mașinile, presupunând că sunt mai multe) client, în /etc/hosts (diverse variante Unix) sau în windows\system32\drivers\hosts se va seta un alias de forma:

   $server_ip $nume_domeniu

   Unde $nume_domeniu este numele domeniului pe care dorim să îl accesăm. Se va adăuga câte un astfel de alias pentru fiecare domeniu hostat de către mașina server.

2. Configurarea unui server DNS, soluție destul de complicată încât să nu o explic aici. Pe scurt, se poate configura un server de nume special pentru rețeaua internă, care să directeze cererile pentru domeniile locale către $server_ip și să rezolve celelalte cereri normal. Pentru asta însă, toate mașinile din rețeaua internă trebuie configurate în așa fel încât să rezolve toate cererile NS prin acel server.
3. (pentru modem-uri) Configurarea în bridge cu un router capabil de NAT Loopback sau (pentru routere) înlocuirea cu un router capabil de NAT Loopback. Totuși, dacă soluția asta ar fi fost așa simplă, nu începeam articolul de față.
4. (pentru routere/modem-uri cu Linux/Unix și iptables) Configurarea iptables în interfața router-ului: soluția la care a recurs subsemnatul, asta fiindcă, pur întâmplător, modem-ul Romtelecom are un firmware bazat pe Busybox, un distro de linux pentru dispozitive embedded, accesibil prin telnet. În acest caz, documentația iptables menționează o metodă interesantă de configurare a NAT-ului (pentru versiunea 2.4 a kernel-ului de linux, dar aparent funcționează și pe 2.6): se face forwardarea prin NAT a tuturor cererilor venite din rețeaua internă către $server_ip prin modificarea în chain-ul PREROUTING a adresei destinație și, pentru ca pachetele să știe pe unde să se întoarcă, schimbarea în POSTROUTING a adresei sursă (inițial $client_ip) cu adresa router-ului. Cel puțin teoretic, router-ul ar trebui să știe să intermedieze conexiunea între client-ul intern și server. În mai puține cuvinte, comenzile de iptables sunt:

   $ iptables -t nat -A PREROUTING -d $external_ip -p tcp --dport 80 -j DNAT --to $server_ip
   $ iptables -t nat -A POSTROUTING -d $server_ip -s 192.168.0.0/24 -p tcp --dport 80 \
    -j SNAT --to $router_ip #se inlocuieste 192.168.0.0/24 in functie de retea

Primele două metode scot complet router-ul din ecuație. Astfel, dacă se întâmplă să schimbăm router-ul cu altul, această modificare nu ar trebui să afecteze cu nimic configurația creată anterior. A treia metodă e cea mai radicală, rezolvă cele mai multe probleme, dar este și cea mai scumpă.

Ultima metodă ar trebui să transforme router-ul nostru problemă într-unul capabil să facă NAT Loopback. Singura mare problemă este aceea că cele două comenzi nu sunt persistente. La fiecare restartare a router-ului, trebuie să ne conectăm prin telnet la acesta și să dăm copy/paste la cele două comenzi, fapt ce poate deveni destul de iritant la un moment dat (ce ne facem dacă suntem în concediu și colegii vor să acceseze un site de pe server-ul intern?).

În partea a doua a tutorial-ului vom discuta despre automatizarea task-ului de updatare a tabelei de NAT pe un modem/router cu Busybox (aceasta putându-se generaliza și pentru alte distribuții de Linux).