Codul tău e de nimic și te urăsc

Articol original: jml.io

Dinamica Socială a Recenziilor de Cod

Jonathan Lange, septembrie 15, 2008

Citiți traducerea în ucraineană (mulțumesc Alyona Lompar!)

Acest articol e tradus în limba rusă de către Ivanka de la Coupofy.com

Rezumat

Recenziile de cod pot fi minunate, de mare folos, dar și incredibil de descurajatoare. Acest articol examinează cum puteți scrie recenzii de cod pentru proiectele dumneavoastră fără a vă fi provocate instinctele din categoria ”luptă sau fugi”.

Vom examina rapid de ce ar trebui să scriem recenzii de cod ca mai apoi să ne focusăm pe dinamica socială a procesului de evaluare a codului, în special în ceea ce ține de proiectele cu sursă deschisă. Într-o anumită măsură, ceea ce face codul cu sursă deschisă atât de grozav (iar uneori intimidant!) este că acesta poate ajunge în vizorul experților din întreaga lume.

Examinăm aici efectele pe care le pot avea diverse tehnologii asupra culturii de recenzare a codului, ce se poate obține de fapt prin recenzii, cum au loc recenziile în alte discipline. La fel, evidențiem unele capcane în care e foarte simplu de căzut.

Introducere

Recenziile de cod sunt cu noi deja de mult timp, fiind parte a mișcării pentru Software Liber de la bun început: cel puțin sub forma celor cu drepturi de commit revizuind patch-uri ale celor lipsiți de acest privilegiu.

În ultimii ani, recenziile de cod au căpătat o nouă importanță. Programarea Extremă a promovat ideea programării în pereche (o modalitate de recenzie continuă a codului)  și multe proiecte cu sursă deschisă acum necesită ca toate patch-urile să fie verificate, indiferent de nivelul de profesionalism al autorului.

Fiecare din aceste proiecte au abordări diferite față de recenzie: diferite instrumente, diferite procese și diferite scopuri, ceea ce duce la un grad diferit de presiune asupra comunităților de dezvoltatori de software.

Acest articol explorează deciziile pe care aceste proiecte le-au luat și presiunile sociale și stimulentele care rezultă din aceste decizii. Articolul la fel identifică potențiale probleme în procesul de recenzie și oferă sugestii pentru evitarea acestor probleme. Acest text nu este conceput ca un studiu academic riguros; mai curând e o colecție de opinii bine gândite  menite să ducă la alte reflecții, cercetări și experimentare.

Ce este o recenzie de cod?

În termeni foarte simpli, o recenzie de cod este ceea ce se întâmplă când cineva examinează codul și face comentarii în privința acestuia.

Acest articol se focusează pe recenziilepre-merge” (în traducere: ”pre-contopire”) – recenziile cărora sunt supuse patch-urile înainte de a ajunge la etapa principală de dezvoltare. Procedura clasică în cazul dezvoltării Software-lui Liber arată astfel: un dezvoltator nou trimite un patch pe o listă de adrese electronice. În unele proiecte, procesul de recenzare pre-merge continuă chiar și pentru dezvoltatori experimentați (spre exemplu, Twisted, Bazaar, Linux).

Există așa chestie ca recenzii post-merge (în traducere: ”post-contopire”). Acestea au loc frecvent în proiectele de tip Software Liber când cineva include un commit suspect în trunk. În general, recenzentul răspunde la notificarea asociată cu respectivul commit și evidențiază eroarea.

Recenziile pot fi efectuate și ca un fel de inspecție aleatoare. Ca parte a acestei abordări, un programator senior inspectează o parte anume a bazei curente de coduri și lasă comentarii despre structura și calitatea ei.

Unele recenzii sunt involuntare. Acestea tind să fie generate noaptea târziu, când un programator descifrează codul într-un colț obscur al proiectului, posibil încercând să repare o eroare. Aceste recenzii de cod sunt deseori caracterizate de un limbaj grosolan, comentarii furioase și nu sunt în genere de ajutor autorului original, care s-ar putea în genere să nu le vadă niciodată.

Ce pot realiza recenziile?

Pentru unii oameni, recenziile de cod fac parte din aceeași categorie ca și documentația, dezvoltarea bazată pe testare și tărâțele: lucruri bune dar plictisitoare cu care ne răsfățăm mai rar decât ar trebui s-o facem.

Spre deosebire de cerealele bogate în fibre, recenziile de cod pot avea beneficii diverse dar deseori concurente. În procesul recenzării în cadrul unui proiect, este important să evaluăm care dintre aceste beneficii contează cu adevărat.

Impunerea conformității

Recenziile de cod sunt importante pentru a ne asigura că tot codul sursă arată la fel. Aceasta include convențiile de denumire, ortografie corectă în comentarii și utilizarea consecventă a API-urilor interne.

Asigurarea calității

Recenzarea codului în prealabil oferă șansa de a depista erorile înainte ca acestea să înceapă a afecta utilizatorii. Un recenzent este mult mai distanțat emoțional față de cod ceea ce-l face să fie mai critic în evaluarea acestuia, iar aceasta, la rândul ei, duce la o probabilitate mai mare de depistarea a erorilor.

Sporirea clarității

Dacă o bucată de cod a fost evaluată de altcineva, atunci există cel puțin doi oameni în această lume care sunt în stare să o înțeleagă.

Un recenzent este mai distanțat de acest cod inclusiv din punct de vedere intelectual și prin urmare, poate identifica presupunerile ascunse și deciziile neclare.

O bază de coduri cu un nivel înalt de claritate permite celor proaspăt veniți să înceapă a contribui în mod rapid, ceea ce este îndeosebi de important pentru proiectele cu sursă deschisă, care se bazează în mod exclusiv pe efortul voluntarilor.

Educarea recenzenților

Dacă tot codul trebuie evaluat, atunci fiecare patch oferă o șansă de a învăța despre o parte a bazei de coduri pe care recenzentul nu o mai văzuse înainte. Aceasta înseamnă că un proces de recenzie poate fi exploatat pentru a face schimb de cunoștințe despre baza de coduri în interiorul unei comunități.

Evaluarea codului de către o pereche de ochi neimplicată anterior poate fi o binecuvântare incertă: uneori va duce la mult mai multă claritate, iar alteori va rezulta în recenzii superficiale.

Balansarea priorităților

Întrucât dezvoltatorii unui proiect deseori au diferite priorități, recenzentul deseori va avea priorități diferite de cele ale autorului. Cineva poate adăuga un patch care îmbunătățește performanța unui API central, ca mai apoi să fie nevoit să justifice de ce acest lucru e mai important decât păstrarea compatibilității inverse. Recenzia de cod forțează această discuție să aibă loc înainte ca schimbările să fie introduse în trunk.

Educarea unor programatori mai buni

O recenzie de către un programator reprezintă o oportunitate pentru a face o mică incursiune în modul de gândire al acestui programator, iar expunerea îndelungată la modul de gândire al altor programatori extinde și dezvoltă propria gândire. Recenzenții pot sugera tehnici despre care autorii nu au mai auzit înainte. Ei pot acorda întrebări la care autorul nu s-a gândit niciodată. Ei pot indica o cale mai simplă pe care autorul a omis-o.

Pe de altă parte, procesul de recenzare a codului îl impune pe recenzent să clarifice ce reprezintă exact un cod bun.

Sumar

Dinamica recenziilor de cod va varia în dependență de care dintre aceste scopuri are cea mai mare importanță. Dacă recenziile sunt în mare parte orientate spre asigurarea calității codului, atunci recenziile vor lua mai mult timp și vor fi mai minuțioase, întrucât recenzenții vor încerca să identifice erori, probleme de performanță, etc. Dacă recenziile sunt orientate în mod primar spre sporirea clarității, atunci recenziile for fi mai scurte, vor pune mai multe întrebări și vor tinde să presupună că patch-ul este bine testat și bine motivat.

Deciziile

Există niște întrebări importante care necesită un răspuns atunci când se stabilește un proces de recenzare. Aici, examinăm unele dintre aceste întrebări și vedem ce răspunsuri oferă la ele proiectele Bazaar, Launchpad și Twisted.

Cine sunt recenzenții?

Probabil cea mai importantă întrebare la care trebuie să răspundă un proiect este ”Cine sunt recenzenții?” În majoritatea proiectelor cu sursă deschisă, recenzenții sunt atrași din comunitatea celor care au contribuit cel mai mult, deși mecanismul exact variază.

Patch-urile la proiectul Bazaar trebuie aprobate de către doi dezvoltatori de bază, definiți ca oamenii care pot plasa aceste patch-uri în trunk. Aceasta asigură că fiecare patch este evaluat de către cineva cu expertiză și la fel asigură un nivel de comunicare de bază între dezvoltatori.

Launchpad are o echipa de recenzenți care este o subdiviziune a echipei generale de dezvoltare a Launchpad. Echipa de recenzie vrea ca toți dezvoltatorii să fie recenzenți, dar are și un proces prin care dezvoltatorii trebuie să fie ”tutelați” înainte de a deveni recenzenți cu drepturi depline. Procesul de ”tutelare” asigură că recenzenții proaspeți au pe cineva la care să se adreseze atunci când nu sunt siguri și că prioritățile de recenzare ale Launchpad (claritatea codului, asigurarea unui proces rapid de recenzare) sunt respectate de toți recenzenții.

Twisted permite oricui să lase recenzii atâta timp cât persoana nu a fost implicată în scrierea patch-ului. Această idee destul de ingenioasă împiedică fenomenul de ”gândire de grup” care ar putea avea loc între autor și recenzent. Dezavantajul acestei abordări este că există o diferență enormă între recenzenți. În plus, când recenziile sunt sarcina fiecăruia, ele în scurt timp devin sarcina nimănui.

Care forum?

Twisted efectuează recenziile de cod utilizând tichete de eroare. Bazaar efectuează recenziile prin intermediul unei liste de adrese electronice. Launchpad face recenziile prin intermediul unei liste de adrese electronice separate dedicate doar pentru recenzenți.

Abordarea adoptată de Twisted este un exemplu al UQDS (“Ultimate Quality Development System”). Recenziile sunt înfăptuite prin utilizarea unor tichete, astfel că pagina web asociată cu tichetul devine autoritatea canonică pentru toată informația despre o anumită corecție de eroare sau despre un anumit element funcțional adăugat. Astfel, pe lângă faptul că informația relevantă este adunată într-un singur loc, se evită discuțiile ineficiente și dezbaterile înverșunate cu participarea oamenilor care nu sunt implicați cu adevărat. Acest beneficiu vine cu un dezavantaj la fel de important: recenziile sunt rareori citite de către altcineva decât autorul patch-ului, ceea ce facilitează aplicarea diferitor standarde de către diferiți recenzenți. Dacă recenzia abordează întrebări importante, acestea sunt greu de adus în atenția unei comunității mai vaste. Regretabilul sistem de poștă electronică al Trac face dificilă urmărirea unei discuții.

Bazaar trimite recenziile pe lista generală de adrese electronice, suplimentat cu un instrument special adaptat de monitorizare a patch-urilor denumit Bundle Buggy. Întrucât atât recenziile cât și patch-urile sunt trimise tuturor dezvoltatorilor prin email, discutarea patch-urilor tinde să fie mult mai deschisă decât în cazul Twisted. Numărul mare de patch-uri face mai dificilă urmărirea corespondenței electronice și se întâmplă destul des ca firul discuției în legătură cu o recenzie anume să se transforme într-o conversație lungă și întortocheată.

Lista separată de adrese electronice a Launchpad facilitează filtrarea conversațiilor generale legate de dezvoltarea de software de cele asociate cu recenziile de cod, asta în timp ce permite părților terțe să urmărească recenziile altor persoane. În practică, aceasta înseamnă că Launchpad preia din avantajele și dezavantajele ambelor abordări.

În timp real sau offline?

Efectuarea recenziilor de cod în mod asincronic diferă foarte mult de efectuarea recenziilor în timp real.

În cadrul recenziilor de cod asincronice, așa ca cele efectuate prin email, recenzentul are timp să formuleze comentariile în mod diplomatic. În mod similar, autorul este în stare să răspundă la fiecare item în ordinea în care consideră de cuviință.

Recenziile de cod în timp real posedă toate avantajele și dezavantajele unei conversații naturale: neînțelegerile pot fi identificate și corectate în mod rapid; nu trebuie de așteptat mult timp răspunsul celeilalte părți. Desigur, discuția riscă mult mai mult să devină aprinsă, fiind mai dificilă separarea emoțiilor de fapte. La fel, este mai dificil să-ți dai seama când a luat sfârșit. Când primiți un email cu o recenzie a codului, puteți evalua imediat volumul conținutului din acel email, pe când conversațiile în timp real nu oferă în prealabil o delimitare clară a timpului care necesită a fi investit.

Cine soluționează disputele?

Există momente când autorul crede una despre patch, iar recenzentul crede cu totul altceva și nici un volum de argumente din partea ambelor părți nu pare să ducă la o opinie convergentă. Spre exemplu, într-un patch, autorul a considerat că:

  [item] = singleton_list

reprezintă un procedeu clar de obținere a singurei valori dintr-o listă care are în mod garantat o singură valoare. Recenzentul a considerat că acest procedeu nu este clar și a sugerat:

 assert len(singleton_list) == 1, \ “List should have only one value: %r” % (singleton_list,) item = singleton_list[0]

În pofida argumentelor convingătoare ale ambelor părți, nici una nu e dispusă să cadă de acord. Ce e de făcut? Cine rezolvă disputa?

Bazaar adoptă poziția că autorul patch-ului are ultimul cuvânt în subiectele aflate în dispută. Twisted zice că recenzentul are ultimul cuvânt, iar Launchpad are un recenzent superior care are un vot decisiv în astfel de situații.

Dacă autorul are ultimul cuvânt, rata dezvoltării va fi mai rapidă în detrimentul uniformității și posibil al calității. Dacă recenzentul are ultimul cuvânt, patch-urile vor fi finalizate mai lent, (recenzentul niciodată nu este la fel de interesat ca autorul ca aceasta să se întâmple), în schimb vor fi verificate mai riguros.

Lucruri proaste

Ad hominem

Aceasta ar trebui să fie de la sine înțeles: efectuați recenzia codului, nu a autorului. Comentariile la adresa persoanei doar vor îngreuna pentru ea aplicarea în practică a criticilor în adresa codului său.

Când lăsați comentarii negative, referiți-vă la ”patch” sau ”ramură”, nu la om. Spre exemplu, ”Ai introdus o eroare în get_message” devine “acest patch introduce o eroare în get_message”.

Așteptări Neclare

Dacă tot ce spuneți este ”acest patch introduce o eroare în get_message”, atunci ați eșuat ca recenzent. Scopul este să îmbunătățiți codul, nu să oferiți o serie de ghicitori autorului.

În urma citirii recenziei, autorul urmează să fie în stare să înțeleagă cum să abordeze fiecare item și să știe când a soluționat toți itemii. Recenziile fără așteptări clare devin discuții neterminate despre patch, ceea ce uneori are mai curând scopul de a satisface recenzentul decât cel de a îmbunătăți codul.

Confundarea preferințelor personale cu valoarea obiectivă

Aceasta este o problemă valabilă pentru toate tipurile de recenzii. Criticii de film, editorii literari, recenzenții academici – toți cad pradă acestui fenomen.  ”Ceea ce-mi place mie” nu este în mod necesar echivalent cu ”ceea ce e bine”, deși, în parte, a deveni un programator mai bun înseamnă a-ți alinia mai bine preferințele cu realitatea. ”Ceea ce nu-mi place” are probabil încă mai puține șanse să însemne ”ceea ce e rău”.

