Prin prisma experientelor din ultimele saptamani de cand mi-am tras IPv6 nativ acasa si il folosesc on a daily basis (spre deosebire de ultimii ani cand era doar ceva in plus pe un server), ma bate gandul sa ma apuc sa fac ceva ghid/howto/faq despre chestiile invatate, nu de alta, dar e o lipsa crasa de documentatie disponibila pe net, rfc-urile sunt ingrozitor de stufoase, iar in romana nu gasesti mai nimic. Btw, am inceput ceva pe wiki.lug.ro si vad ca mai apar contribuitori, dar pagina de acolo o sa fie mentinuta scurta si la obiect ca sa nu plictiseasca lumea.

Nu stiu inca cum o sa fac, fie ceva serial aici, fie pe wiki, fie altfel (de mult voiam sa-mi fac un soi de personal wiki, formatul de blog mi se pare cam aiurea), si inca nu-s mare specialist (de exemplu chestiunea care ma framanta acum e cum fortez reconfigurarea interfetei fara sa o restartez).

First things first: ceva sugestii cu ce sa incep?

Pe vremea cand se potcovea puricele cu 99 de oca la picior si invatam eu despre web, asta insemna CGI si presupunea sa iti scrii tu headerele HTTP si sa decodezi query-string si asa mai departe numai ca sa faci o singura pagina. Dupa aia au venit PHP dark ages unde nu mi-am facut problema sa scriu de la zero mai mult de 2-3 formulare si niste rapoarte.

Lately am inceput sa dau de frameworkurile astea post-web2.0 si gasesc o gramada de idei interesante. Recunosc ca nu m-am dat prea tare in vant nici dupa Ruby nici dupa Python, dar Rails, pe de o parte si specificatia WSGI, pe cealalta, fac totusi niste chestii dragute. Suficient de dragute astfel incat sa apara si in Perl niste module care sa promita zero-bullshit webapp development & deployment. unele chestii sunt suficient de cool ca am invatat sa ma joc cu ele practic peste noapte: Plack, Dancer, Mojolicious.

Partea frustranta e ca nu ma pricep sa fac design de aplicatii web. Nu, nu ma refer la designul vizual (stiu mai mult HTML si CSS decat mi-ar face vreodata placere sa recunosc iar nici la capitolul UI nu-s chiar nedus la scoala), ma refer la arhitectura. De exemplu cartile de Catalyst pe care le-am citit (care era copilul minune al Perl in materie de web frameworks pana anul trecut inainte de aparitia PSGI) pleaca de la premisa ca cititorul stie ce e aia MVC si mai ales cum sa-si muleze aplicatia pe patternul cu pricina. Eu sincer sa fiu n-am avut ocazia sa scriu cod in mediu asa structurat, iar problemele cu care am eu cel mai des de-a face (sa parsez, transform si editez datele altora) par a fi straine tuturor howto-urilor.

Si nu e doar problema de backend, ci si de interfata, mai exact cum imi fac layoutul url-urilor. REST e teh shit, foarte frumos, dar cum faci design la un API decent? Tot ce-am gasit pe net e un mare circlejerk cu design patterns si cu singletoane si factories si asa mai departe de ma face sa cred ca le-a luat tuturor Java mintile. Ma rog, so far am gasit ceva, dar e prea putin si se opreste imediat ce devine interesant.

Poate pls cineva sa-mi recomande ceva resurse (web sau print) care sa explice problemele astea asa mai ca pentru ingineri?

Ce-am facut: am aranjat sa servesc un "hello world" atat direct cu node.js, cat si via AtomWS (caruia a trebuit sa fac niste mici modificari sa mearga cu node 0.4.8 din Debian), si ca textfile din apache-ul instalat local, cat si ca aplicatie Plack pentru perl, servita fie cu HTTP::Server::PSGI, fie cu Twiggy (un webserver bazat pe AnyEvent). M-a batut gandul sa caut si chestii in Python sau Ruby (cu Tornado respectiv EventMachine), dar am decis ca ma pricep prea putin la astea anyway asa ca m-am oprit aici.

Concluziile au fost ca:

• apache se tine suficient de bine pe picioare (mi-a dat cei mai mici timpi de raspuns, nu reusesc sa-mi explic de ce), insa la concurenta mare tinde sa dea erori si ramane in urma fata de resul la numarul de requesturi pe secunda (in jur de 1000/s);
• HTTP::Server:PSGI nu imi da failed requests (desi la concurenta mare crapa ab-ul, poate e laptopul meu de vina), insa e destul de slow raspunsul si ca numar de requesturi pe secunda se invarte pe langa apache. De notat insa ca H::S::P e gandit doar pt. development si teste, nu pentru productie
• trecand in zona de event-based webservers, node.js e... interesant. Mi-a raspuns cu aceeasi frecventa indiferent de nivelul de concurenta. 10, 100, 1000, 2000 de requesturi simultane, el tot cam cu 6500/s raspundea, se constata doar o usoara crestere a imprastierii rezultatelor
• folosind AtomWS peste node.js, scade putin rata de raspuns undeva pana pe la 5000/s, curios insa ca se consolideaza rezultatele, sunt mult mai grupati timpii de raspuns decat la versiunea cu barebone node. Habar n-am ce inseamna asta;
• arma mea secreta, twiggy, s-a comportat foarte bine, scotand cam 3500 req/s si ma pregateam sa inchei acest articol pe o nota impaciuitoare pana mi-a dat prin cap sa ma uit pe plackperl.org dupa alte webservere, asa ca l-am gasit pe
• Feersum, bazat pe libev (la fel ca node.js), recomandat pentru situatii cu concurenta mare. Feersum a avut nesimtirea sa nu scoata mai putin de 10500 de requesturi pe secunda (concurenta mai mare de 2000 nu pot pe o singura masina din cauza de ulimit -n)

Poate o data reiau problema mai serios, similar cu nenea asta si fac si eu niste poze frumoase.

For now, pot dormi linistit stiind ca nu va trebui sa fac reconversie profesionala pe javascript (asa cum am scapat pana acum si fara sa invat prea mult Erlang).

La modul serios, pare foarte cool node.js si incepe sa-si justifice intrucatva hype-ul (asta fiind, by the way, singurul rezultat concret al testelor de mai sus).

Doi: m-am decis ca maine seara sa prezint ceva mai de incepatori (pentru ca trebuie sa recunosc, subiectele exotice ii lasa reci pe majoritatea). M-am hotarat sa zic doua vorbe despre awk (pentru ca ma intristeaza cand lumea il foloseste doar ca pe un soi de cut). Pana maine incropesc eu niste slide-uri, dar daca aveti sugestii let me know.

Of course, profit de ocazie sa va reamintesc ca aveti datorii morale fata de comunitatea asta (in general, nu la RLUG ma refer). Asa ca primul pas ar fi sa participati (la evenimentul asta daca vreti si puteti, sau la altul daca nu va place de noi din motive geografice, politice sau estetice).

Cum ai invatat astea? Poate partial la scoala (pe la Automatica se cam predau chestii de Linux, probabil si pe la alte facultati similare), dar majoritatea le-ai cautat de unul singur. Pe forumuri, liste de discutii, IRC, manpages, carti, cod sursa. Toate aceste chestii au fost scrise de voluntari (poate cu exceptia cartilor, dar din cate stiu autorii de carti nu prea fac profit, cel putin cea la care am fost coautor nu a facut). In orice caz, trebuie sa admiti ca, de bine de rau, datorezi o buna parte acunostintelor pe care le ai in acest domeniu unei intregi multimi de oameni care au sacrificat macar un dram de timp si efort pentru asta.

Eu unul imi datorez o foarte mare parte a cunostintelor in domeniu listelor lug.ro pe care activez de vreo 10-11 ani si prietenilor pe care mi i-am facut acolo, astfel incat de ceva vreme incerc sa-mi platesc datoriile morale contribuind la intretinerea serverelor pe care sunt listele si mirrorurile lug.ro, mai dau cu mailul pe liste din cand in cand, contribui cum pot la Prolinux (ong-ul care a fost creat in jurul listelor) si mai nou incerc sa ridic de la sol o serie de intalniri "real life" (despre care am mai mentionat).

Aici intervine apelul meu. Din toti care cititi asta, sunt convins ca o foarte buna parte e in stare sa ajunga cel putin o data la doua luni la aceste intalniri (sunt in seara fiecarei a doua joi din luna, in ultima vreme le-am tinut in incinta Facultatii de Automatica si Calculatoare, in Politehnica). Din acea foarte buna parte (mai bine de jumatate, I bet), fiecare poate sa zica ceva interesant. Da, si intrebarile se pun, nu doar prezentari ca la carte. Putem face o sesiune speciala de "intrebari de la nou-veniti" daca va deranjeaza statutul de prezentatori. Cu siguranta va fi in sala un newbie in domeniul respectiv caruia sa-i fie utile informatiile, asa cum si tie ti-a lamurit niste chestii o prezentare sau un mail sau un blog post al cuiva acum X ani.