Când revizuiți un patch perfect acceptabil care rezolvă o problemă folosind programarea în stil imperativ, nu criticați doar din cauza că nu este într-un stil mai funcțional. Dacă o faceți, transformați procesul de recenzie într-un joc dea ”ghici ce îi place recenzentului” în loc de ”scrie un cod bun”.

Recenzenții pot evita această capcană formulând comentariile de recenzie ca întrebări: ”Ai luat în considerare utilizarea unui stil mai funcțional?”, ”De ce nu folosești expresii regulate pentru a rezolva această problemă?”, etc.

Vezi la fel ”Un feedback specific este un feedback bun”.

Dacă tot sunteți acolo…

Când evaluați codul, este tentant să cereți autorului să repare alte probleme care se regăsesc în aceeași porțiune de cod. Dacă nu aveți grijă, totul poate evolua rapid într-un exercițiu de transformare a acestei porțiuni de cod în una perfectă, luând în considerare că inițial, atât autorul cât și recenzentul voiau doar să îmbunătățească un pic codul.

Soluția în cazul dat este să apreciați obiectiv măsurile de îmbunătățire pas cu pas (vedeți, ”Mai bine este mai bine, perfect este imposibil”).

Obstrucționism

Cuvântul englez ”Filibustering” este un termen politic American care se referă la prelungirea fără capăt a dezbaterilor în legătură cu un proiect de lege pentru a împiedica adoptarea acelui proiect de lege. Fenomenul are loc uneori în cadrul proiectelor Software Liber, pentru împiedicarea implementării anumitor patch-uri.

Uneori, efectele de obstrucționare pot avea loc involuntar. Un recenzent respinge un patch pentru că nu prevede teste unitare, autorul întreabă ”cum pot face testare unitară pentru acest cod?”, iar recenzentul nu mai apare să răspundă la întrebare.

Pe lângă faptul că este un proces neplăcut, autorul este lăsat cu o ”temă pentru acasă” în așteptare, ceea ce îl încetinește în procesul de elaborare a patch-urilor.

Vezi, ”Așteptări neclare” și ”Un feedback rapid este un feedback bun”

Lucruri bune

Un Feedback specific este un feedback bun

Indicați linia exactă a codului care ar putea fi îmbunătățită. Spuneți clar ce nu este în regulă cu ea. Sugerați o modalitate prin care se poate de îmbunătățit. Asigurați-vă că autorul își va da seama când problema va fi rezolvată.

Un feedback rapid este un feedback bun

Odată ce autorii prezintă patch-urile pentru recenzie, aceștia nu mai pot face nimic atâta timp cât recenzentul nu răspunde. Efectuați recenziile operativ pentru a nu permite ca atenția autorilor să devieze prea mult.

Mai bine este mai bine, perfect este imposibil

Niciun patch nu va fi perfect și niciun patch nu va repara toate problemele existente într-un cod. Nu tindeți spre perfecțiune ci spre îmbunătățiri graduale (pas cu pas).

Fiți recunoscători

Cineva tocmai a încercat să vă îmbunătățească produsul, investind resurse cognitive, efort și creativitate pentru a vă ajuta, iar acum au expus rezultatul muncii lor pentru critici.  Mulțumiți-le!

Divmod are o politică de a spune mereu un lucru bun în fiecare recenzie de cod. Întotdeauna se găsește ceva bun de spus, chiar dacă acel ceva este ”Sunt bucuros că cineva examinează această porțiune de cod”.

Puneți întrebări

Recenzenții nu pot greși punând întrebări. În cel mai rău caz, autorul va veni cu un răspuns evident. În cel mai bun caz, atât autorul cât și recenzentul vor învăța ceva nou.

Concluzie

Recenziile de cod oferă o oportunitate minunată de a evolua ca programator și de a îmbunătăți software-ul pe care îl scriem. Există multe alegeri pe care un proiect le poate face în ceea ce privește modul în care se efectuează recenziile și ce pot obține acestea. Reflectând cu grijă la modul în care tehnologiile și procesele afectează interacțiunile de bază dintre oameni în cadrul procesului de recenzie, proiectele cu sursă deschisă pot evita capcanele care-i sperie pe începători sau care îi demoralizează pe cei ce contribuie de ani buni și pot în schimb să se focuseze pe construirea celui mai bun software posibil.

Lecturi Suplimentare

Acest eseu e făcut disponibil sub licența Creative Commons Sharealike Attribution CC-BY-SA.

Nuggeturile lui Noel

Articol original: enete.com

Nuggeturile sunt niște exemple scurte și clare care vă oferă ceva care funcționează ajutându-vă să lucrați mai rapid. Aceste nuggeturi au fost asamblate într-un arbore de pagini web pentru acces mai rapid și convenabil.

Nuggeturi pentru Java

Aceasta este o colecție de exemple simple în Java împreună cu explicațiile de rigoare.

Instalarea: Creați un director (folder) cu numele \java dacă e vorba de Windows sau ~/java dacă e vorba de Linux și dezarhivați acest fișier în el. Odată cu dezarhivarea, are loc crearea directorului javanuggets și plasarea arborelului de fișiere și exemple html înăuntru. Direcționați navigatorul web către javanuggets\index.html pentru a explora conținutul.


Nuggeturi pentru Jini

Aceasta este o colecție de exemple simple pentru Jini împreună cu explicațiile ce le însoțesc.

Instalarea: Creați un director denumit c:\sun\jini și dezarhivați acest fișier zip în el. Va fi creat următorul subdirector c:\sun\jini\nuggets care va conține pagini web și exemple. Pentru un tur ghidat, direcționați navigatorul web spre c:\sun\jini\nuggets\index.html.


Nuggeturi pentru Quicktime

Aceasta este o colecție de exemple și explicații care oferă programatorilor o modalitate rapidă de a începe a programa în Quicktime. Exemplele sunt în OSX/C, OSX/Java, și Windows/C.

Instalare: Dezarhivați și accesați fișierul nuggets_quicktime/index.html cu ajutorul navigatorului web.


Nuggeturi din Biblie

Aici găsiți o colecție de reflecții scurte și abilități simple de studiere a Bibliei pentru a vă ajuta să creșteți în relația dumneavoastră cu Domnul.

Instalarea: Acesta este un fișier care se dezarhivează în mod automat. Descărcați fișierul biblenuggets.exe și porniți-l. Va avea loc crearea directorului biblenuggets și toate paginile web și aplicațiile vor fi plasate înăuntru. Accesați fișierul biblenuggets\index.html prin intermediul navigatorului web.

CE ESTE GEOSTATISTICA?

Această pagină web este menținută de Donald E. Myers


Articol original u.arizona.edu

Nu trebuie să fim statisticieni ca să folosim geostatistica cu cap, dar s-ar putea să avem nevoie de asistența, suportul, îndrumarea unui (geo?)statistician. Un bun inginer, ecolog, biolog, specialist în știința plantelor, hidrolog, pedolog are deja o bază bună, pentru că geostatistica nu este altceva decât știință de calitate adaptată conștientizării faptului că fenomenele naturale sunt supuse variației în spațiu. Studiul geostatisticii nu înlocuiește alte cunoștințe pe care le posedăm, ba chiar dimpotrivă –extinde cunoștințele deja acumulate și le face mai utile.

(parafrazat dintr-un citat de William Edwards Deming)


PUȚINĂ ISTORIE

Aplicarea statisticii în probleme ce țin de geologie și minerit  dar și hidrologie datează cu mult timp în urmă. Pentru un timp, geostatistica însemna statistica aplicată în geologie sau probabil, în mod mai general, în probleme ce țin de științele Pământului. Începând cu mijlocul anilor 60 și în special în mijlocul anilor 70, a devenit mult mai direct asociată cu lucrările lui Georges Matheron și probabil, această conexiune este cea care prevalează și astăzi. Întrucât majoritatea lucrărilor sale timpurii și cele ale discipolilor săi au fost scrise în mod principal în franceză, nu au ajuns să fie cunoscute prea bine în SUA și alte țări. Mai multe evenimente, însă, au început să schimbe această situație. În 1975 o întrunire NATO ASI (Advanced Study Institute) a avut loc lângă Roma, Italia cu genericul Geostatistică Avansată în Industria Mineritului. Lucrările prezentate la această conferință conțineau articole predominant în Engleză. Evenimentul dat a fost precedat de o serie de notițe (aparținând lui Matheron) pregătite pentru un program de vară în Fontainebleau. Aceste notițe, deși în engleză, nu erau ușor accesibile. Un articol teoretic mai definitiv a apărut în J. Applied Probability în 1973.

Profesorul Matheron activa la Ecole Normale Superieure des Mines de Paris (Școala Mineritului), una din Grande Ecoles. Ca parte a unui curent general de relocare a unităților de cercetare din locația principală din Paris (adiacent la Jardin du Luxembourg), Matheron a fondat Centre de Morphologie Mathematique (Centrul de Morfologie Matematică).  Mai târziu au fost inițiate două programe de studiu aici, unul în morfologie matematică iar altul în geostatistică. Matheron s-a pensionat ca Director al Centrului doar anul trecut. Seria din două volume ale lui Jean Serra despre morfologia matematică și analiza imaginilor este binecunoscută și bazată pe o carte despre teoria seturilor aleatorii scrisă ceva mai devreme de Matheron. Doi dintre studenții lui Matheron au jucat un rol instrumental în implantarea geostatisticii în America de Nord. Andre Journel s-a mutat la Universitatea Stanford în 1978 și a fost coautorul la Mining Geostatistics (Geostatistica Mineritului) împreună cu Ch. Huijbrechts. Michel David s-a mutat mai devreme la Ecole Polytechnique in Montreal și în 1977, a publicat Geostatistical Ore Reserve Estimation (Estimarea Geostatistică a Rezervelor de Minereuri). Journel lucra la Facultatea de Științe ale Pământului Aplicate, dar mai recent, această facultate a fost desființată, așa că el activează acum la Facultatea Ingineriei Petroliere și a fondat (cu ajutorul mai multor companii petroliere) Centrul Stanford pentru Prezicerea Rezervoarelor.

Lucrările lui Matheron nu au fost acceptate prea bine în comunitatea statistică pentru o perioadă de timp, deși un număr de statisticieni de vază vizitau Fountainebleau în anii 70, 80 și 90. Parțial, era din cauza unei percepții că parte din aceste lucrări dublau rezultate care erau deja binecunoscute dar sub alte nume de autori. Predispoziția lui Matheron de a publica doar în Franceză și doar în cadrul ”notelor interne” din cadrul Centrului probabil a contribuit la această percepție. Acum însă, geostatistica și-a revendicat un loc clar atât în cadrul revistelor de statistică cât și la întâlnirile naționale. În mijlocul anilor 80, cu ajutorul lui M. Armstrong, o listă a acelor notițe a fost publicată în Mathematical Geology (Geologia Matematică) – chiar dacă era posibil de solicitat fotocopii din Centru, nu exista un registru al acestor informații în afara sa. Lista menționată aici este deja foarte învechită. Iarăși, cu ajutorul lui M. Armstrong, o parte mică din aceste notițe au fost publicate ca articole științifice GLOSAR.

Software

La sfârșitul anilor 70, Centre de Geostatistique, Fountainebleau a inițiat un program de masterat în geostatistică (doi ani) care a atras un flux constant de studenți din industrie și guvern din diferite țări. În colaborare cu Shell Oil și Bureau de Recherche Geologie Mathematique (varianta franceză a USGS – United States Geological Survey), a fost dezvoltat un program software comercial numit BLUEPACK. Versiunea inițială a fost adaptată doar pentru VAX, dar succesorul ISATIS este disponibil pentru un număr de stații de lucru. Este comercializat în SUA de către GEOMATH din Houston. Geostatistica fără de calculatoare nu reprezintă mare interes – în multe privințe, realizările din geostatistică reflectă evoluțiile tehnicii de calcul, în particular apariția calculatoarelor personale și a stațiilor de lucru.

Publicații și Conferințe

Două mici volume de geostatistică axată pe minerit au apărut în engleză in anii 70: una de Jean-Michel Rendu și alta de Isabel Clark. La sfârșitul anilor 80 a apărut volumul scris de Isaaks și Srivastava, iar ulterior – o carte de Noel Cressie (la tema mai generală a statisticii spațiale dar incluzând și geostatistica).

În vara anului 1983, o a doua întrunire NATO ASI a avut loc la Lacul Tahoe, Nevada, cu un amestec mai internațional și incluzând cercetători dintr-o gamă mai largă de domenii. Datorită unei serii din patru articole al căror autor este Richard Webster și unii dintre studenții săi (pe atunci la Centrul de Cercetare Rothamstead din Anglia), geostatistica a devenit cunoscută în rândul științelor solului. Aceste articole au apărut în revista J. Soil Science (1980-1981). În 1979, la Praga, a fost fondată Asociația Internațională a Geologilor Matematicieni, care mai târziu a început să publice J. of the Int. Assn. Math. Geologists (mai târziu denumirea a fost schimbată pur și simplu în Mathematical Geology). Deși revista nu era limitată doar la geostatistică, ea în scurt timp a devenit locul principal de publicare a astfel de articole. Un al treilea congres internațional de geostatistică a avut loc în Avignon, Franța în 1988, al patrulea – în Troia, Portugalia în 1992, iar cel mai recent – în Wollongong, Australia în 1996. Ca urmare a conferinței din 1983, Andre Journel și Leon Borgman (Universitatea din Wyoming) a propus o ”vacanță de vară” anuală în geostatistică orientată spre cercetătorii din America de Nord. Primul astfel de eveniment a avut loc lângă DuBois, Wyoming în august 1984. Grupul era mic așa că prezența familiilor era încurajată. Sesiunile erau informale și nu erau publicate materiale, dar mai târziu, a fost fondat un ziar care a apărut destul de rar de atunci.

O non-organizație a fost fondată în 1987 la o întâlnire în munții Chirachaua, la sud-est de Tucson. Urmau să fie evitate orice cotizații de membru, orice apartenență formală, orice costuri de abonament pentru ziar, însă voluntarii urmau să fie solicitați pentru organizarea întâlnirilor în fiecare an. Mai multe astfel de întâlniri au avut loc atât în Canada cât și în SUA, iar în 1996, a avut loc o întâlnire în Guanajuato, Mexic. Ca urmare a fondării ziarului în America de Nord, a fost fondat și alt ziar destinat comunității europene.

În urma întâlnirii din 1983, mai mulți membri ai EPA-Las Vegas au devenit interesați în aplicarea geostatisticii în monitorizarea și evaluarea mediului ambiant. Pe lângă suportul de cercetare pentru un număr de indivizi și programe, EPA a mandatat crearea unui pachet software de geostatistică, GEO-EAS, care a fost făcut accesibil pentru domeniul public. GEO-EAS era un program DOS dar includea și elemente de interfață grafică, care l-a făcut foarte prietenos, pe lângă faptul că avea și un preț corect. Din păcate, din variate motive, EPA nu a continuat să mențină și să dezvolte acest software și nu a fost înnoit deja de câțiva ani. În 1992, Andre Journel și Clayton Deutsch au publicat GSLIB. Acesta era un set vast de aplicații geostatistice (scrise în FORTRAN) și un ghid pentru utilizatori. Versiunile actuale ale codului sunt disponibile pe pagina web a Universității Stanford. Din păcate, aplicațiile nu includeau nici un fel de interfață grafică și sunt menite pentru rulare în mod ”batch”. Acestea sunt compilabile pe un număr de platforme. În 1996, Yvan Pannatier a publicat VARIOWIN. VARIOWIN este o versiune pentru MS-Windows a două dintre componentele GEO-EAS. Programul permite procesarea unor seturi de date mult mai mari ca GEO-EAS dar și modelarea interactivă a variogramelor.

Geostatistica la Universitatea din Arizona

Geostatistica a fost predată la Universitatea din Arizona din toamna anului 1982, însă activitatea de colaborare a început mult mai devreme între Y.C. Kim și Donald Myers, A. W. Warrick (Științe ale Solului, Apei și Mediului) și Donald Myers. Cursurile au atras rapid studenți de la diverse facultăți: Ingineria Mineritului, Hidrologie, Științe ale Solului, Apei și Mediului. Mai recent, au fost atrași și studenți de la Teledetecție, Fiziologia Plantelor, Geografie, Laboratorul Tree-Ring, Resurse Naturale Renovabile. Aceasta este o consecință directă a naturii cantitative a cercetării în aceste programe diverse.

Alte Realizări

Au mai avut loc trei alte realizări care nu ar trebui trecute cu vederea. B. Matern, lucrând în Suedia, a dezvoltat în esență o teorie paralelă celei a lui Matheron, dar cu aplicare preponderent în silvicultură. Lucrarea sa au apărut în suedeză în 1960 și nu a fost tradusă în engleză până în 1986 (Springer-Verlag). Y. Ghandin, lucrând în fosta URSS, a aplicat teoria sa preponderent în meteorologie și științe atmosferice unde era cunoscută ca Analiză Obiectivă. Această lucrare nu a apărut în engleză decât mult mai târziu, când acesta a emigrat în Israel. În final, în 1971, R. Hardy (Universitatea de Stat din Iowa) lucrând asupra problemelor legate de interpolarea datelor despre gravitație, a dezvoltat ceea ce a devenit cunoscut ca Funcțiile Radiale de Bază (Radial Basis Functions). Realizările sale sunt mult mai bine cunoscute în literatura ce ține de analiza numerică.

Aplicări

Geostatistica este într-o mare măsură o disciplină aplicativă (poate chiar nu e o disciplină în genere). Dezvoltarea acesteia se datorează realizărilor inginerilor din domeniul mineritului, industriei petroliere, hidrologilor, cercetătorilor științelor solului, geologilor, cât și statisticienilor. Aceste cunoștințe și realizări se aplică în epidemiologie, patologia plantelor sau entomologie, cât și în silvicultură, științe atmosferice, științele schimbării globului, geografie. Există careva suprapunere cu Sistemele de Informație Geografică și cu statistica spațială în genere. Alte două reviste trebuie remarcate în mod special: Water Resources Research și J. Soil Science Society of America. Mai recent, articolele au început să apară în Environmetrics, Remote Sensing of the Environment dar și în altele, prea numeroase pentru a fi menționate.

După cum a fost menționat mai sus, hidrologia era printre domeniile de aplicare timpurii – merită menționată activitatea în trei locații: grupul lui L. Gelhar’s din MIT (care are legături cu New Mexico Tech din Socorro), grupul de hidrologie din Fontainebleau (în particular G. DeMarsily care este acum la Universite Paris-Jussieu) și desigur, Facultatea de Hidrologie de la Universitatea din Arizona.

PROBLEME ȘI OBIECTIVE

Într-un fel, geostatistica poate fi pur și simplu văzută ca o metodă de interpolare a datelor în baza unor tipare neregulate dar aceasta e o viziune prea simplistă. Un număr de algoritmi și metode de interpolare erau deja bine știute atunci când geostatistica a început a fi cunoscută: Inverse Distance Weighting și Trend Surface Analysis dar și algoritmi mult mai simpli ca Nearest Neighbor.

Mai întâi de toate, geostatistica este preocupată de date spațiale. Cu alte cuvinte, fiecare valoare este asociată cu o locație în spațiu și există cel puțin o conexiune subînțeleasă între locație și valoarea corespunzătoare. ”Locația” are cel puțin două sensuri: prima reprezintă pur și simplu un punct în spațiu (care există doar într-un sens abstract matematic), iar a doua – o suprafață sau volum în spațiu. Spre exemplu, o valoare asociată cu o suprafață ar putea fi valoarea medie a unei variabile observate, media fiind calculată în baza volumului corespunzător. În ultimul caz, suprafața sau volumul sunt deseori numite ”suport” al datelor. Acest concept este strâns corelat cu ideea de suport al unei măsuri. Fie x, y, …., w niște puncte (nu doar niște coordonate) într-un spațiu 1, 2, sau 3-dimensional iar Z(x), Z(y),…. denotă valorile observate în aceste locații, spre exemplu: calitatea cuprului, temperatura, conductivitatea hidraulică, concentrația unui poluant. Acum să presupunem că t este o locație care nu este ”eșantionată”. Obiectivul este estimarea/ prezicerea valorii Z(t) (și locațiile valorilor cât și locația t). Dacă această informație este oferită, atunci problema este prost formulată, cu alte cuvinte, nu are o soluție unică. O metodă de obținere a unei soluții unice este introducerea unui model în problemă. Există două modalități de a face aceasta: una este deterministă, iar alta – stocastică sau statistică. Ambele modalități trebuie să încorporeze cumva ideea că există incertitudine asociată cu etapa de estimare/ prezicere. Valoarea la locația neeșantionată nu este în sine aleatoare dar cunoștințele noastre despre ea sunt incerte. Ulterior, una din modalități este de a trata Z(x), Z(y),…. și Z(t) ca fiind valori ale variabilelor aleatorii. DACĂ distribuția comună a acestor variabile aleatorii ar fi fost cunoscută, atunci ”cea mai bună” estimare (cea mai bună însemnând imparțială și având o varianță minimă a erorii de estimare) ar fi așteptarea condiționată a Z(t) fiind date valorile celorlalte variabile aleatorii. Totuși, datele constau doar dintr-o singură observație a variabilelor aleatorii Z(x), Z(y),…. și nicio observație a variabilei aleatorii Z(t), deci nu este posibil de estimat sau de modelat această distribuție folosind metodele standard de modelare și potrivire a distribuțiilor de probabilitate.

Schimbarea Accidentală a Vitezelor

 de Sheldon “Oops!” Brown
revizuit de John “Whoops” Allen

Articol original sheldonbrown.com

Schimbarea accidentală a vitezelor spre o valoare superioară (upshifting) este un motiv destul de frecvent de plângere, în mod special în rândul bicicliștilor energici care utilizează rame destul de flexibile. Simptomul caracteristic este că la angrenajul din spate, lanțul sare pe roată dințată imediat următoare cu diametru mai mic (un sprocket mai mic) când vă ridicați și pedalați cu putere.

Primul lucru pe care îl verifică majoritatea oamenilor este maneta de schimbare a vitezelor și în zilele de dinainte, când se utilizau manete de schimbare a vitezelor pe bază de fricțiune care necesitau ajustare periodică, aceasta era deseori cauza problemei. Aceste dispozitive, în marea lor majoritate, au un șurub sau o piuliță-fluture pentru reglarea forței de frecare. Dacă acest șurub slăbește, aceasta rezultă în schimbare automată a vitezelor spre o valoare superioară. Totuși, uneori, problema constă nu într-o forță de fricțiune insuficientă, iar înșurubarea mai strânsă nu va fi o soluție.

Odată cu creșterea popularității schimbătoarelor de viteză cu trepte discrete problema a devenit mult mai puțin prevalentă ca înainte dar poate apărea chiar și în acest caz. Iar dacă se întâmplă, nu aveți niciun reglator al forței de frecare care ar putea fi ajustat. Schimbarea accidentală/ automată a vitezelor poate la fel rezulta din slăbirea șurubului de atașare a mecanismului de poziționare a lanțului (care asigură saltul de la o roată dințată la alta când sunt schimbate vitezele), dar și ca urmare a deteriorării cablului, sau a unei neconcordanțe dintre treptele schimbătorul de viteze și cele ale casetei.

Un butuc cu viteze interne (angrenajul e localizat în interiorul butucului) la fel poate suferi de schimbarea automată a vitezelor sau poate ”sări” din viteza prestabilită. Ajustarea cablului este de o importanță critică mai ales în cazul butucilor noi cu multe viteze și deplasare scurtă a cablului între viteze. Butucul cu 11 viteze interne Shimano Alfine nu va funcționa corect la o deviere a ajustării cablului de doar 1.5 mm [Mulțumesc cititorului Dale Christensen pentru această informație – căutați-l pentru a afla mai mult!]. La fel, pivotul indicator al unui butuc mai vechi se poate deșuruba de la cablu – vezi sfaturi pentru ajustare.

Cauza cea mai frecventă a problemei, fie că credeți sau nu, este elementul de ghidare a cablului de care mecanismul de poziționare a lanțului  (derailer) sau cablul de schimbare a vitezelor butucului fac uz pentru a evita axa pedalierului. În timpul pedalării bicicletei, cadrul se îndoaie dintr-o parte în alta. Aceasta cauzează creșterea și scăderea tensiunii în cablu cu fiecare rotire a pedalelor.

Dacă acest element de ghidare a cablului cauzează fricțiune prea puternică, poate acționa ca niște gheare care trag într-o singură direcție, trăgând cablul dinspre manivelă dar nepermițându-i să se retragă la următoarea rotire a pedalei. Deseori, tot ce este necesar este doar ungerea acestui element de ghidare a cablului.

În unul din cazurile cu adevărat grave, în care era vorba de un ciclist greoi și puternic cu o bicicletă veche din oțel, a trebuit să utilizez măsuri mult mai eroice. Am utilizat un scripete Sturmey-Archer, care a fost fixat în partea de jos a țevii scaunului în loc de elementul original de ghidare a cablului. Aceasta a rezolvat problema.

ANTHONY SCHIRRIPA, ARHITECT

de Chris Matthew Sciabarra

Articol original nyu.edu

Turnurile Gemene văzute de pe Feribotul Staten Island, 12 mai 2001.

Poză de Chris Matthew Sciabarra

Pe 12 septembrie 2011, The New York Times a publicat un eseu “Then I Heard a Pop” (”Și Atunci Am Auzit o Detunătură”, pagina BU8), în care arhitectul Anthony Schirripa a împărtășit cu Patricia R. Olsen propriile amintiri ale evenimentelor oribile care au cuprins orașul New York zece ani în urmă. Unele din materialele de aici sunt preluate din acest eseu, dar cele mai multe din reflecțiile de mai jos rezultă din interviul meu cu dumnealui cu ocazia evenimentului din acest an din seria mea de reculegeri anuale în legătură cu WTC.

Anthony Schirippa (sau Tony, cum preferă să fie numit), născut în Brooklyn, a vorbit despre ambiția sa din tinerețe de a deveni arhitect. Tony a frecventat școala primară Our Lady of Grace. Tatăl său, proprietarul unei mici companii de construcție, l-a încurajat să treacă testul pentru admitere la Brooklyn Technical High School, care avea un program excepțional în arhitectură. Pe timp de vară, el lucra ca ajutor de zidar pentru compania tatălui său. După finalizarea studiilor superioare, el s-a mutat la Staten Island Community College, înainte de a se transfera la Universitatea Texas A&M, unde a obținut un titlu de licențiat în științe în construcția clădirilor și un titlu de licențiat în design de mediu, absolvind Colegiul de Arhitectură în 1973. La moment, este un Arhitect Înregistrat în statul New York, Certificat la Nivel Național de către NCARB (National Council of Architectural Registration Boards) și este licențiat în alte 20 de state.

Tony a lucrat timp de patru ani la William B. Tabler Architects, care se specializa în proiectarea hotelelor, iar mai târziu la Gibbs & Hill, care se specializa în proiectarea centralelor nucleare. Timp de 15 ani, el a lucrat pentru Gensler, unde a devenit vicepreședinte. În această perioadă, unul din proiectele sale cele mai importante a fost proiectarea clădirii Goldman Sachs (situat pe Broad Street 85), un proiect cu o suprafață de circa 46000 metri pătrați implementând modalitatea indirectă de iluminare (care a devenit trend de atunci) – aceasta oferea o ambianță distinctă pentru diversele etaje dedicate activității de tranzacționare (trading). Către anul 1995, Tony a trecut la Mancini Duffy. El a devenit un partener al companiei, care era localizată la etajele 21 și 22 ale Turnului Sudic. Mai târziu, a devenit C.E.O și președinte al companiei.

Un lucru nu poate fi negat: pe parcursul tuturor urcușurilor și coborâșurilor din viață, Tony, a fost binecuvântat cu o familie mare. El este căsătorit și are doi fii, unul dintre care este și el căsătorit și are trei copii. Are și o soră, ai cărei trei copii s-au căsătorit cu toții, astfel că aceasta a ajuns să aibă opt nepoți. Din păcate, ea a pierdut un fiu în mai 2017 și unul din nepoți în martie 2018. Soția lui Tony are și ea o soră fără copii. El și familia sa locuiesc în East Northport, Long Island.

Tony își aduce aminte că în acea dimineață însorită și senină ca de la sfârșitul verii, pe 11 septembrie 2001 (o zi de marți, ca și astăzi), el ajunsese în oficiul său în jurul orei 8:30 dimineața și se ridicase la etajul 21 al Turnului Sudic. Era la masa lui de lucru ascultând mesajele vocale adresate lui. Se uita pe fereastră și privirea i se oprise asupra unei persoane care mergea prin piață spre Turnul Nordic. Dintr-o dată, a văzut aceeași persoană luând-o la fugă spre dreapta, dinspre direcția Turnului și aproape în mod instantaneu, a auzit o detunătură. S-a uitat în direcția Turnului Nordic și a văzut flăcări care se ridicau în sus spre vârful clădirii. El s-a gândit că, în mod cert, s-a produs o explozie în interiorul clădirii. Posibil că era ”un generator de rezervă care a explodat în timpul testării”. A simțit mirosul a ceea ce credea că este diesel – doar mai târziu aflase că era mirosul combustibilului pentru avioane reactive.

Din fericire, Tony nu auzise sfatul inițial adresat de către Autoritatea Portuară celor ce se aflau în Turnul de Sud și anume acela de a nu părăsi locația, de a sta în oficii, unde ar fi fost în mai mare siguranță, luând în considerare cantitatea mare de materiale detritice care cădeau din direcția Turnului Nordic. El a auzit aceste anunțuri doar după ce a ajuns în hol. În loc de aceasta, el a acționat foarte decisiv: a comunicat tuturor angajaților să evacueze imediat etajele întreprinderii timp de cinci-zece minute din moment ce primul avion a lovit Turnul Nordic. ”Toți membrii companiei mele au început să coboare scările. Eu am părăsit ultimul oficiul meu de la etajul 21 încredințându-mă că toți au părăsit încăperile, iar unul din partenerii mei Dave Hannaford a făcut același lucru la etajul 22. Dave era în fața mea îndreptându-se spre scări…”

Dintr-o dată, Tony s-a oprit. Și-a amintit de reculegerile unuia din partenerii săi care fusese martor la atentatul terorist cu camion din 26 februarie 1993 în garajul pentru parcare al Turnului Nordic. Aparent, ”ca urmare [a acestui prim atac terorist], multe dintre lucrurile personale au dispărut din oficii”. Așa că Tony a decis să meargă înapoi și să închidă ușile ca să prevină furtul lucrurilor personale ale lucrătorilor săi. El a hotărât să ia ascensorul spre parter, gândindu-se că ”dacă ceva era în neregulă în clădirea noastră, ascensoarele ar fi fost trimise spre parter și nu ar fi răspuns la chemările mele. Ascensorul s-a oprit la etajul meu,” a zis Tony, ”iar eu am început să cobor în jos”. Viteza cu care el a acționat era remarcabilă. Într-adevăr, după cum observase și el: ”Am avut noroc că am ieșit.”

”Era deja în stradă, pe Broadway”, și a recunoscut acolo pe câțiva oameni din compania sa. Le-a zis să meargă acasă cu precauție, asigurându-i că se vor reorganiza cât de curând posibil. Datorită deciziilor sale rapide, toți angajații săi au părăsit Turnul Sudic practic cu un minut înainte ca oficialii de la Autoritatea Portuară să le spună celor din clădire să evacueze ambele Turnuri și doar cu două minute înainte ca Turnul Sudic să fie lovit de al doilea avion, care a lovit între etajele 77 și 85 ale clădirii.