Be that guy (or girl)! Pay it forward!

PS: daca sunteti atat de egoisti incat sa nu fiti miscati de argumentul asta, o sa fiu nevoit sa fac concurs cu premii

We tell people we use Linux because it's secure. Or because it's free, because it's customizable, because it's free (the other meaning), because it has excellent community support...

But all of that is just marketing bullshit. We tell that to non-Linuxers because they wouldn't understand the real reason. And when we say those false reasons enough, we might even start to believe them ourselves.

But deep underneath, the real reason remains.

We use Linux because it's fun.

It's fun to tinker with your system. It's fun to change all the settings, break the system, then have to go to recovery mode to repair it. It's fun to have over a hundred distros to choose from. It's fun to use the command line.

Let me say that again. It's fun to use the command line.

No wonder non-Linuxers wouldn't understand.

The point with Linux fans is we use Linux for its own sake. Sure, we like to get work done. Sure, we like to be secure from viruses. Sure, we like to save money. But those are only the side effects. What we really like is playing with the system, poking around, and discovering fascinating facts about the software that lies underneath it.

Cred ca am face bine cu totii sa constientizam ceva mai mult lucrurile astea

Din cauza ca simteam nevoia sa stric ceva si nu voiam sa pun pe altii sa munceasca, mi-am upgradat laptopul la Debian Testing (aka. Wheezy). De obicei stau pe testing pana la release, cand raman asa pe stable inca vreo luna doua sa se potoleasca apele.

A mers foarte smooth (cu exceptia prietenului meu network-manager care a decis sa o ia razna nitel, evident), ar mai fi un bug foarte haios cu driverul nouveau (dar stau pe nvidia non-free pana una alta). Singura problema care mi-a dat ceva batai de cap era procesorul care insista sa stea pe 800MHz, cea mai joasa frecventa disponibila.

Dupa multe cautari pe net se pare ca problema e ca nu-i place de adaptorul AC (iarasi, e al treilea adaptor pe care il stric) si bios-ul insista sa tina procesorul in 800 MHz pana imi iau carger sau baterie sau mai stiu eu ce de la Dell.

Solutia, pana una alta, a fost sa adaug ca parametru de kernel umatoarea treaba: "processor.ignore_ppc=1" (in Debian, l-am adaugat la GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.conf , YMMV), care din cate m-am prins ii spune kernelului sa nu ia in considerare plansetele biosului ref. la frecvente. Ramane de vazut daca imi strica . Hope this helps.

Planul de principiu e sa imi amintesc care anume din micile mele scamatorii zilnice de readline sau vim sunt remarcate de catre shoulder-surferii ocazionali, dar probabil n-or sa ajunga pentru ~45 min cat am alocat, asa ca fiti bineveniti sa-mi povestiti ce trickuri va fac lucrul in consola mai productiv.

Din cate stiu, evenimentul nu e public, dar probabil se va gasi iar cineva sadic sa ma filmeze si sa ma puna pe net. Ca atare, ma tot gandesc cum sa fac elegant sa alternez intre terminal si prezentare, as aprecia niste linkuri la prezentari cu fragmente interactive, sa pot fura meserie

Si ca sa fie putin mai competitiv, castigatorul cu cea mai interesanta sugestie va primi dreptul sa sustina un lightning talk de 5 minute despre un subiect OSS-related la urmatoarea intalnire RLUG (14 aprilie) si o bere (sau cola, suc de portocale, whatever) de la subsemnatul in seara aceleiasi zile

Pasul 0: sign up for EC2 la http://aws.amazon.com/ec2/ , enjoy the phone.

Pasul 1: Get the certificates. aws.amazon.com, sign it to aws console, account, security credentials, access credentials, x509 certificates, create new. Downloadeaza si cheia privata si certificatul. Fa un director ~/.ec2 in care sa le salvezi. Pentru siguranta, chmod -R go-rwx ~/.ec2 . (Atentie mare cu certificatul ala ca are acces direct la credit card ).