Era 9:03 dimineața. Tony a auzit explozia și a simțit intensitatea flăcărilor, care acum cuprindeau ambele turnuri. Mulți oameni erau în stradă, îngroziți și privind în sus la clădiri. Ar fi fost dificil de imaginat cât de groaznice erau condițiile din interiorul fiecăruia din acești zgârie-nori simbolici ai New Yorkului. Când Tony a privit în sus, putea vedea oameni căzând de la etajele de mai sus. Puteau fi condițiile atât de groaznice încât niște ființe umane să ia decizia conștientă de a sări în loc ca să fie incinerați în interior de către două infernuri verticale.

După aproximativ 40-45 de minute, Tony a început să-și facă drum spre garajul unde era parcată mașina sa, cu vreo două blocuri mai la sud de Turnul Sudic. Tony a observat gaura neagră mare din clădire și că ”lipseau coloane pe perimetrul clădirii”, așa că în scurt timp, ”a conștientizat că turnul s-ar putea prăbuși”. Pe drum spre garaj, a văzut fața sudică a Turnului Sudic și gaura din clădire. I se păruse că porțiunea de sus a clădirii ar putea cădea; s-a gândit că face să ajungă la mașină și să plece cât se poate de repede de acolo. Dar nu a fost să fie. ”Când am auzit sunetul clădirii în prăbușire, am crezut că vârful clădirii cade înspre mine. Așa că m-am refugiat lângă un perete extern și o coloană a acelui garaj, sperând că aș supraviețui căderea turnului peste clădirea în care mă aflam. Nu a fost decât mai târziu în timpul zilei când am conștientizat că clădirea de fapt s-a prăbușit vertical. Am fost înconjurat imediat de un nor de praf, și am început să-mi fac drum spre ieșirea garajului împreună cu alții care se aflau acolo. Nu puteam vedea prea departe în fața noastră”.

Ei toți se mișcau spre o lumină puternică, care s-a dovedit a fi un club de sănătate învecinat. Când s-au apropiat, oamenii dinăuntru au deschis ușile și i-au adăpostit înăuntru. Cât se aflau în acea clădire, Tony în sfârșit a văzut reportajele TV care confirmau că două avioane reactive au lovit în fiecare din Turnurile Gemene. El a văzut un video în reluare a ceea prin ce trecuse câteva clipe în urmă: prăbușirea Turnului Sudic.

În acest moment, Tony a înțeles că Turnul Nordic s-ar putea prăbuși în același fel în orice moment. ”Voiam să plec cât mai departe posibil. Praful era foarte dens.” își amintește el, pe măsură ce un miros înțepător de ars a impregnat aerul din jur. Atât de dens era fumul – un amestec de pulbere de ciment, sticlă, metale, mase plastice arse, azbest și cenușă de om – încât era ”greu de înțeles unde mă aflam”. De fapt, Tony nu se orienta corect. Pe măsură ce ”materialele detritice din stradă deveneau tot mai dense”, el a realizat că merge spre epicentrul dezastrului și nu dinspre el. Prin urmare a schimbat repede direcția și a ieșit spre Water Street, chiar în moment ce Turnul Nordic a început să cadă.

Tony și-a făcut drum înspre South Street Seaport, unde a întâlnit pe cineva pe care îl cunoștea dintr-o firmă de inginerie JB&B, care se afla în centrul Manhattanului. Bărbatul îi confirmase că ambele clădiri s-au prăbușit; ei se aflau suficient de departe ca unicele materiale detritice aduse să fie praful purtat de vânt.

El a ajuns la Podul Brooklyn, gândind că se va alătura altor mii de oameni care ar trece prin acest loc istoric, căutând să scape de devastarea din centrul Manhattanului. Un ofițer de poliție l-a informat că Calea Ferată a Long Island și tot transportul public era deconectat. Astfel că Tony a decis să facă cale întoarsă. ”Ulterior am încercat să-mi fac drum spre apartamentul fiului meu în Manhattan.” Fiul său de-abia a început să studieze la drept și locuia pe strada 11 a Bulevardului numărul 5 (5th Avenue). El a ajuns la apartament, hainele fiindu-i de-a dreptul îmbibate cu praf, a făcut un duș și a petrecut acea noapte și dimineața următoare în Manhattan. El și partenerii săi au organizat o conferință virtuală; ei erau ferm determinați să facă tot ce e necesar pentru a restabili compania. După această conferință cu colegii săi, Tony în sfârșit a părăsit apartamentul fiului său, a mers la Penn Station și a luat transportul feroviar spre casa sa în East Northport, Long Island.

Daunele cauzate companiei sale erau ireparabile; în final, prăbușirea Turnului Sudic a distrus tot ce deținea compania. În pofida acestui fapt, cu sârguință, timp de o săptămână, partenerul său cu care a fondat compania, Ralph Mancini, a putut găsi un spațiu temporar pe Park Avenue cu asistența lui J. P. Morgan. Ulterior, compania s-a mutat în midtown Manhattan și a ”stabilit un sistem mai robust de stocare și recuperare a datelor pentru operațiile sale I.T.” El la fel și-a exprimat recunoștința managerilor de construcție care și-au asumat curățarea locului dezastrului – aceasta fost finalizată cu 9 luni mai devreme decât era planificat.

Astăzi, Tony se uită înapoi la cei 17 ani care au trecut și crede că locul, cândva cunoscut ca Ground Zero, ”a fost readus la viață și că a devenit din nou o parte dinamică din orașul nostru”. El a avut norocul ”să viziteze  atât memorialul cât și muzeul.” Pentru Tony, a fost o ”vizită profund emoțională”. El crede că memorialul și muzeul nu au fost pur și simplu bine proiectate, dar și ”un omagiu puternic celor care și-au pierdut viețile”, oferind ”o comemorare sumbră și sobră a clădirilor WTC care nu mai sunt, a oamenilor și a răspunsului eroic al FDNY și NYPD în momentul atacului.”

Tony încă nu a fost în interiorul noii clădirii cu numele de “One World Trade Center.” Dar a fost ”bine informat în legătură cu proiectarea sa și toate sistemele de securitate și metodologiile de construcție gândite și implementate pentru a asigura securitatea vizitatorilor” în cazul unui nou dezastru. El este foarte impresionat de construcția acestor clădiri noi și speră că toți zgârie-norii vor fi proiectați în viitor cu o atenție similară la siguranță.

Tony a finalizat interviul cu un sentiment bine sesizabil de vulnerabilitate: ”Eu cu certitudine nu voi uita evenimentele acelor zile – niciodată. Îmi este teamă că un astfel de atac terorist se poate întâmpla din nou, în pofida eforturilor brave ale forțelor de ordine. Îmi e teamă că va trebui să ne obișnuim cu o viață în măsuri sporite de siguranță în toate aspectele vieții noastre cotidiene”.

Reculegerea ajută în vindecare, fapt pentru care sunt onorat că am oferit această platformă, din septembrie 11 2001, ca să povestesc istoriile celor care au supraviețuit. Și voi continua să fac asta atâta timp cât sunt în viață. Îmi exprim recunoștința lui Tony pentru versiunea sa asupra evenimentelor din acea zi. Este un omagiu rezilienței celor care au supraviețuit și care niciodată nu vor ceda în fața unei existențe marcată de acte de brutalitate.

Tony Schirripa (la dreapta) împreună cu familia.

Tony Schirripa (în centru) împreună cu familia.

(Pozele au fost oferite de Tony Schirripa.)

LTOOLS

Accesați fișierele d-stră Linux din Windows 9x/ME și Windows NT/2000/XP de Werner Zimmermann

Articol original www2.hs-esslingen.de

LTOOLS oferă în Windows aceeași funcționalitate ca și MTOOLS în Linux: acesta vă permite accesarea fișierelor în sistemul de operare ”ostil”.


Linux Journal, noiembrie 1, 2000 pe tema LTOOLS

Linux User Magazine, august 2000.

Notă: Noi nu suntem afiliați cu niciuna din paginile scrise în alte limbi decât engleza și nu ne putem asigura dacă aceste pagini web sunt sigure. Așa că accesați linkurile de mai sus pe propria răspundere.


Utilizarea LTOOLS prin Intermediul Liniei de Comandă

La baza LTOOLS stă un set de aplicații care rulează prin intermediul liniei de comandă și care pot fi accesate din DOS sau dintr-o Fereastră-DOS în Windows 9x/ME sau Windows NT/2000/XP. Ele oferă aceeași funcționalitate ca și binecunoscutele comenzi ”ls”, ”cp”, ”rm”, ”chmod”, ”chown” și ”ln” din LINUX. Astfel, în DOS/Windows puteți:

  • să listați fișiere și foldere Linux (comanda: ldir),
  • să copiați fișiere din Linux în Windows și invers (comenzile: lread, lwrite),
  • să ștergeți sau să redenumiți fișiere Linux (comenzile: ldel, lren),
  • să creați linkuri simbolice (comanda: lln),
  • să creați noi foldere Linux (comanda: lmkdir),
  • să modificați drepturile de acces și posesorul pentru fișierele Linux (comanda: lchange),
  • să modificați directorul implicit din Linux (comanda: lcd),
  • să setați discul/partiția implicită din Linux (comanda: ldrive) și
  • să afișați partițiile harddiskului (comanda: ldir -part).

Ca și în cazul multor instrumente UNIX, aceste funcții  sunt incluse într-un singur executabil, care este accesat utilizând un set de parametri de linie de comandă. Pentru a vă ușura viața, este prevăzut un set de fișiere batch (shell-scripturi), astfel ca să nu fiți nevoiți să memorizați și să tastați toți acești parametri. Adițional, există și o versiune Unix/Linux a LTOOLS, astfel că acesta poate fi folosit în Solaris sau chiar în Linux atunci când vreți să accesați un fișier pe altă partiție a harddiskului fără a monta această partiție.

LTOOLgui – o interfață grafică Java pentru LTOOLS

Aplicațiile cu linie de comandă sunt demodate! Unde este interfața grafică a LTOOLS? Nicio problemă – utilizați LTOOLgui. LTOOLgui, scrisă in Java folosind biblioteca Swing a JDK 2, oferă o interfață grafică asemănătoare cu cea a Windows Explorer (Fig. 1). În două subferestre, LTOOLgui vă arată arborii de directoare atât din DOS/Windows cât și din Linux. Puteți naviga prin metoda clasică de interacțiune cu interfețele grafice (point-and-click). Copierea fișierelor din Windows în Linux și invers se face prin acțiunile de copiere și inserare sau trăgând și dând drumul la obiecte în/din ferestrele respective. Un clic dreapta pe mouse va deschide o listă de opțiuni pentru vizualizarea și modificarea atributelor fișierului, astfel ca drepturile de acces, GID-ul (group ID) sau UID-ul (unique identifier). Un click dublu pe fișier îl va porni în caz că este un executabil Windows sau îl va deschide în aplicația asociată cu tipul respectiv de fișiere. Aceasta funcționează chiar și cu fișierele Linux, în caz că acestea au o aplicație Windows înregistrată.

Apropo: Puteți folosi LTOOLgui și ca manager de fișiere în Linux. Întrucât instrumentele LTOOLS cu linie de comandă sunt disponibile și într-o versiune pentru Linux, veți putea accesa fișiere de pe discuri/ partiții fără a le monta.

Autorul a ales Java pentru LTOOLgui pentru că Java este mai ales potrivită pentru accesul de nivel inferior la harddisk…glumim evident! Nu desigur, acesta nu e deloc cazul cu Java. Dacă vreți să accesați hardware-ul în mod direct, urmează să utilizați cod C++ și JNI (Java to Native Interface). Totuși, întrucât JNI funcționează doar cu cod 32 biți,  în Windows 9x/ME aceasta ar însemna a folosi ”thunking din 32 biți în 16 biți” (vedeți mai jos). Întrucât autorului, nu i-a plăcut ideea combinării limbajului JAVA de la Sun și codului MASM de la Microsoft, el a mers pe altă cale. El pur și simplu folosește aplicația cu linie de comandă LTOOLS, care este inițiată din Java prin intermediul interfeței binecunoscute stdin/stdout. Astfel, în ceea ce ține de Java, accesul la hardware înseamnă simplul input/output al fișierelor bazat pe fluxuri (streams).

Fig. 1: Interfața grafică bazată pe Java a LTOOLgui

Accesul fișierelor prin Internet?

Fără dubii, orice program de vârf trebuie să prietenească cu Internetul! Ei bine, dacă rulați LREADjav pe un computer aflat la distanță și vă conectați la el prin intermediul butonului de conectare al LTOOLgui, puteți accesa fișiere Linux pe acest server aflat la distanță ca și cum ar fi fișiere locale. LREADjav este un simplu daemon de server, care traduce solicitările trimise de LTOOLgui prin TCP/IP către programul cu linie de comandă LTOOLS, care produce și trimite outputul programelor cu linie de comandă înapoi prin TCP/IP către LTOOLgui (Fig.2). Desigur, puteți nu doar vizualiza listele de foldere dar puteți face de la distanță tot ce puteți face și local, inclusiv încărcarea și descărcarea fișierelor. Calculatorul aflat la distană poate rula Unix/Linux sau Windows. Astăzi, aceasta este mai mult o jucărie decât un program serios pentru că LREADjav poate avea probleme de securitate. Configurația implicită presupune utilizarea acestuia din ”localhost” (gazdă locală), dar programul poate fi configurat pentru a permite conectarea a trei clienți aflați la distanță, toți diferiți. Însă aceștia sunt identificați doar după adresa lor IP, nu este posibilă protecția prin intermediul parolei sau ceva de genul. Totuși, dacă e vorba de un proiect serios, utilizatorul poate ușor implementa un sistem de logare și protecție cu parolă… Pentru că e vorba de software cu sursă deschisă (open source)!

Fig. 2: LTOOLgui pentru acces de la distanță

Fără Java? Utilizați navigatorul web!

Posibil că nu aveți instalat Java 2. Ei bine, nu e nicio problemă, atâta timp cât aveți un navigator web (browser).  Porniți ”LREADsrv” și navigatorul web și introduceți ”http://localhost” ca adresă URL (Fig. 3). Ca rezultat, lista de directoare Linux va fi afișată grafic în navigatorul web. READsrv este un server web mic și local, care, printr-o simplă interfață de tip CGI (Common Gateway Interface), face LTOOLS accesibil prin intermediul solicitărilor HTTP și convertește outputul acestuia în mod dinamic în pagini HTML (Fig. 4). Desigur, aceasta nu doar oferă acces local, dar și acces la distanță prin Internet. Însă utilizatorilor de la distanță, LREADsrv le oferă același nivel jos de securitate ca și LREADjav.

Pentru că LREADsrv este bazat pe formulare HTML, care de exemplu nu susțin operarea în stil drag-and-drop sau operațiile de copiere/ inserare, lucrul prin intermediul navigatorului web este ceva mai puțin confortabil decât lucrul prin intermediul interfeței grafice bazate pe Java. Totuși, această modalitate oferă aceleași instrumente și opțiuni.

Fig. 3: Explorarea fișierelor Linux prin intermediul Internet Explorer de la Microsoft

Fig. 4: LREADsrv – acces la fișierele Linux prin intermediul HTTP

Modul de funcționare a LTOOLS – Accesarea Harddiskului în Windows

Întrucât DOS/Windows nu susține interfețe către sisteme de fișiere străine, LTOOLS trebuie să acceseze biții de date ”în stare crudă” direct de pe disc. Pentru înțelegerea funcționării interne a LTOOLS, trebuie să aveți o înțelegere de bază a următoarelor subiecte:

  • Cum sunt organizate harddiskurile în partiții și sectoare și cum acestea pot fi accesate, cu alte cuvinte, cum biții ”cruzi” pot fi citiți sau scriși (de) pe disc. Această informație poate fi găsită, spre exemplu în /2,3/.
  • Cum este organizat sistemul de fișiere Extended 2 al Linux. O prezentare generală calitativă a tot ce ține de inode-uri, grupe, blocuri, bitmapuri și directoare poate fi găsită spre exemplu în /4/.

Aceasta duce în mod automat la o arhitectură în straturi a nucleului LTOOLS (Fig. 5), care consistă din mai multe fișiere C:

  • Stratul 1 (în fișiereul Readdisk.c), care e și cel mai de jos, accesează harddiskul în mod fizic. Acest strat are de a face cu (aproape toate) diferențele dintre DOS, Windows 9x/ME, Windows NT/2000/XP și Linux/Unix în ceea ce privește accesul direct al harddiskului și încearcă să le ascundă de straturile superioare. Mai mult despre aceasta mai târziu.
  • Stratul 2 are de a face cu inode-ul tipic al UNIX, cu structurile de tip bloc și grupuri, care stau la baza organizării sistemului de fișiere Extended 2.
  • Stratul 3 operează cu structura directoarelor sistemului de fișiere.
  • Stratul 4 (în fișierul Main.c), care e și cel mai de vârf, produce interfața grafică și scanează parametrii liniei de comandă.

Prin scanarea tabelului partițiilor harddiskului, LTOOLS încearcă să identifice în mod automat prima partiție Linux de pe primul harddisk. Dacă doriți să accesați altă partiție sau disc, trebuie să specificați aceasta prin intermediul parametrului ”-s” al liniei de comandă, spre exemplu ”-s/dev/hdb2”. Ca alternativă, puteți seta un alt disc și partiție implicită prin intermediul comenzii ”ldrive”.  Pentru a afla ce partiții aveți, rulați ”ldir -part”.

Fig. 5: Arhitectura în straturi a LTOOLS

Viața era simplă în vremurile vechi și bune ale domniei DOS. Exista doar o modalitate pentru accesarea operațiilor de citire sau scriere de nivel inferior (de) pe harddisk: BIOS interrupt 13h /3/. Structurile de date BIOS au limitat harddiskurile la 1024 cilindri, 63 capuri magnetice și 255 de sectoare a câte 512 octeți, adică 8 GB. Cele mai multe compilatoare C ofereau o funcție numită biosdisk() pentru a permite evitarea programării în limbaje de asamblare. Pentru a face față harddikurilor cu capacitate mai mare, câțiva ani în urmă au fost introduse funcțiile ”extended” int 13h. Pentru depășirea limitărilor BIOSului, aceste funcții utilizează o schemă de adresare lineară, adrese logice pentru blocuri (LBA) și nu adresarea de tip vechi cilindru–cap-sector (CHS).

Aceasta încă funcționează în Windows 9x și în fereastra DOS a Windows Millenium (tabelul 1), cel puțin pentru acces de citire și atâta timp cât programul este compilat cu un compilator de 16 biți. (LTOOLS folosește Borland C; versiunea Windows NT/2000/XP la fel se compilează cu Microsoft Visual C; versiunea Unix/Linux folosește GNU C). Dacă doriți acces de nivel inferior pentru scriere, aveți nevoie de ”volume locks” /3/. Acest mecanism informează sistemul de operare că programul dumneavoastră operează scrieri directe pe disk în ocolirea driverilor sistemului de operare, astfel că Windows poate preveni accesarea diskului de către alte programe până nu isprăviți treaba. Iarăși, aceasta se poate face fără limbaje de asamblare, folosind funcția ioctl() a compilatorului C.

Într-un program Windows de 16 biți, funcțiile BIOS pot fi apelate doar prin intermediul DPMI. Întrucât majoritatea compilatoarelor C nu oferă funcții wrapper, aceasta ar necesita un asamblor (inline). Totuși, Win16 nu permite deloc programe cu linie de comandă, așa că nu vă faceți griji…

În DOS-boxul Windows NT/2000/XP, utilizarea BIOS int 13h va duce la GPF (General Protection Fault). Din motive de securitate, Windows NT/2000/XP nu permit accesul direct la harddisk în ocolirea sistemului de operare. Totuși, Microsoft oferă o soluție, care este practic la fel de simplă ca și ceea pe care ați folosi-o în Unix/Linux:

int disk_fd = open(“/dev/hda1”, O_RDWR);

Aceasta va deschide partiția /dev/hda1 a harddiskului – pentru a citi, folosiți read(), iar pentru a scrie – write(). Simplu și pe înțelesul tuturor, nu-i așa? În Windows NT/2000/XP, dacă folosiți WIN32 API /5/, funcția CreateFile() permite nu doar crearea și accesarea fișierelor, dar și a partițiilor de disc:

HANDLE hPhysicalDrive = CreateFile(“\\\\.\\PhysicalDrive0”,

                                       GENERIC_READ | GENERIC_WRITE,

                                       FILE_SHARE_READ | FILE_SHARE_WRITE,

                                    0, OPEN_EXISTING, 0, 0 );

Citirea și scrierea sectoarelor de disc poate fi acum efectuată prin intermediul ReadFile() and WriteFile().

Pentru un moment, ați putea presupune că aceeași funcție Win32 ar putea fi folosită și în Windows 9x/ME. Însă, dacă citiți documentația respectivă pentru CreateFile(), veți afla că:

Windows 95: Această tehnică nu funcționează pentru inițierea unui disc logic. În Windows 95, executarea comenzilor într-un astfel de format determină CreateFile să genereze o eroare.

În Windows 9x/ME, documentația Microsoft  pentru Win32 recomandă apelarea BIOS Int 13h prin intermediul VWIN32, unul din VxD-urile sistemului de operare (drivere pentru nucleu). Totuși, dacă încercați să faceți asta, nu veți reuși. Problema cu numărul Q137176 raportată in Baza de Cunoștințe a Microsoft spune că, în pofida la ceea ce anunță documentația oficială Win32, această metodă funcționează doar în cazul dischetelor (floppy), nu și în cazul harddiskurilor. Precum spune raportul, pentru haddiskuri unica cale este apelarea BIOS Int 16h în cod de 16 biți. Pentru a apela codul de 16 biți dintr-un program de 32 biți, aveți nevoie de “thunking din 32 în 16 biți” de la Microsoft… Acesta nu este doar un alt API (cu alte caracteristici nedocumentate sau erori documentate?). Thunkingul la fel are nevoie de compilatorul thunking al Microsoft – thunking compiler, care, dintr-un script definitoriu generează cod de asamblare.

Pornind de aici, fișiere de obiect de 16 biți și de 32 biți trebuie generate utilizând asamblorul MASM al Microsoft. Acestea vor face legătura cu zeci de rânduri de cod C, pe care urmează să le scrieți, rezultând într-un DLL (dynamic link library) de 16 biți și de 32 biți. Apropo, nu aveți nevoie doar de Visual C++ de 32 de biți pentru aceasta, dar mai trebuie să aveți și o versiune veche de 16 biți a compilatorului C al Microsoft… Ați înțeles? Utilizarea unui set de instrumente brevetate și puțin populare nu ar fi o alegere bună pentru un instrument software open source așa cum este LTOOLS!

Însumând: Trebuie versiuni separate pentru DOS/Windows 9x/ME, Windows NT/2000/XP și Linux/Unix. Pentru a ascunde aceasta de utilizator cât se poate de mult, LTOOLS încearcă să detecteze pe care sistem de operare rulează și face apel, în mod automat, la executabilul corespunzător.

Tabelul 1: Accesul de nivel inferior la harddisk

În DOSÎn Windows 9x/MEÎn Windows NT/2000/XPÎn LINUX/Unix
BIOS Int 13h
(e nevoie de Extensiuni BIOS pentru discuri de peste 8GB)
programe DOS:ca și în DOS, dar trebuie folosită blocarea/ deblocarea partițiilorpentru acces la operațiuni de scriereprograme Win16:
trebuie apelat BIOSul Int 13h prin intermediul DPMIprograme Win32:
thunking din 32 în 16 biți într-un Win16 DLL
programele DOS:
nu este permisprograme Win16:
nu este permisprograme Win32:
CreateFile(), ReadFile(), WriteFile()
open(), read(), write()

Probleme de siguranță?

Da, a avea LTOOLS înseamnă într-o măsură anume să vă expuneți anumitor riscuri. Fiecare utilizator care îl poate rula poate accesa și modifica fișiere în sistemul de fișiere LINUX, spre exemplu să schimbe drepturile de acces al fișierelor sau proprietarii fișierelor, să facă schimb cu fișiere ce conțin parole, etc. Totuși, toate acestea sunt la fel de posibile și cu un simplu editor de disc. Poate că utilizarea LTOOLS e doar un pic mai convenabilă. Cu toate acestea, accesul nelimitat este posibil doar în cazul rulării în DOS sau Windows 9x/ME. În Windows NT/2000/XP, utilizatorul LTOOLS trebuie să aibă drepturi de administrator pentru a accesa harddiskul în mod direct. În Unix/Linux, în majoritatea cazurilor, la fel doar administratorul sistemului are drepturi de acces la dispozitivele de stocare ”crudă” /dev/hda, /dev/hda1, etc.

Există careva alternative?

LTOOLS nu este unica soluție pentru accesarea fișirelor Linux din DOS/Windows. Cel mai probabil, setul de instrumente cu linie de comandă Ext2tool /6/, dezvoltat de Claus Tondering în 1996, a fost prima soluție a acestei probleme. Cu toate acestea, Ext2tool e limitat doar la acces de citire și nu rulează în Windows NT. În baza Ext2tool, în 1997, Peter Joot a scris o versiune NT, la fel limitată doar la citire /7/. Ambele aplicații au fost scrise în C, codul-sursă e disponibil în ambele cazuri.

John Newbigin ne va oferi ulterior Explore2fs /8/, care vine cu o interfață grafică foarte plăcută și rulează în Windows 9x și Windows NT. Având acces atât de citire cât și de scriere, acesta oferă aceeași funcționalitate ca și LTOOLgui. Apropo, John a făcut un lucru bun întrucât a reușit să implementeze thunkingul din 32 în 16 biți al Microsoft (vezi mai sus) chiar în limbajul Delphi de la Borland! Ca toate programele din Delphi, Explore2fs se integrează perfect în Windows, însă transferul către sisteme de operare care nu rulează Windows poate fi dificil.

Istoria și Viitorul

Prima versiune a LTOOLS a fost creată sub numele original de ”lread” de către Jason Hunter și David Lutz la Universitatea Willamette, Salem/Oregon (SUA). Această primă versiune rula în DOS, putea afișa liste de directoare în LINUX, copia fișiere din LINUX în DOS și era limitată în utilizare pentru harddiskuri mici IDE și pentru LINUX pe partiția principală.

Autorul a preluat mentenanța și dezvoltarea ulterioară în 1996. De atunci, LTOOLS a învățat să opereze cu harddiskuri de capacitate mai mare, să acceseze discurile SCSI, să ruleze în Windows 9x/ME și Windows NT/2000/XP, a învățat modalități mai ample de acces pentru scriere și a fost adaptat și pentru UNIX pentru a rula în Solaris și Linux. A apărut și interfața grafică bazată pe JAVA și cea bazată pe navigatorul web, etc., etc. Mulți utilizatori Linux, cei mai mulți dintre care au fost menționați în codul-sursă, au ajutat la testarea și debugging. Mulțumim!

Între timp, LTOOLS a ajuns la versiunea V4.7 /1/, poate chiar mai mult atunci când va fi publicat acest articol. În afară de funcționalitatea adițională, o sumedenie de erori au fost eliminate și probabil, altele noi au fost introduse. Pe parcursul anilor, a rămas relevantă aceeași problemă – nimeni nu a anticipat evoluția rapidă a tehnologiei de fabricare a harddiskurilor, când capacitatea lor a explodat și permanent se lovea de limitările sistemelor de operare. Mai țineți minte problema DOSurilor cu discurile de 512MB, problemele Windows 3.x cu partițiile de 2GB, limita BIOSului de 8GB și diversitatea de probleme pe care Windows NT le avea la 2GB, 4GB și 8GB? Parcă a fost ieri! Și apropo, chiar și Linux are problema sa: în versiunile de nucleu până la 2.3, nici un fișier nu poate depăși 2 GB întrucât Linux, ca și majoritatea altor sisteme Unix de 32 de biți, folosește un offset pointer semnat de 32 de biți atât în read() cât și în write() (această problemă va fi înlăturată în versiunea 2.4 a nucleului prin schimbarea offseturilor  la valori de 64 biți, dar menținerea compatibilității cu standardele mai noi ar putea împinge Linux spre aceleași probleme pe care le-am discutat mai sus despre Windows). Procesul de standardizarea a software-ului pentru accesarea discurilor a fost întotdeauna cu mult mai lent ca producătorii de discuri, așa că ei au inventat și brevetat soluții pentru depășirea limitelor sistemului de operare. Și întotdeauna LTOOLS și mulți alți programatori trebuiau să facă față acestor schimbări… Așa că nu vă enervați că LTOOLS nu vrea să ruleze pe calculatorul dumneavoastră nou cu disc de 64 GB. Este open source, așa că încercați să ajutați la debugging și la dezvoltarea de mai departe a programului!

Și nu uitați, dacă utilizați LTOOLS, făceți-o pe propria răspundere! Accesul doar pentru citirea fișierelor Linux nu cauzează îngrijorări. Totuși, dacă folosiți operații de scriere pentru a șterge fișiere sau pentru a modifica atributele lor pe discul d-stră Linux, atunci d-stră ca utilizator și LTOOLS aveți șanse să faceți mare haos împreună. Așa că păstrați întotdeauna o copie de rezervă a datelor importante!

Referințe

1.    http://www.it.fht-esslingen.de/~zimmerma/software/ltools.html: Homepage of the LTOOLS

2.    Michael Tischer: PC-Intern 4. Data-Becker-Verlag

3.    http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html Ralf Brown’s interrupt list for x86-PCs

4.    http://metalab.unc.edu/pub/Linux/system/filesystems/ext2/Ext2fs-overview-0.1.ps.gz: Gadi Oxman’s overview about the Extended 2 filesystem.

5.    Microsoft Windows Win32 API – Documentation, comes with most Windows C compilers or on the MSDN CDs

6.    http://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ext2tool_1_1.zip: Claus Tondering’s Ext2tool

7.    http://metalab.unc.edu/pub/micro/pc-stuff/Linux/utils/dos/ext2nt.lsm: Peeter Joot’s Ext2nt

8.    http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm: John Newbigin’s Explore2fs

Despre Autor

În viața reală, Werner Zimmermann predă ingineria de control, sisteme digitale și arhitectura calculatoarelor la FH Esslingen – Universitatea Științelor Aplicate, Esslingen, Germania. El are un background hardware și software în sisteme auto și integrate în industrie. ”Cariera” sa ca dezvoltator de software pentru Linux a început în 1994, când a procurat un CDROM, care nu era compatibil cu Linux… Așa că a dezvoltat ‘aztcd.c’, un driver Linux pentru CDROM, care încă este inclus în toate nucleele standard de Linux, chiar dacă dispozitivul e deja foarte vechi.

Thomas Tallis și Gregorio Allegri

Articolul original este disponibil pe webpages.uidaho.edu

1505-1585           1582-1652   

Muzica Pasiunii