Pasul 2: Downloadeaza utilitarele de consola de ec2 de la http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip . Extrage bin si lib din el si muta-le in ~/.ec2. Daca n-ai sun-java6-jre, instaleaza-l.

Pasul 3: Environment-ul. Pune-ti undeva in ~/.bashrc sau unde iti pui variabile de mediu urmatoarele:

# environment variables for EC2
export EC2_HOME=~/.ec2
export PATH=$PATH:$EC2_HOME/bin
export EC2_PRIVATE_KEY=$EC2_HOME/pk-XXXXXXXXXXXXXXXXXXXXXXXX.pem
export EC2_CERT=$EC2_HOME/cert-XXXXXXXXXXXXXXXXXXXXXXXX.pem
export EC2_URL=https://ec2.eu-west-1.amazonaws.com
export JAVA_HOME=/usr/lib/jvm/java-6-sun

"XXX"-urile se inlocuiesc cu numele certificatului si cheii luate in pasul 1. De notat ca mi-am setat EC2_URL astfel incat daca nu specific regiunea sa foloseasca by default regiunea eu-west-1, unde prefer sa-mi fac instantele. In lipsa acestei variabile, va prefera ec2.amazonaws.com care este us-east-1. Diferentele probabil nu conteaza. JAVA_HOME trebuie setat daca nu l-a facut Java la instalare, trebuie sa dea in directorul care contine jre/bin/java.

Test time: Source the profile (sau deschide un terminal nou) si ruleaza 'ec2-describe-regions'. Daca nu merge, you skipped a step. Daca merge, trebuie sa apara o lista cu regiunile de ec2 (la ora actuala, 1 europa, 2 america si 2 asia). Da, e normal sa dureze >5s , get used to it

Pasul 4: Cheie de ssh.

ec2addkey RPETRE > ~/.ec2/RPETRE.pem
chmod 600 ~/.ec2/RPETRE.pem

(Ofc, in loc de RPETRE poti utiliza alt identificator al cheii).

Pasul 5: Pornirea unei instante noi.

Dat fiind ca Ubuntu de ceva vreme face release-uri si in cloud, am decis sama joc cu o imagine de la ei. La http://uec-images.ubuntu.com/releases/lucid/release/ sunt AMI-urile oficiale pentru 10.04 LTS, in toate regiunile, pe 32 si 64 biti. Eu am notat ami-311f2b45, varianta 32bit din eu-west-1. De notat ca AMI-urile nu sunt valide decat in regiunea aleasa via EC2_URL.

ec2-run-instances ami-311f2b45 --instance-type t1.micro -k RPETRE

Comanda de mai sus o sa returneze numele instantei (i-xxxxxx) si statusul "pending".

ec2-describe-instances i-xxxxxxx va returna starea instantei, dureaza cateva minute pana se transforma din "pending" in "running". Cand e "running", va avea un nume foarte lung, care se termina in compute.amazonaws.com. Ala e IP-ul pe care se poate face SSH. But first...

Editeaza ~/.ssh/config si adauga urmatorul paragraf:

host *.amazonaws.com
User root
StrictHostKeyChecking no
IdentityFile ~/.ec2/RPETRE.pem
UserKnownHostsFile ~/.ssh/ec2_hosts

Asta ca sa nu se planga la fiecare noua instanta ca n-a mai vazut-o si sa nu polueze known_hosts cu catralioanele de instante viitoare. Pentru cei paranoici care vor sa verifice fingerprintul cheii de ssh (bravo!), scoateti linia cu keycheck si tineti minte comanda ec2-get-console-output.

Ok, acum ar trebui ca ssh ubuntu@numefoartelungdeinstanta.compute.amazonaws.com sa mearga seamlessly (cu cheia cu care a fost creata instanta).

Cand te-ai plictisit de instanta, ruleaza ec2-terminate-instances i-xxxxxx si cateva minute mai tarziu o sa dispara. Atentie, billingul se face cu ora, incepand din momentul in care s-a lansat instanta, practic daca ii dai terminate in primele 55 de minute de cand ai pornit-o, ai de plata 2.5 centi, daca depasesti 60 de minute inca 2.5 centi, samd. (plus costul de bandwidth).

Mno, cam atat deocamdata. Daca ma mai joc, o sa mai pomenesc si despre security groups si load balancer, poate si despre storage.

Deocamdata nu am nici o idee de tema de discutie, please join in si propuneti una. Ne vedem acolo (or else!)