Thomas Tallis
Gregorio Allegri
Thomas Tallis a fost cel mai influent compozitor englez al generației sale, dar și unul din cei mai renumiți compozitori ai Renașterii. Tallis a activat ca organist și în alte roluri profesionale pentru patru monarhi englezi, inclusiv în cadrul Capelei Regale. Împreună cu cel mai faimos student al său William Byrd, el a obținut de la regina Elisabeta I dreptul de monopol asupra publicării muzicii vocale. Tallis a prezidat pe parcursul celei mai dinamice perioade din istoria muzicală a Angliei, timp în care stilul continental al imitării structurale a fost adoptat în mare măsură de către compozitorii englezi ca urmare a Reformei Protestante și a suprimării mănăstirilor. Deși muzica lui Tallis include o varietate mare de stiluri și obiective, partea predominantă a creației sale este reprezentată de muzica corală, atât în stilul mai vechi al motetului latin, cât și în stilul mai nou al imnului englez. Ideile lirice de regulă domină impulsurile sale muzicale, iar polifonia sa este preponderent armonioasă (cu evitarea contrapunctului) sau omofonică. El nu era prea interesat în utilizarea contrapunctului tehnic ca atare, iar aranjamentele sale muzicale sunt caracterizate, prin urmare, de un aer de seninătate (calm) care izvorăște din mijloacele directe folosite pentru dezvoltarea ideilor melodice. Muzica sa corală sacră (latină) este cea mai înalt apreciată realizare a sa; această operă voluminoasă este preponderent în genul muzical motet, cu o mare varietate de texte selectate în mod personal și aranjate silabic în stilul Renașterii continentale, al maeștrilor italieni și al maeștrilor nordului. Imnurile sale engleze la fel au jucat un rol important în dezvoltarea timpurie a acestui gen muzical longeviv. Astăzi, muzica lui Tallis continue să fie extrem de populară. Ea a servit drept motivație pentru compozitori contemporani precum Ralph Vaughan Williams și Peter Maxwell Davies și în același timp, a servit ca stimulent principal pentru mișcarea muzicală timpurie în interpretarea corală engleză.Deși realizările tehnice ale lui Tallis sunt modeste în comparație cu cele ale contemporanilor săi care au activat la distanță nu prea mare în timp, muzica sa posedă un element superb de comunicativ al exprimării umane care încă vorbește direct cu publicul.~ Todd McComb, All Music Guide De departe cea mai celebrată compoziție a lui Allegri este Miserere mei, Deus, un aranjament al Psalmului 51(50) din Biblia Sacra Vulgata. Este scrisă pentru două coruri, unul din cinci voci, iar altul din patru voci și a obținut o popularitate considerabilă. A fost compusă pe timpul domniei Papei Urban VIII (probabil în anii 1630) pentru a fi interpretată în Capela Sixtină în timpul utreniilor din zilele de Miercuri și Vineri ale Săptămânii Mari. Miserere este unul din cele mai frecvent menționate exemple ale muzicii Renașterii târzii, chiar dacă  a fost de fapt scrisă în limitele cronologice ale erei Barocului; în acest context, este reprezentativă pentru muzica Școlii Romane de compozitori, care erau conservativi în ceea ce privește stilul. Este muzica care i-a inspirat astfel de compozitori ca Mendelssohn, Liszt și Mozart.~ Todd McComb, All Music Guide Textul Miserere (traducere în română a versiunii engleze). Ai milă de mine, o Doamne, în virtutea bunătății tale pline de iubire.În virtutea îndurării tale mărinimoase și blânde, șterge păcatele mele.Spală-mă cu desăvârșire de fărădelegile mele și curăță-mă de păcatul meu.Pentru că eu îmi recunosc fărădelegile, iar păcatul îl văd clar în fața mea.Împotriva ta și numai a ta am păcătuit și am făcut acest rău sub privirile tale, astfel încât vei avea deplină dreptate când vei vorbi și mă vei judeca.Iată că am fost zămislit în nelegiuire și în păcat m-a conceput mama mea.Dar Tu vrei ca adevărul să domnească în inima mea: fă astfel ca partea ascunsă a ființei mele să cunoască înțelepciune.Curăță-mă cu isop și voi fi curat, spală-mă și voi fi mai alb ca zăpada.Fă-mă să aud veselie și bucurie, așa ca oasele pe care le-ai zdrobit să se poată bucura.Întoarce-ți privirea de la păcatele mele și șterge toate fărădelegile mele.Dă-mi o inimă curată, o Doamne și un suflet drept.Nu mă lipsi de prezența ta și nici de Duhul Tău Cel Sfânt din mine.Dă-mi din nou bucuria salvării Tale și sprijină-mă cu spiritul Tău cel liber.Și atunci, îi voi învăța calea cea dreaptă pe cei ce încalcă legile Tale, iar păcătoșii se vor întoarce cu fața spre Tine.O Doamne, Dumnezeul salvării mele, izbăvește-mă de vina sângelui vărsat și voi cânta în glas tare dreptatea Ta.O Doamne, deschide-mi buzele și gura mea va vesti lauda pentru Tine.Pentru că nu-ți dorești jertfe, altfel ți le-aș fi adus – nu primești bucurie din ofrande arse.Jertfa care este cu adevărat pe placul Domnului este un suflet zdrobit, o inimă pocăită, pe care, o Doamne, nu o vei disprețui.Întru plăcerea ta milostivă, dăruiește binefacerile tale Sionului și zidește pereții Ierusalimului.Atunci vei fi mulțumit cu jertfe neprihănite, cu ofrande arse și ofrande întregi, atunci se vor jertfi viței pe altarul tău.

Exemple ale muzicii lor:

Tallis: Salvator mundi (Antifon pentru Vinerea Mare, comemorând răstignirea lui Isus pe Golgota; compus în latină; 3:58) din albumul Salve Regina – 2001

Tallis: Credo din Liturghia Pentru Patru Voci (7:09) din albumul Benedict – Muzică Clasică Pentru Reflecții și Meditare – 1999.

Allegri: Miserere (Psalmul 51 – Miercurea Cenușie; 13:51) din albumul Ghidul Unui Novice în Clasică (complet) Allegri – 2007. Puteți audia admirând Capela Sixtină.

Muzică pentru Passiontide* din Duminica lui Sf. Paul (Media Americană Publică, difuzat pe 16 martie 2008)

*ultimele două săptămâni din Postul Mare

 Notă: aceste materiale îl au ca autor pe Todd McComb (All Music Guide) și sunt prezentate aici pentru a fi utilizate de către studenții mei în scopuri restricționate, necomerciale și educaționale.

Nr. 1031: MECANISMUL ANTIKYTHERA

Articolul original este disponibil pe uh.edu

de John H. Lienhard

Click aici pentru înregistrarea audio a Episodului 1031.

Astăzi, vorbim despre un calculator de 2000 de ani vechime de pe fundul oceanului. Colegiul de Inginerie al Universității din Houston prezintă acest ciclu de publicații despre dispozitivele care stau la baza funcționării civilizației noastre și oamenii a căror ingeniozitate a dus la crearea lor.

Chiar înainte de Paști în 1900, șase culegători de bureți marini din Grecia și echipa lor au deviat de la itinerarul lor prestabilit în Marea Mediterană spre regiunea dintre insulele Kythera și Creta. Ei au aruncat ancora lângă insula minusculă Antikythera, chiar la sud-est de Kythera.

Ulterior, au decis să se scufunde în acele ape nefamiliare ca să vadă dacă pot găsi bureți. Ceea ce au găsit în realitate a fost epava puternic descompusă a unei nave comerciale care s-ar fi scufundat în jurul anilor 80 î.e.n. – chiar înainte de Cleopatra, chiar înainte de Imperiul Roman. 

Aceasta a fost prima epavă antică descoperită vreodată. Așa că guvernul elen i-a trimis ulterior pe acești scufundători înapoi la bordul unei nave militare. Ei s-au scufundat la adâncimea de 140 picioare (circa 43 metri) în zona naufragiului. Aceasta era înaintea aparatelor autonome de respirat sub apă  (SCUBA) și înaintea rezervoarelor de aer comprimat! Ei au continuat scufundările pe parcursul unui an, ridicând la suprafață statui, amfore și alte obiecte de comerț. Către momentul când s-au isprăvit, unul din scufundători a murit, iar alții doi au devenit infirmi.

Doar după ce articolele din presă despre această descoperire și-au pierdut actualitatea, atenția cercetătorilor a fost atrasă de un obiect anume – un set foarte corodat de roți dințate din alamă fixate într-o cutie de lemn. Dar în 1900, noi nu știam cum să conservăm obiectele antice din lemn extrase din apa mării. Prin urmare, cutia de lemn s-a destrămat în timp scurt.

A fost concluzionat că dispozitivul era probabil un fel de astrolab pentru navigație, iar fragmentele au fost duse în muzeu. În 1973, Derek de Solla Price, un istoric din Yale, a publicat în sfârșit un studiu monumental de 70 de pagini dedicat acestui obiect. Când a făcut-o, întreaga noastră viziune asupra tehnologiilor mediteraneene antice a trebuit revizuită.

Din ceea ce putem descifra din inscripțiile de pe roțile dințate, ne dăm seama că e vorba de un mic planetariu, conceput pentru a calcula și a ilustra poziția soarelui și a lunii. Angrenajul său complex de roți dințate reprezintă, de fapt, un computer analog sofisticat.

Pentru a ajunge la această concluzie, de Solla Price a folosit instrumente din repertoriul metalurgistului, radiologului, și inginerului cinematic. Angrenajul diferențial de roți dințate din acest calculator antic îmi amintește de sistemul de transmisie al clasicului Model T Ford.

Dinții roților sunt triunghiulari. Acesta nu este un design prea bun pentru o roată dințată. Istoricii știu că roțile dințate au fost inventate pentru prima oară în Africa de Nord elenistică cu doar 200 de ani mai înainte. Dar ei au presupus o perioadă îndelungată că cunoștințele grecilor despre roțile dințate erau predominant teoretice. Ei bine, nu a fost deloc așa! Am fost iarăși prostiți pentru că atât de puține artefacte originale supraviețuiesc. Roțile dințate din alamă au căzut demult pradă coroziunii sau au fost topite pentru alte scopuri.

Dar angrenajele eroice ale uzinelor ilustrate de către arta WPA (Works Progress Administration) și care apar în filmul lui Charlie Chaplin Timpuri Moderne (Modern Times) nu erau totuși atât de moderne precum păreau cândva. Chiar și minunea cea mare de la sfârșitul secolului 20, computerul însuși, pare a fi doar o întruchipare nouă a unei descoperiri mult mai vechi.

Sunt John Lienhard de la Universitatea din Houston, unde suntem interesați de modul în care funcționează mințile inventive.

(Temă muzicală)


de Solla Price, D., Gears from the Greeks: The Antikythera Mechanism — a Calendar Computer from ca. 80 BC (în traducere: Roți dințate de la greci: Mecanismul Antikythera – un computer calendaristic din jurul anilor 80 î.e.n.). Transactions of the American Philosophical Society, Vol. 64, Pt. 7, 1974, pp. 1-70.

Sunt recunoscător lui Fred Stahl, Wellington Systems, Norwalk, Connecticut, pentru sugerarea unui episod Antikythera și a articolului corespunzător aparținând lui de Solla Price. Aduc mulțumiri și lui Eli Slawson de la Observatoarele Instituției Carnegie din Washington pentru sugerarea următoarelor trei pagini web dedicate dispozitivului Antikythera:

http://www.grand-illusions.com/antikyth.htm

http://www.ams.org/featurecolumn/archive/kyth1.html

http://www.nordex.com/htmlpages/amazing.html

Transportul în Comitatul San Diego, California

Articolul original este disponibil pe efgh.com

Data transferului 14 aprilie 2020

Un Site Neoficial al lui Philip J. Erdelsky

Pentru comentarii, corecții și completări, scrieți pe adresa [email protected]

Avioane

Spre deosebire de majoritatea aeroporturilor din orașele mari, Aeroportul Internațional San Diego este amplasat în mod convenabil în apropiere de centrul orașului și de majoritatea atracțiilor turistice majore. 

Aeroportul a fost deținut și operat anterior de San Diego Unified Port District, o agenție guvernamentală specială care operează și instalațiile portuare din San Diego.  Câțiva ani în urmă, aeroportul a fost transferat în gestiunea Autorității Aeroportuare Regionale din San Diego. Site-ul lor este www.san.org.

O listă convenabilă a zborurilor non-stop din Aeroportul San Diego poate fi accesată pe www.flightsfrom.com/SAN.

Când ajungeți la Aeroportul San Diego, puteți fi salutat de către Ambasadorii Aeroportului – voluntari care vă pot răspunde la întrebări despre aeroport și alte aspecte ale turismului local.

Dacă punctul dumneavoastră de pornire sau destinația finală se află în partea de nord a  Comitatului San Diego, puteți găsi Aeroportul McClellan Palomar din Carlsbad încă mai convenabil decât Aeroportul Internațional San Diego.

Dacă punctul de pornire sau de destinație se află în Mexic, s-ar putea să vreți să zburați prin Aeroportul Tijuana.

Automobile

Șoselele Comitatului San Diego sunt destul de bune, iar congestionarea traficului încă nu a atins nivelul de gravitate care se atestă la vecinul de la nord.

Ieșirile de pe autostradă în California au denumiri. Sunt folosite și numere, dar unele ieșiri rămân nenumerotate. Aceasta uneori îngreunează semnificativ oferirea indicațiilor clare de călătorie pentru că poate fi greu de memorizat denumirea exactă a ieșirilor. De asta, am pregătit un document numit Ieșirile de pe Autostradă în Comitatele San Diego și Imperial. Este în esență o listă a ieșirilor de pe autostradă în Comitatele San Diego și Imperial, dar și distanțele și textul afișat pe semnele de ieșire. La fel, include câteva regiuni învecinate din comitatele Orange, Riverside și San Bernardino și șoseaua Interstatală 8 din Arizona.

La fel am pregătit și o Hartă a șoselelor din Comitatele San Diego și Imperial, indicând toate șoselele statale și interstatale. Nu este prea detaliată, dar o puteți utiliza până procurați o hartă mai bună la cea mai apropiată benzinărie.

Descrierile, distanțele și niște poze ale câtorva șosele din Comitatele San Diego, Imperial și Riverside care nu reprezintă autostrăzi:

Două poze ale podului I-15 peste lacul Hodges, una făcută pe când lacul Hodges încă era un lac, iar alta făcută cinci ani mai târziu, după ce acesta a devenit o pădure:

De atunci, a devenit din nou lac.

Aici găsiți alte câteva pagini web cu informații despre șoselele Comitatului San Diego:

  1. Caltrans Districtul 11 Pagina Principală
  2. Drumurile și Șoselele lui Casey
  3. Rețeaua de Șosele a Statului California Site Neoficial
  4. Șoselele din San Diego de Andy Field
BICYCLES

Biciclete

Mă deplasez cu bicicleta la nivel local cât de mult pot și am dedicat și un site acestui subiect:

Comitatul San Diego, California: Paradisul Unui Biciclist

Autobuze

Serviciile locale de transport cu autobuzul în orașul San Diego sunt operate de San Diego Transit Corporation. Hărțile și orarele pot fi accesate pe 

Câteva informații importante despre autobuzele orășenești din San Diego:

  • Prețul standard pentru majoritatea călătoriilor este de $2.25 (e necesar de achitat suma exactă).
  • Inserați banii în automat când intrați în autobuz. Automatele acceptă bancnote de un dolar, unele monede de un dolar (nu știu exact care), monede de 25 cenți, de 10 cenți și de 5 cenți. 
  • Cei în vârstă (cel puțin 60 de ani) și cei cu dizabilități beneficiază de o taxă redusă de $1.10 la majoritatea rutelor. Un act care demonstrează vârsta sau dizabilitatea poate fi necesar.
  • Aproape toate autobuzele au ascensoare pentru scaune cu rotile.
  • Fiecare autobuz are un suport pentru biciclete care poate fi utilizat de două biciclete simultan.
  • Nu există o taxă suplimentară pentru biciclete
  • Dacă trebuie să schimbați mai multe autobuze pentru a ajunge la destinație, ați putea economisi procurând un abonament pentru o zi întreagă cu $5.00 când intrați în primul autobuz. Pentru a face asta veți avea nevoie de un card compass.

Apelați 619-233-3004 pentru informații adiționale.

Orarele autobuzelor, abonamentele și cardurile compass sunt disponibile la

The Transit Store102 BroadwayDowntown San Diego
Luni-Vineri 9:00 AM până la 5:00 PM

NE corner of Broadway and First

Serviciile de transport local cu autobuzul sunt la fel disponibile în alte orașe ale Comitatului San Diego și în multe din regiunile care nu fac parte din el. 

Feribotul Coronado

Feriboturile pentru pasageri traversează regulat Golful San Diego între Broadway Pier în centrul orașului San Diego și Punctul de Debarcare al Feribotului Coronado în Coronado. O călătorie într-o direcție durează circa 10 minute.

MAPS

Feribotul se pornește:

  1. din Broadway Pier în fiecare oră de la 9 dimineața până la 9 seara dar și la 10 seara doar în zilele de Vineri și Sâmbătă
  2. de la Punctul de Debarcare al Feribotului Coronado în fiecare oră de la 9:30 dimineața până la 9:30 seara dar și la 10:30 seara doar în zilele de Vineri și Sâmbătă.

Călătoria într-o direcție costă $4.25 pentru o persoană (actualizat pe 21 februarie, 2011).

Puteți lua și o bicicletă pe feribot fără a achita taxe adiționale.

Navetiștii pot folosi feribotul gratuit în anumite ore ale zilei. Accesați site-ul pentru detalii.

Pentru informații suplimentare, intrați pe www.flagshipsd.com/coronado-ferry.

Taxiuri

De regulă, nu e necesar de chemat un taxi la aeroport, gara de autobuze, gara de trenuri sau terminalul pentru nave de croazieră. Taxiurile stau în așteptarea călătorilor.

Dacă aveți nevoie de un taxi sau o limuzină în alte locații și la alte ore, mai jos găsiți contactele câtorva companii (listate în ordine alfabetică):

Shuttle-urile comerciale deservesc aeroportul, gara auto, gara feroviară și terminalul pentru nave de croazieră. Acestea oferă transferuri grupurilor spre hoteluri, baze militare, reședințe în regiunea San Diego. Cel mai mare serviciu de acest gen în San Diego este Cloud 9 Super Shuttle. Shuttle-urile de regulă așteaptă la aeroport. Pentru îmbarcare în alte locații, apelați la 1-800-974-8885 (1-800-9-SHUTTLE) sau intrați pe www.cloud9shuttle.com.

Un site unde puteți găsi servicii de transfer spre sau dinspre Aeroportul San Diego este ShuttleWizard.com.

Serviciile de împărțire a călătoriei Uber și Lyft la fel deservesc aeroportul. Există locuri separate de îmbarcare pentru Terminalele 1 și 2. Căutați indicatoarele ”Servicii de Împărțire a Călătoriei” și utilizați aplicațiile Uber sau Lyft pentru a chema un șofer.

Limuzine

Ocaziile speciale, așa ca nunțile, aniversările, balurile de absolvire, etc. sunt printre cauzele apelării la un serviciu de transport cu limuzina. O altă situație în care are sens să faceți comandă de o limuzină este dacă numărul de oameni în grup depășește limita de capacitate a unui taxi sau a unei mașini personale. Cel mai important, contractarea unui serviciu de transport cu limuzina poate fi o soluție logică atunci când în cadrul evenimentului se va consuma alcool, de exemplu, dacă ați hotărât să dați o raită prin cluburi în Gaslamp sau să faceți o degustare de vin în Escondido sau Temecula, care se află în vecinătate.

Ca și în cazul oricărui alt serviciu, industria serviciilor de transport cu limuzina îi are pe cei care-și fac treaba bine și pe cei despre care nu se poate de zis așa. Evitați intermediarii. Compania pe care o contractați și căreia îi plătiți s-ar putea să nu fie compania care vine la ușa dumneavoastră. Sugestii ce Țin de Contractarea Serviciilor de Transport cu Limuzina.

Statul California este cel care acordă licențe tuturor serviciilor de transport cu limuzina. Companiile respective trebuie să demonstreze Comisiei Pentru Servicii Publice a Californiei (PUC) că îndeplinesc toate condițiile și că șoferii sunt supuși testării în ceea ce privește consumul de droguri. Verificați statutul licențelor pe site-ul ce aparține PUC din California.

Unele servicii de transport cu limuzina din San Diego:

Mașini de Închiriat

Dacă doriți să închiriați o mașină în San Diego, există o modalitate nouă de a o face. Utilizați smartphone-ul dumneavoastră pentru a chema una:

  • Skurt: o aplicație care vă livrează o mașină conform cererii direct unde vă aflați. Tot ce trebuie să faceți este să apăsați un buton. Detalii la skurt.com.

Trenuri

Tramvaiul San Diego vine să contribuie la mania ce ține de transportul pe căi ferate. 

Trenul de Liman Pentru Navetiști din San Diego traversează coasta de-a lungul în ambele direcții legând centrul orașului San Diego cu Oceanside în fiecare zi a săptămânii, cu excepția zilelor de Duminică și a sărbătorilor mari.

Informații despre Tramvai și Trenul de Liman puteți găsi pe

Amtrak la fel operează câteva rute de tren pe zi în ambele direcții de-a lungul coastei între San Diego și Los Angeles. Unele chiar ajung până la San Luis Obispo, destinația cea mai de nord. Accesați www.amtrak.com pentru mai multe informații.

La nord de Oceanside, există o rețea vastă de trenuri de navetiști numită Metrolink. Informații despre Metrolink puteți găsi pe acest site:

 Pagina Oficială a Metrolink

Imprimată pe un zid de sprijin al solului lângă Stația Alvarado de pe Linia Verde a Tramvaiului San Diego este o ghicitoare care sună așa:

ARTERE, VENE ȘI CAPILARE

PENTRU AUTOMOBILE, PLOAIE ȘI SUSPENSII CATENARE.

TOATE TREI LINII SE ÎNTIND UNA LÂNGĂ ALTA

DEASUPRA, DEDESUBT ȘI STRATIFICAT.

UNA ARE UN NUMĂR MAI MIC CA NOUĂ,

ALTA, ERA AICI LA ÎNCEPUTUL TIMPULUI,

IAR ULTIMA VA TRECE PE AICI DACĂ AȘTEPȚI UN PIC

SAU CHIAR ACUM, DACĂ NU AI ÎNTÂRZIAT.

PRIVEȘTE ÎN JUR CA SĂ REZOLVI ACEASTĂ GHICITOARE

NUMEȘTE-LE PE TOATE TREI: CEA DE SUS, DE JOS ȘI DIN MIJLOC

DACĂ EȘTI NEDUMERIT, URMEAZĂ BALUSTRADA

RĂSPUNSUL E SCRIS ACOLO ÎN BRAILLE.

Am fotografiat balustrada și am descifrat inscripțiile în alfabet Braille. Pentru a vedea răspunsul, verificați aici.

Glosarul Denumirilor

Multe nume în Comitatul San Diego sunt de origine spaniolă sau indiană. Am pregătit un scurt glosar pentru a ajuta vizitatorii cu scrierea corectă și pronunția denumirilor nefamiliare.

Hărți

Hărți topografice scanate pentru Comitatele San Diego, Orange, Imperial și Riverside sunt disponibile pe CD-ROM la cerere. Acestea sunt imagini în format GIF cu acces public nerestricționat. Pentru mai multe detalii, contactați webmasterul prin email.

La fel, am pregătit O hartă a Șoselelor din Comitatele San Diego și Imperial, indicând toate șoselele statale și interstatale. Nu este prea detaliată, dar o puteți utiliza până procurați o hartă mai bună la oricare benzinărie.

Hărțile lui Rand McNally Ghidurile lui Thomas sunt printre cele mai folositoare hărți a străzilor din Comitatul San Diego dar și din alte regiuni. Totuși, ca și aproape oricare altă colecție vastă de informații, acestea conțin erori. De exemplu, ele indică unele străzi care nu mai există.

Am raportat anterior unele corecții prin email și unele din aceste corecții și-au găsit loc în edițiile ulterioare. Totuși, unele raportări de erori mai recente se pare că s-au pierdut sau au fost ignorate. De asta, le listez aici în speranța că cineva de la Rand McNally le va observa și le va încorpora în edițiile ulterioare. 

Mai jos sunt unele dintre erorile identificate de mine și corecțiile sugerate.

  1. Polk Ave. la intersecția cu Park Blvd.
  2. Șoseaua 125 la intersecția cu str. Troy (corectată în ediția din 2005)
  3. Str. Nutmeg și str. Maple lângă str. 30
  4. Colțul la Polk Ave. și str. 40
  5. Robinson Ave. la intersecția cu str. Alabama
  6. Str. Upas la intersecția cu str. India și Columbia
  7. Lila Dr. la intersecția cu str. 49.
  8. Adams Ave. la intersecția cu str. Ashby
  9. str. Quince între str. Boundary și Nile.

ATENȚIE: Aceste corecții sunt aplicabile doar edițiilor mai vechi. Una dintre cele mai recente ediții ale Ghidurilor lui Thomas abundă în erori.

Linkuri

Aici găsiți linkuri la alte site-uri potențial utile: 

Este Navigatorul Web Parte a Sistemului de Operare?

Articolul original este disponibil pe world.std.com

Un exercițiu de trimitere într-o direcție greșită 

În 1998, Guvernul Federal al Statelor Unite a învinuit compania Microsoft de violarea reglementărilor antitrust. Una din plângeri era că Microsoft a început să ofere propriul navigator web Internet Explorer (IE) la pachet cu sistemul său de operare (SO) Windows. Din punctul de vedere al consumatorului, IE venea gratuit împreună cu SO. Întrucât Windows la acea vreme avea o cotă de piață de peste 95%, aceasta însemna că oricine cumpăra un calculator, obținea și browserul IE. Aceasta a redus dramatic popularitatea unicului concurent al IE de pe piață – a browserului comercial Netscape și a dus la declinul ulterior al Netscape Communications Corporation.

În apărarea sa, Microsoft afirma că navigatorul web era de fapt parte componentă a sistemului său de operare. Prin urmare, nu avea sens de discutat despre oferirea ”la pachet” a navigatorului web; este de așteptat în mod natural ca un vânzător de SO să includă și un browser în produsul său. 

 La prima vedere, acesta este un argument valabil. Toate produsele constau din anumite componente și nu putem învinui producătorii pentru includerea în produsul lor a acelor părți pe care le consideră necesare. Când cumpărăm o mașină, ea vine cu un motor la pachet. Aceasta îngreunează foarte mult vânzarea motoarelor de automobil cumpărătorilor de rând de către producători independenți de motoare. Dar nu putem acuza companiile de producere a autoturismelor de faptul că oferă motoare la pachet cu  automobilele vândute pentru a elimina producătorii independenți de motoare de pe piață: pur și simplu acceptăm că motorul este o parte componentă a automobilului.

Așa că învinuirea în adresa Microsoft s-a redus la o întrebare tehnică: este oare navigatorul web parte a sistemului de operare? Evident, procesul a avut parte de numeroase mărturii și dezbateri. Urmăream acest proces ocazional; pentru mine, întrebarea părea opacă și nu auzeam printre argumente decât afirmații de genul ”este așa” sau ”nu este așa”.

Spre final, Microsoft a fost acuzat de monopolizare, dar a primit o pedeapsă minimă. Microsoft încă oferă IE la pachet cu Windows, deși astfel de navigatoare independente ca FireFox au câștigă teren între timp. Întrebarea, însă, rămâne valabilă și azi: este browserul parte componentă a sistemului de operare?

Ei bine, este oare???

Aici există (cel puțin) patru întrebări distincte corelate, iar Microsoft a lucrat din greu   mulți ani la rând ca să ne zăpăcească și să ne facă să le confundăm. Ei nu vor ca oamenii să aibă o viziune clară asupra întrebării întrucât aceasta nu le-ar servi deloc cauza. Haideți să abordăm întrebările pe rând și să vedem dacă putem să le clarificăm. Iată care sunt acele întrebări: 

1. Așteaptă oare clientul ca calculatorul să includă un navigator web?

2. Cine ar trebui să aleagă browserul și să-l integreze cu calculatorul?

3. Este navigatorul web parte a colecției vaste de software cu numele de ”sistem de operare”?

4. Ar trebui ca codul care implementează browserul să fie integrat cu nucleul sistemului de operare (kernel)?

Așteaptă oare clientul ca calculatorul să includă un navigator web?

Aceasta este o întrebare despre comportamentul și așteptările consumatorului. Când un consumator de rând sau un om de afaceri de rând cumpără un calculator, îl despachetează și îl include, așteaptă ei oare să găsească și un navigator web preinstalat? Pentru a afla răspunsul, trebuie să vorbim cu consumatorii și să le urmărim comportamentul. Răspunsul se dovedește a fi da.

În discuțiile cu guvernul care au precedat acest proces, un avocat al Microsoft a spus despre sistemul de operare Windows:

Noi am fi putut oferi un sandviș cu șuncă, dar nimeni nu l-ar cumpăra.

Partea cu șunca a fost scoasă din context și folosită ca exemplu al aroganței demonstrate de Microsoft; însă, ceea ce voia să spună avocatul era că Microsoft este sensibil la așteptările consumatorilor, iar consumatorii așteaptă ca calculatoarele lor să aibă și un navigator web preinstalat.

Răspunsul la întrebarea această este în favoarea Microsoft.

Cine ar trebui să aleagă browserul și să-l integreze cu calculatorul? 

Aceasta este o întrebare despre organizarea industrială: cum ar trebui organizată producerea și distribuirea calculatoarelor? În Statele Unite, noi lăsăm piața să decidă majoritatea întrebărilor de acest gen. 

Industria calculatoarelor personale are aproximativ 25 ani. Au avut loc anumite evoluții în această perioadă, însă elementele esențiale au rămas neschimbate și clar stabilite. Calculatoarele sunt create de către producătorii de echipamente originale (original equipment manufacturer sau OEM) – companii ca Dell, Gateway și Hewlett-Packard. Aceste companii:

  • cumpără componentele (șasiuri, transformatoare electrice, plăci de bază, harddiskuri, etc)
  • asamblează calculatoarele utilizând aceste componente 
  • instalează software-ul
  • creează un ghid de exploatare și oferă un talon de garanție
  • le pune pe toate într-o cutie
  • își imprimă numele pe cutie
  • vinde produsul direct consumatorilor sau intermediarilor 

Producătorii de echipamente originale au responsabilitatea de a integra tot software-ul instalat pe calculator cu o excepție. Microsoft dictează ca producătorii (OEM) care instalează Windows să instaleze și IE pe toate calculatoarele. Microsoft impune aceste condiții prin intermediul licenței care însoțește Windows.

Dacă Microsoft nu și-ar impune puterea sa de monopol, există tot temeiul să credem că producătorii de echipamente originale (OEM) ar fi cei care aleg ce browser să instaleze, fix așa cum selectează celelalte componente.

Răspunsul la această întrebare este în defavoarea poziției adoptate de Microsoft.

Este navigatorul web parte a colecției vaste de software cu numele de ”sistem de operare”?

Această întrebare fie ține de opinia fiecăruia, fie nu are un răspuns cert. Explicația constă în faptul că termenul ”sistem de operare”, așa cum este utilizat aici, nu este definit clar în termeni tehnici. O analogie ar fi termenul ”oraș”.

Orașele sunt mari și se întind pe teritorii mari, iar hotarele lor pot fi greu de deslușit. Este adevărat că orașele au hotare geografice clar delimitate din punct de vedere legal, dar câți oameni cunosc exact pe unde trec acestea și cui îi pasă prea mult de asta?

Să întrebi dacă browserul este pare a sistemului de operare este ca și cum ai întreba dacă o linie de autobuz este parte a orașului. În final, depinde de ce avem în vedere prin ”oraș”.

Răspunsul la această întrebare este irelevant pentru procesul cu implicarea Microsoft.

Ar trebui ca codul care implementează browserul să fie integrat cu nucleul (kernel) sistemului de operare? 

Aceasta este o problemă inginerească. Spre deosebire de termenul ”sistem de operare”, termenul “nucleu al sistemului de operare” are o semnificație tehnică clar definită, iar întrebarea are un răspuns cert.  Din punct de vedere ingineresc, răspunsul este un ”Nu” sigur.

Sistemele de operare sunt organizate în straturi, la fel ca ceapa. Stratul cel mai adânc este numit de regulă nucleu (kernel).

Nucleul este prima componentă a SO care este încărcată când calculatorul este pornit și primul lucru pe care îl face nucleul este să preia controlul asupra tuturor componentelor fizice ale calculatorului (hardware).

  • procesorul 
  • memoria
  • discurile (harddiskurile, discurile optice, etc.)
  • monitorul
  • tastatura/ mouse-ul
  • conexiunile în rețea 

Toate celelalte aplicații rulează sub controlul nucleului. Nucleul:

  • determină orarul de execuție al aplicațiilor 
  • alocă resurse aplicațiilor 
  • recuperează resursele alocate aplicațiilor atunci când acestea nu mai au nevoie de ele 
  • elimină aplicațiile din sistem atunci când ultimele sunt oprite.

În mod crucial, hardware-ul calculatorului asigură posibilitatea ca nucleul să poată prelua din nou controlul în caz că o aplicație îngheață, se prăbușește, sau rulează într-un mod greșit. Când se întâmplă așa ceva, nucleul oprește aplicația, face curățenie, și rulează mai departe.

Atâta timp cât nucleul funcționează normal, SO poate să se restabilească după orice eroare produsă în orice altă aplicație. Spre deosebire, dacă nucleul este compromis de către:

  • erori 
  • programe dăunătoare
  • intruși

atunci aplicațiile în care se produc erori pot:

  • să interfereze cu alte aplicații
  • să blocheze calculatorul 
  • să corupă datele.

De regulă, unica modalitate de a restabili calculatorul după o problemă cu nucleul este resetarea. Dacă coruperea datelor se extinde și asupra harddiskului, poate fi necesară reinstalarea SO. 

În lumina tuturor celor menționate mai sus, o practică inginerească bună este crearea unui nucleu cât mai mic și mai simplu. Cu timpul, nucleele tind să devină mari și complicate întrucât ele efectuează o multitudine de operațiuni complexe. Însă principiul următor rămâne valabil: nimic nu trebuie introdus în nucleu fără o scuză bună.

Scuzele bune

Niște scuze bune pentru includerea anumitor componente în nucleu sunt:

  • necesitatea
  • performanța
  • securitatea

Necesitatea

Unele aplicații pur și simplu nu pot fi făcute să lucreze dacă nu sunt în interiorul nucleului. Navigatorul web nu este nicidecum printre ele. Multe navigatoare folosite pe larg au funcționalitate avansată și pot rula pe Windows nefiind parte din nucleu. Acestea includ:

Existența acestor navigatoare demonstrează că nu este necesar ca browserul să fie parte din nucleu.

Performanța

Unele aplicații rulează mai rapid sau mult mai rapid dacă sunt parte din nucleu. Browserul, iarăși, nu aparține acestei categorii. Browserul Internet Explorer al Microsoft nu rulează deloc mai rapid fiind parte din nucleu comparativ cu alte browsere care nu sunt parte din nucleu. Pe lângă aceasta, considerând tehnologiile actuale cât și modul de utilizare, navigatoarele web  petrec mai mult timp în așteptarea operațiunilor de încărcare și descărcare a datelor din rețea decât în așteptarea execuției operațiunilor de către procesor. 

Securitatea

Unele aplicații rulează în interiorul nucleului pentru că e necesar ca acestea să se afle în interiorul granițelor de securitate ale nucleului. Un exemplu bun este sistemul de fișiere. Iar browserul nu este un exemplu bun. Navigatoarele web listate mai sus care rulează în afara nucleului sunt sigure – conform multor estimări, mult mai sigure ca Internet Explorer, care rulează în interiorul nucleului. Securitatea nu este un motiv bun pentru a rula un browser în interiorul nucleului. 

Integrarea

Uneori este menționată altă justificare pentru includerea browserului în nucleul SO și anume integrarea. ”Integrarea” este doar un cuvânt frumos care semnifică că ceva ”reprezintă o parte componentă” a altceva, așa că avem parte aici de un argument circular. 

Inspectând îndeaproape beneficiile proclamate ale integrării, aceste deseori se dovedesc a fi afirmații despre un nivel superior de performanță, securitate sau comoditate. Deja ne-am convins că argumentele privind performanța și securitatea nu justifică includerea browserului în nucleu. Mai jos vom discuta aspectele ce țin de comoditate.

Păstrarea în afară

Pentru că nu există niciun motiv serios pentru includerea browserului în nucleu, practicile inginerești bune recomandă păstrarea acestuia în afara nucleului. Dar nu este vorba doar de practici bune: există beneficii reale care justifică păstrarea browserului în afara nucleului. Cele mai importante două motive sunt:

  • stabilitatea
  • securitatea

Stabilitatea

Oamenii creează nuclee pentru sisteme de operare deja de mai bine de jumătate de veac. Noi știm cum:

  • să le proiectăm
  • să le ”scriem”
  • să le facem stabile și sigure

La fel, dezvoltatorii creează browsere de zeci de ani. Cunoștințele despre proiectare, implementare, cerințele de bază încă evoluează. Dar este binecunoscut faptul că includerea browserului în nucleu îl destabilizează în mod semnificativ.

Securitatea

Nucleul impune granițe de securitate la interfețele sale. Orice date care trec prin aceste interfețe trebuie verificate pentru a constata dacă nu încalcă cerințele de securitate ale nucleului. Nucleul poate fi complex, dar interfețele sale sunt:

  • bine definite
  • bine înțelese
  • relativ simple.

Aceste proprietăți sunt cruciale pentru crearea unor nuclee sigure. Dacă interfețele sunt prost definite, prost înțelese, sau pur și simplu prea complicate, atunci asigurarea securității nucleului devine o sarcină imposibilă.

Dacă nucleul include un browser, atunci granițele sale de securitate se extind la interfața dintre browser și Internet. Această interfață include:

  • pagini web (text, HTML, XML, …)
  • reguli de stil (style sheets)
  • aplicații încorporate (Java, JavaScript, ActiveX, …)
  • imagini (GIF, JPEG, PNG, …)
  • linkuri (URL-uri)
  • pluginuri (Flash, …).

Cuvintele “World Wide Web” descriu foarte elocvent cât de abundente, complexe și vagi sunt datele pe care browserul trebuie să le mânuiască. Validarea acestor date este imposibilă și încadrarea browserului în nucleu compromite securitatea în mod iremediabil. 

Recapitulare

Pentru referință, aici sunt răspunsurile pe care le-am obținut la cele patru întrebări ale noastre:

1. Așteaptă oare clientul ca calculatorul să includă un navigator web?

DA

2. Cine ar trebui să aleagă browserul și să-l integreze cu calculatorul?

Producătorul de echipamente originale (OEM)

3. Este navigatorul web parte a colecției vaste de software cu numele de ”sistem de operare”?

Depinde de ce se are în vedere prin ”sistem de operare”

4. Ar trebui ca codul care implementează browserul să fie integrat cu nucleul sistemului de operare (kernel)?

În niciun caz

Acum, haideți să vedem ce face de fapt Microsoft cu Internet Explorer.

  1. Microsoft furnizează Internet Explorer la pachet cu sistemul de operare Windows. 

Destul de corect – clienții așteaptă să obțină și un browser la pachet cu calculatorul.

  1. Microsoft impune producătorii de echipamente originale (OEM) să instaleze anume IE și nu oricare alt browser pe calculatoarele care sunt livrate cu Windows.
    Joc murdar și ilegal apropo. Din păcate, OEM-urile sunt prea dependente de Microsoft pentru a se plânge iar guvernul SUA refuză să aplice pedepse pe măsură companiei Microsoft, aparent, din motive politice.
  2. Microsoft spune că browserul este parte componentă a sistemului de operare.
    Ei au dreptul la această opinie.
  3. Microsoft integrează codul de implementare al Internet Explorer în nucleul SO Windows.
    Aoleu!!!!!!!

Este chiar atât de rău totul?

Este cu adevărat foarte rău.

Discuția de mai sus este tehnică și într-o măsură anume abstractă, dar problemele la care se refer nu sunt deloc abstracte. Includerea navigatorului web în nucleu cauzează probleme reale utilizatorilor de rând.

Toate navigatoarele web produc erori; toate browserele  îngheață sau fac colaps ocazional. Când aceasta se întâmplă cu un browser ca Firefox, utilizatorul pur și simplu pierde pagina web accesată. Pentru a fi vizualizată din nou, trebuie doar pornit browserul și reintrodus URL-ul. Când Internet Explorer face colaps, ia după el și nucleul, sistemul de operare și calculatorul. Restabilirea, de regulă, necesită o resetare iar pierderea datelor în alte aplicații deschise la moment nu este o raritate.

Toate navigatoarele web au breșe de securitate; toate browserele sunt supuse atacurilor din partea paginilor web ostile. Când un browser ca FireFox este compromis, atacatorul obține controlul doar asupra browserului. Când Internet Explorer este compromis, atacatorul obține controlul asupra nucleului și prin intermediul său, asupra întregului calculator.

De ce ei continuă să o facă?

Dacă integrarea browserului cu nucleul SO este o idee atât de proastă, ne întrebăm în mod natural de ce Microsoft continuă să o facă. Răspunsul constă din două părți:

  • de ce o fac conform spuselor lor
  • de ce o fac în realitate

De ce o fac conform spuselor lor

Primul răspuns al Microsoft este, desigur, că browserul este parte componentă a sistemului de operare. Totuși, răspunsul se bazează pe o confundare a întrebărilor examinate în detaliu anterior. Nimeni nu are obiecții la afirmația că termenul de ”sistem de operare” poate fi suficient de vast ca să includă și un navigator web. Întrebarea este ce a dat peste cei de la Microsoft ca să includă browserul în nucleul SO. Microsoft preferă să nu vorbească prea multe la acest subiect, dar dacă citim literatura lor de marketing și conținutul reclamelor, putem identifica și alte afirmații în acest context. 

Microsoft declară în gura mare despre comoditatea și utilitatea care rezultă din integrarea IE cu nucleul SO. Este întotdeauna acolo; rulează fără întrerupere. Conținutul din orice sursă de pe net poate fi transferat fără probleme oricărei aplicații de pe calculator. Datele din orice aplicație pot fi afișate ca o pagină web. Distincția sâcâitoare dintre propriul calculator și Internet dispare: Windows are grijă de toate pentru dumneavoastră.

În mod ironic, este exact acest tip de integrare care fac din Internet Explorer un vector atât de eficient pentru programe dăunătoare. ”Comoditatea” pe care Microsoft o oferă vine la un preț colosal în ceea ce privește securitatea și stabilitatea. 

De ce o fac în realitate?

Când abia totul începea, Microsoft vindea produse bazându-se pe caracteristicile, performanța și comoditatea lor și compania încă pretinde să acorde atenție acestor beneficii orientate spre consumatori. Spre deosebire, în ziua de azi, strategia primară de vânzare a produselor de către Microsoft este de a priva clienții săi de oricare alternative. 

Una din metodele utilizate este prin eliminarea afacerilor concurenților săi, de exemplu, prin includerea ”la pachet” a unor produse. Dar simpla includere a IE în aceeași ”cutie” cu Windows nu este suficientă: dacă tot ce făcea Microsoft era pur și simplu să o includă în ”cutie”, oricine ar fi fost liber pur și simplu să o ”scoată” de acolo.

  • Dacă judecătorii în procesul antitrust ar fi putut elimina IE din Windows, ar fi fost mult mai dificil pentru Microsoft să-și susțină afirmația precum că IE este parte din Windows.
  • Dacă utilizatorii ar fi putut elimina IE din Windows, ei ar fi putut opta cu o probabilitate mare pentru alte browsere. 

Există la fel și o cauză istorică pentru includerea IE în Windows. Până la începutul anilor 1990, Internetul era în esență un proiect de cercetare finanțat de guvern și limitat la universități și corporații mari. Ulterior, un ansamblu de evoluții l-au făcut practic pentru utilizatorii de rând. 

Acestea includeau:

  • micșorarea prețurilor la hardware 
  • extinderea rețelelor 
  • dezvoltarea interfețelor grafice
  • deciziile politice de a comercializa Internetul și de a lărgi accesul la el.

Când aceasta s-a întâmplat, Internetul, dintr-o dată a fost propulsat în conștiința publicului larg. Pentru o perioadă scurtă de timp, existau speculații serioase că browserul va înlocui sistemul de operare ca interfață primară de interacțiune a utilizatorului cu calculatorul.

O atare perspectivă înspăimânta compania Microsoft. Dacă utilizatorii ar petrece tot timpul în navigatorul web, nu le-ar păsa prea mult ce sistem de operare rulează pe fundal. În așa caz, producătorii de echipamente originale (OEM) ar fi fost liberi să vândă calculatoare cu sisteme de operare produse de concurenți, iar monopolul Microsoft s-ar fi evaporat. 

E binecunoscut că Microsoft erau absolut nepregătiți pentru comercializarea Internetului. Primul lor răspuns a fost să-și creeze propriul navigator web, dar ei la fel s-au asigurat că acesta era integrat direct în sistemul de operare. În acest fel, chiar dacă browserul devenea cumva sistem de operare, utilizatorii oricum ar fi rulat Windows, iar Microsoft ar fi continuat să controleze industria calculatoarelor staționare. 

Lucrurile nu au urmat acest scenariu. Consumatorii navighează în rețea de ani buni,  nu își petrec tot timpul în interiorul navigatorului web și încă le pasă mult ce sistem de operare utilizează. Dar Microsoft nu a făcut un pas înapoi de la decizia sa inițială de a integra browserul cu sistemul de operare – ba chiar din contra, le-au făcut pe ambele inseparabile, împrăștiind codul de implementare a browserului în multiple fișiere ce se regăsesc în diverse locații ale sistemului de operare și estompând distincția dintre rețea și desktop la interfața utilizatorului.

Remarci

Netscape Communications Corporation

Wikipedia oferă o scurtă istorie a Netscape Communications Corporation. Numele Netscape supraviețuiește ca o marcă înregistrată de AOL.

nucleu al sistemului de operare

Această discuție se referă în mod special la sistemele de operare cu nuclee monolitice, așa ca GNU/Linux și Windows 95/98/ME. Pentru sisteme de operare cu arhitectură micro-nucleu așa ca GNU/Hurd și Windows NT/2000/XP, terminologia și detaliile sunt întrucâtva diferite; totuși elementele esențiale sunt similare.

caracteristici, performanță și comoditate

Am utilizat compilatorul C excelent al Microsoft practic pe întreg parcursul anilor 1980.

un pas înapoiJoel Spolsky susține că Microsoft a neglijat în mod intenționat dezvoltarea IE, din frica că un browser mult mai capabil, fie chiar și al lor, le-ar fi putut încă amenința monopolul pe piața sistemelor de operare.