Canonical incepe sa ma calce pe nervi

Wednesday, 22 June, Year 3 d.Tr. | Author: Mircea Popescu

Canonical e unul dintre grupurile care ofera pachete de ubuntu pentru oamenii prea lenesi sa si le configureze ei.

Sunt practic vorbind un fel de Microsoft lightweight asa. Distributia lor e cea pe care am recomandat-o cu ocazia articolului despre trecut pe linux (il stiti, ala citit de vreo doua ordine de marime mai multi oameni decit aberatiile "blogerilor" despre BCR).

Pentru ca eu nu cred in vorbit discutii, l-am chiar instalat, l-am chiar testat, e si astazi pe-un box. De functionat functioneaza, dar!

canonical-suge

Cu care ocazie, hai sa lamurim niste chestii.

In primul rind, "branding pentru firefox" nu poate nici intr-un caz sa fie "Important Security Update". Nu are cum. Nu este posibil.

In al doilea rind, daca "the list of changes isn't available yet" atunci pachetul nu-i gata pentru a primi push catre utilizatori. Nu ma intereseaza ce se rezolva. Chiar daca-i chestie ca linuxu' crapa in doua si expune parola de root unui utilizator remote, patch-ul care repara chestia asta nu-i gata pentru a primi push catre utilizatori pina cind cineva nu a scris "reparam bugul ala care crapa kernel-ul si expune parola de root remote".

Astea doua probleme trecind peste faptul ca dupa mintea mea, un pachet software care primeste update trebuie dezinstalat. Pentru ca nu-i inca gata de utilizare, noi nu futem pubere si nici nu folosim software care nu-i terminat. Ca suntem oameni seriosi.

Sigur, spre deosebire de Microsoft, care instaleaza toate cacaturile direct si pe ascuns astia macar te intreaba, si e al naibii de simplu sa le eviti, un checkbox acolo. Ceea ce e foarte bine, ca faceam explozie. Dar totusi, principiul ramine gresit.

Si e trist daca ajungi sa inveti principii de pe un blog romanesc, cind tu ai peste trei ani de experienta in domeniu, in lumea reala. Parerea mea.

Category: Meta psihoza
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.

87 Responses

  1. tu chiar citesti lista lu' peste?

  2. Mircea Popescu`s avatar
    2
    Mircea Popescu 
    Wednesday, 22 June 2011

    Io-s om serios, ce pielea.

  3. linux deci cum ?
    http://www.ubuntu.com/usn/lucid/

    10 patch-uri in iunie 2011
    17 patch-uri in mai 2011

    la versiunea 10.4 lansata in aprilie 2010.

  4. Mircea Popescu`s avatar
    4
    Mircea Popescu 
    Wednesday, 22 June 2011

    Plm ii stie, asa au ei impresia ca-s feshan.

  5. deci ti-ai tras teapa singur.

  6. Păi asta se întâmplă cam la toate distribuţiile de linux, mai mult sau mai puţin.

    În definitiv, ce e o versiune nouă dacă nu una cu a) o parte din erorile versiunii precedente eliminate şi b) noi funcţionalităţi, care pot la rândul lor introduce alte erori? De obicei le testează un timp şi apoi le dau "push", dar invariabil vor mai exista bug-uri depistate după şi patchuite.

    Ceea ce diferă la aceste distro-uri este înclinaţia autorilor spre safe sau spre cutting edge. Iar Ubuntu stă bine aici, e o distribuţie stabilă. Fedora de exemplu implementează tot ce e nou, chit că uneori apar diverse probleme. Totuşi mulţi linuxişti cu state vechi o preferă, inclusiv Linus Torvalds.

    Mai e o chestie de menţionat. Ubuntu scoate o versiune nouă o dată la şase luni. Deci la un interval fix.

    Dar s-ar putea să ai dreptate cu Canonical.

  7. This is a transitional package to ensure that upgrades work correctly. It can be safely removed ... de pe http://packages.ubuntu.com/natty/firefox-branding
    Sterge-l deci.

  8. Astea doua probleme trecind peste faptul ca dupa mintea mea, un pachet software care primeste update trebuie dezinstalat.

    Nu-s deloc de acord. Mai au oamenii din industrie câteva concepte cu „software engineering” și alte bălării (avea Diana un articol pe temă) și nu, nu prea merge, adică merge în teorie dar nu ține foarte bine în practică. Dezvoltarea software-ului nu-i ca dezvoltarea podului [1], nici un soft nu e vreodată „terminat”, asta dacă nu cumva e ceva extrem de simplu, un dd sau un ls sau mai știu eu ce, deși și alea sunt updatate cam o dată la zece-douăzeci de ani, așa. Pur și simplu, când ai trecut de pragul de zece mii de linii de cod și zece dezvoltatori (ba chiar și sub), e imposibil să nu apară probleme, statistic vorbind. Și bun, sunt probleme, dar time-to-market-ul bate la ușă, chiar dacă e linux (a se vedea ce fac Google cu Chrome și cum s-au luat și Mozilla după).

    În rest, na, nici io nu m-am prins care-i faza cu firefox-ul ca update important de securitate. De fapt problema s-ar putea să fie pur tehnică: au băgat un update de securitate în xulrunner (care-i vulnerabil la din astea), iar rahatul de firefox-branding era o dependență, deci au trebuit să recompileze și să bage în upstream toate pachetele alea. Chestie care nu mă miră, fiindcă firefox-ul (mai ales firefox 3) are probleme mari cu felul în care i-a fost concepută arhitectura, de sus până jos.

    [1]: Chestie apropo de care, auzisem mai demult o anecdotă conform căreia dacă dezvoltatorii software se făceau constructori de poduri, cădeau toate la prima utilizare; tind să fiu oarecum de acord.

  9. Dacă construiau poduri atunci ar fi gândit la altă scară şi altfel ar fi proiectat totul. De altfel n-am auzit ca softul pentru (să zicem) rachete să fie chiar bug-ridden, dar acolo altele sunt constrângerile.

  10. În general nu, în particular da. O parte deloc neglijabilă din supercomputerele din State au fost construite după accidente de rachete spațiale, pentru a putea face simulări mai complicate, pentru că softurile de reglare nu luau în calcul anumite corner case-uri. De altfel și ESA au avut o problemă de genul [1].

    În plus, un soft scris pentru un microcontroller n-o să depășească decât rar 1000 de linii și e testat la niște standarde, ce-i drept. Nu se aplică la programele care rulează pe sisteme de operare, cu excepția softurilor făcute special pentru RTOS poate.

    [1]: http://en.wikipedia.org/wiki/Ariane_5_Flight_501

  11. Mircea Popescu`s avatar
    11
    Mircea Popescu 
    Wednesday, 22 June 2011

    @Critic http://www.thinkgeek.com/books/humor/8e6c/images/2070/

    @Lotus Nu prea vad legatura, da-n fine.

    @spyked Cum adica "nu e terminat" ? Mei frate, de feature creep ai auzit ? Software inseamna ca iti alegi o sarcina, o rezolv, lansezi produsu' si treci mai departe. Software nu inseamna ca ai un produs bun pe care "il dezvolti", "il redizainezi" si alte cacaturi, aia e cel mult "design", si e chestia cu care se mindreste spatiul Windows : orice produs util si functional pina la versiunea 2-3 va deveni imposibil de utilizat de la 5 incolo.

    Care "time to market" ? Eu am folosit 10 ani TCMD, stii cite update-uri am avut la el ? Sa-ti zic ? Nu ma fute la cap cu aiureli. Un program bun se face in o luna, maxim doua, de o singura persoana, si e gata facut. La Golden Axe cite update-uri ai avut ?

    Indiferent de ce "au trebuit sa faca", si cu mentiunea ca cine ajunge sa "trebuiasca sa faca" la calculatoare e dobitoc din capul locului, puteau scrie cu minusitele lor alea de dobitoci "am futut xul si tre' sa recompilam toate astea sorry". Era ok.

    @dAImon Eu n-am inteles teoria asta. Deci de cind sunt doua clase de consumatori, aia smecheri cu rachete si aia fraieri cu linuxu' ? Pai mai frate, parca toti astia-s socialisti cu open source, smecherii ? Ce facem aici, ori suntem egali ori nu mai suntem ?!

  12. moot approves this !

  13. Deci stai, cine a zis ceva de feature-uri? Kernel-ul linux e dezvoltat de douăj de ani mâine poimâine pe modelul ăsta.

    Și iar, Golden Axe câte linii de cod avea? Da' World of Warcraft câte linii de cod are? Mnoa, asta-i diferența. Când faci un soft simplu, nu e nevoie să-l updatezi. Când nu mai e simplu, e nevoie. Ghinion.

  14. Mircea Popescu`s avatar
    14
    Mircea Popescu 
    Wednesday, 22 June 2011

    @Critic moot has no ideea who you are.

    @spyked NIMIIIIC!!!!!

    Nu exista motive suficient de bune pentru a scrie programe mai lungi decit putem tine-n cap.

    THIS IS SPARTA!

  15. @Mircea Popescu @spyked
    Nu vreau sa fiu rau cu nimeni da compara tu numarul de poduri / arhitecti care stiu face poduri cu numarul de "programe" si de "programatori". Dupa care ia distributia capacitatiilor intelectuale si vezi cam ce-ti iese.

  16. Pfai, deci cum nu? O parte deloc neglijabilă din programele de pe Linux sunt mari și dezvoltate *încontinuu*. apt, apache, postfix, tot ce are o funcție mai complexă decât editor text o să se lovească de bug-uri, imposibil să nu. Din păcate nu poți aplica filosofia Unix la orice soft de pe lumea asta.

    Și nici principii de dezvoltare de genul „scriem 10 ani la el după care iese perfect” nu merg. Că nu iese, în stilul ăsta hardware-ul devine obsolete și scoți un rahat pe băț (a se vedea Duke Nukem Forever).

  17. Mircea Popescu`s avatar
    17
    Mircea Popescu 
    Wednesday, 22 June 2011

    @Dr.A Buei ce hater.

    Ce urmeaza sa mai scoti acuma, chestii ca orice proasta se face social media manager expert delo negocios si de-aia suntem in halu' in care suntem in zona aia ?

    Pfoai ce oameni, ce suflete haine.

    @spyked Sa ma uit de curiozitate cind am primit ultimu' update la postifix ? sau la mysqld ? Sau la ce sa ma uit ? Nu ma mai omori cu zile, Duke Nukem n-o avut nici o legatura cu discutia asta, cre'ca stii istoria si nu-i nevoie sa ma apuc s-o repet ?

    Ideea e sa iti alegi o bucata si s-o rezolvi corect, modular si in asa fel incit sa se poata utiliza solutia ta oricind de catre oricine, nu sa faci echipe de ametiti care sa rezolve prost probleme prea mari pentru ei. Ca scopu' nu-i sa ne dam mari, scopu-i sa facem treaba.

  18. Ba te omor, adică nu te omor, da' îmi susțin ideea, deci: [1]. Au avut cel puțin 5 release-uri anul ăsta? Au avut. Ceea ce înseamnă că oamenii nu au scos soft-ul și l-au lăsat să putrezească, deci fix cum am zis mai sus. Apache scot mai rar de atât, dar uită-te pe trackerele lor de bug-uri să vezi cum apar zilnic rapoarte chiar dacă, cum ai zis, e modular.

    În rest, tu primești update-uri de versiuni majore cam la fiecare upgrade de distro și update-uri de securitate mai des. Pentru că soft-ul respectiv trece printr-o tură serioasă de testare înainte să poată fi integrat în distribuție. Da' newsflash, asta nu înseamnă că o să ajungă pe mașini complet lipsit de bug-uri. Dacă se întâmpla asta, până acum mureau programatorii de foame. :)

    [1]: http://www.postfix.org/announcements.html

  19. @spyked
    Deci cum ? Softul e de ca ca sa nu moara programatorii de foame ?

  20. @Dr. A: lol. pei cum să nu, ori suntem comuniști ori nu mai suntem. :D

  21. Mircea Popescu`s avatar
    21
    Mircea Popescu 
    Wednesday, 22 June 2011

    @spyked Eu cred ca este o diferenta intre release-uri si update-uri. Este ?

    @Dr.A Asta-i tristetea cu lumea moderna, nimeni nu mai exista ca sa rezolve probleme, toata lumea exista ca sa conserve probleme, sa le agraveze, sa le ambaleze si vinda drept importante si alte cacaturi de aceeasi teapa.

    Cam asta-i si principalul motiv pentru care cred ca un mare macel e perfect inevitabil : lumea nu poate continua cu atita jeg pe ea.

  22. Păi release-ul de versiune nouă e echivalent cu un update major, așa. Adică fix partea cu feature-urile și alte tâmpenii neesențiale (sau...?).

    Da' uite, să luăm un alt exemplu: gcc. Apare arhitectură nouă hardware, undeva peste juma din portarea linux-ului pe ea e complet dependentă de portarea gcc-ului pe arhitectura respectivă. În rest, dacă vrei de exemplu ceva pentru optimizări de performanță serioase bagi un LLVM, care e la rândul lui proiect separat și se investește o groază de muncă în el. Și tu dacă nu stai să adaptezi softul la versiuni mai noi de gcc (asta în cazul în care nu ești mai catolic decât papa și respecți standardul C90 cu strictețe - și în 90% din cazuri nu ești mai catolic decât papa, tot din cauza performanței), clar n-o să se mai compileze cum trebe în țșpe ani de-acum.

    Și te gândești că na, mama lui, un compilator (adică program care să-ți translateze din C în cod mașină) îl scrii în cel mult două-trei săptămâni, nu? Ei, nu, nu prea merge.

    Adică io nu zic nu, poți la fel de bine să folosești în secolul XXI Red Hat 7.2 sau DOS sau mai știu eu ce, pe un 386. Nu văd nimic rău în asta (io blog-ul mi-l țin tot pe un Pentium III), da' asta nu înseamnă că ingineria în mediul software funcționează la fel ca în alte domenii. Și-s de acord că Firefox 3 e o prostie, că folosește mai multe resurse decât Firefox 2, da' pe de altă parte vezi cealaltă parte a paharului: tu ai azi, în 2011, hardware mai puternic decât în 2000, iar hardware-ul n-a fost făcut să stea în idle 50% din timp, ceea ce s-ar întâmpla dacă ai folosi Firefox 2 sau Lynx.

    De-aia, io-s pe jumate de acord cu chestia cu problema lumii moderne. Până una alta, producătorii de hardware scot chestii care consumă cât mai puțină energie (fiindcă clientul vrea telefon care să țină 5 zile și să știe să facă de toate), deci îi obligă și pe programatori să se gândească la asta când scriu softuri. Pe de altă parte da, un mare măcel e inevitabil și s-ar putea să se petreacă măcar parțial pe Interneți (a se vedea Stuxnet).

  23. Mircea Popescu`s avatar
    23
    Mircea Popescu 
    Wednesday, 22 June 2011

    Deci, problema din articol era push-ul de cacaturi irelevante, prost documentate si rau etichetate.

    Eu folosesc lynx chiar des.

  24. moot was invented by teh jews, it's a conspiracy.

  25. @Mircea Popescu Continuous deployment!

  26. Mircea Popescu`s avatar
    26
    Mircea Popescu 
    Wednesday, 22 June 2011

    Omg bbq!

  27. Intr-un fel sunt de acord ca ai putea face anumite softuri gata terminate. Ma gandesc ca daca twitter era updatat la fel de des ca anuntul.ro ar fi fost probabil mai bun decat e acum, in special pentru ca n-ar mai avea atatea cacaturi inutile, dar totusi, software-ul tre sa mai si evolueze, intr-o oarecare masura.

  28. Mircea Popescu`s avatar
    28
    Mircea Popescu 
    Wednesday, 22 June 2011

    Sa evolueze, da, da' ca orasele grecesti si ca fiintele vii, prin urmasi, iara nu ca orasele romane si cancerele, prin continua si delabrata razbolire.

  29. banatul`s avatar
    29
    banatul 
    Thursday, 23 June 2011

    @DrA @Mircea Popescu @spyked
    "Nu vreau sa fiu rau cu nimeni da compara tu numarul de poduri / arhitecti care stiu face poduri cu numarul de “programe” si de “programatori”. Dupa care ia distributia capacitatiilor intelectuale si vezi cam ce-ti iese."

    Da de ce compari arhitectii cu programatorii? Compara arhitectii cu arhitectii software, programatorii de pagini web cu muncitorii, cei care scriu algoritmi/programe mai complexe cu inginerii, etc.

    De asemenea, hai sa facem o diferenta intre podurile peste Dunare si sistemele de operare, si podetele din fundul curtii cu programele de contabilitate. Plus chirurgii cu chirurgii, si medicii de familie cu contabilii.

    Nici eu nu vreau sa fiu rau cu nimeni, asa ca o sa tac :P.

  30. Haha, deci data viitoare când mai pun anecdote din astea tre să scriu mare: „anecdotă, a nu se lua în serios (!1!!!11111oneeleven), a fost scoasă probabil de un om beat”. :D

  31. * care de fapt prin definiție nu-i anecdotă, ie așa o comparație puerilă, da' în fine. Trolling is a art, i shall not stand against it. :D

  32. Mircea Popescu`s avatar
    32
    Mircea Popescu 
    Thursday, 23 June 2011

    Poti tu sa pui ce disclaimar vrei, text shall stand on it's own, death of the author & all that :D

  33. Mircea Popescu`s avatar
    33
    Mircea Popescu 
    Thursday, 23 June 2011

    PS. Vaz ca onor banatul e fan al virtualizarii complete. Ca o intrebare de baraj : Curvele cu cin' le pui, domnu' ?

  34. Ce bine că n-am fost io autorul (am auzit-o de la un amic care și el la rândul lui a auzit-o de la altcineva care ce să-i faci, asta-i viața). :D

    Da' dacă inspiră trolatul, cu atât mai bine. Plus că mie îmi place să compar podurile cu sisteme de operare. Problema-i că n-am reușit să crap nici un pod până acum, pe când kernel panic-uri (și să nu mai vorbesc de BSOD-uri și alte bug-uri în kernel pe la OS-uri ceva mai obscure) am dat cu duiumul. Deci până acum comparația ține.

  35. Mircea Popescu`s avatar
    35
    Mircea Popescu 
    Thursday, 23 June 2011

    Pai nu tine, ca io de exemplu iti crap ce pod vrei si alegi tu.

    Obuze sa fie numa'.

  36. Păi stai, că rezistența la obuze nu cred că e în specificațiile podului. Pe când să nu îți crape mașina când apelezi apelul de sistem e o chestie necesară cam la orice sistem de operare respectabil.

    Și în windows cu un driver un pic mai bușit (ceea ce apropo, mă face să mă întreb cum se aplică chestia asta cu update-ul la drivere; e oleacă mai dureros, mai ales când ai cod dependent de arhitectură; da' na, de-aia există repository-uri unstable și versiuni beta) poți lejer să faci asta. Și și în Linux dacă nu a fost atent gogu care a scris driver-ul, se blochează într-o întrerupere și s-a dus pe apa sâmbetei tot sistemul (și asta se întâmplă mai ales la driverele care au bucăți proprietare în ele, cum mai au broadcom pe la plăcile de rețea wireless).

  37. Mircea Popescu`s avatar
    37
    Mircea Popescu 
    Thursday, 23 June 2011

    N-am inteles, da' ce, rezistenta la buffer overflow intra-n specificatiile os-ului ?!

    Io n-am avut inca sistem pe linux busit. Pur si simplu, nu mi s-o intimplat. Nu contest ca li s-o fi intimplat altora, dar eu n-am avut.

    A, c-or murit in flacari aplicatii, sigur ca da. Top-kill. Da kernelu' nu mi-o murit niciodata.

  38. banatul`s avatar
    38
    banatul 
    Thursday, 23 June 2011

    entropie.

    In cite moduri se poate construi si poate exista un pod ? Luind in consideratie toate aspectele relevante.

    Cite variabile exista intr-un kernel ? Care este numarul de stari posibile ?

    Chiar daca nu luam in consideratie bugete si cerinte, spatiul e incomensurabil mai mare in software decit in poduri.

  39. Mircea Popescu`s avatar
    39
    Mircea Popescu 
    Thursday, 23 June 2011

    Chestia asta mi-a amintit din ceva motiv de o fraza dintr-o bucatica de proza scurta de mai demult, "daca impresionistii ar fi fost dentisti", era ceva de genul "doamna X m-a dat in judecata pentru ca i-am pus un pod asa cum am simtit eu, nu asa cum i s-ar fi potrivit ei in gura".

    Revenind : nu cred ca s-a scris inca sistemul numeric mai complex decit realitatea.

  40. banatul`s avatar
    40
    banatul 
    Thursday, 23 June 2011

    De asta am zis toate aspectele relevante. Nu cred ca vreun arhitect de pod ia in consideratie starea atomilor din cuiul X la fiecare faza a satelitilor lui Jupiter.

    Dar ca sa nu ne incurcam in detalii, privind strict de la altitudine mare, spatiul evolutiv pentru poduri si spatiul evolutiv pentru software. Heck, cineva poate sa simuleze in software toate podurile posibile, deci primul e inclus in celalalt...

  41. Mircea Popescu`s avatar
    41
    Mircea Popescu 
    Thursday, 23 June 2011

    Pai cineva poate sa scrie pe-un singur pod toate programele posibile, deci idem.

  42. banatul`s avatar
    42
    banatul 
    Thursday, 23 June 2011

    Nope, nu ai destul spatiu, indiferent cit de mare il faci podul si chiar indiferent cit de multe poduri folosesti.
    Dar oricum, e irelevant, pentru ca un pod tot acelasi pod ramine, indiferent cum il vopsesti si ce scrii pe el.

    Ca sa clarific: toate astea nu sint o scuza pentru programe scrise cu picioarele, si update-uri peste update-uri. Cel putin MS mai nou (win7+) iti spune clar ce vrea sa instaleze, poti sa nu o faci si sa le ascunzi pe update-urile care nu te intereseaza.

  43. Mircea Popescu`s avatar
    43
    Mircea Popescu 
    Thursday, 23 June 2011

    @banatul Pai poate ca nu-l faci mare, poate ca pur si simplu scrii mic pe el.

    Deosebeste intre ce discutam noi (ca poti, adica), si ce discuti tu acuma (ca o chiar faci, adica). Arata-mi tu programul, sistemul, minunea in care nu ca poti sa simulezi toate podurile posibile, dar ai chiar simulat toate podurile posibile.

    @Darku Din pacate comentariul ti se pierduse prin avalansa, da' iata ca l-am recuperat.

    Pachetu' nici nu l-am instalat, da' totusi...

  44. banatul`s avatar
    44
    banatul 
    Thursday, 23 June 2011

    Nu, eu ramasesem strict in domeniul teoretic. Numarul de parameterii ai conceptului ingineresc de pod sint finiti, cunoscuti, si rasexplorati. Numarul de variabile / stari ale unui program in general, poate fi oricit de mare si poate include parametrii mai sus mentionati.

    Este unul din motivele pentru care comparatia initiala este inselatoare. Nu se poate compara un concept cu un domeniu de concepte.

  45. Mircea Popescu`s avatar
    45
    Mircea Popescu 
    Thursday, 23 June 2011

    Pai in termenii in care gindesti tu podul, parametrii programului sunt cunoscuti, finiti si rasextrapolati : incepe, executa niste instructiuni si finalizeaza. In schimb in termenii in care gindesti tu programul, podul este amplu nefinit : poate include de exemplu o statuie a unui gorgoyle de-ala. In care sa se gaseasca un macbook. pe care sa ruleze un program de simulat automate celulare nedeterministe.

    Cu alte cuvinte, cind gindesti probleme de-astea tre' sa ai grija sa tii ochii deschisi.

  46. banatul`s avatar
    46
    banatul 
    Thursday, 23 June 2011

    daca include mac-ul, nu mai e pod, e parte software, si are nevoie de updates.

    putem sa o sucim oricit, nu o sa imi arati niciodata un pod care sa nu poata fi modelat pe calculator, la fel cum nu o sa poti gasi un pod care sa poata sa modeleze programe (cel putin nu unul facut de niste constructori -- pornisem de la disputa "arhitect" vs "programator")

    (iar curvele le pun cu programatorii de virusi, desigur)

    gata, am facut destula galagie aparind onoarea breslei :).

  47. Mircea Popescu`s avatar
    47
    Mircea Popescu 
    Thursday, 23 June 2011

    Hahaha cica nu mai e pod. Da' de ce sa nu mai fie pod, ma rog frumos ?!

    Ti-ai format tu niste idei fixe si tii la ele, normal ca "n-o sa iti arat eu niciodata" daca tu esti cu destele-n urechi si lalala.

  48. @banatul
    nu programul proiecteaza poduri ci arhitectii. Dupa care tot injineri simuleaza chestii in program dupa criterii predefinite (si eventual scriu programe cand nu exista). Daca tu iti inchipui ca programele de ahitectura sunt facute in partile esentiale de programatori si nu de arhitecti atunci ar trebui poate sa reanalizezi.
    Conceptul de stabilitate se aplica si podurilor si softului. Atata ca unii il aplica mai competent decat altii.

  49. @Mircea Popescu

    Ce am scris eu era legat de afirmaţia: "un pachet software care primeste update trebuie dezinstalat".

    Dacă noile versiuni ubuntu ar apare când sunt finalizate şi nu ca acum (când apar la dată fixă) probabil ar fi mai puţine probleme sau lucruri de patch-uit. Asta având în vedere şi că cei care dezvoltă linuxul sunt oameni care fac asta din pasiune în timpul lor liber, fără să fie plătiţi.

    În rest, cineva care făcea un review la Fedora 14 zicea că a doua zi de la data lansării avea deja 50 de update-uri.

    Apropo: unde instalează Windows-ul chestii în umbră şi fără să te întrebe? Că alte softuri de la Microsoft eu nu folosesc.

    Legat de poduri: sunt mult mai puţine decizii pe care trebuie să le iei când faci un pod faţă de când implementezi un program oarecare. Dar se poate face o analogie între a ridica un pod şi a face un soft de un anumit tip, de exemplu un program de sortare binară. În ambele cazuri se ştie scopul lucrării şi algoritmul după care se va face.

  50. Mircea Popescu`s avatar
    50
    Mircea Popescu 
    Thursday, 23 June 2011

    Io cred ca marea problema aici e faptu' ca multa lume s-o jucat cu calculatoare si deci crede despre sine ca-i programator, da' poduri n-o construit. Ca rezultat cele doua activitati primesc o coloratura specifica. Si daca mi-e permis un citat,

    Cine sunt ? Posted by: Petre
    Hai sa luam pe partea profesionala:- ma joc pe calculator de prin 92,[...]

    Pe tema cu windows si silent updates, vezi de ex 1, 2 etc.

  51. N-am inteles, da' ce, rezistenta la buffer overflow intra-n specificatiile os-ului ?!

    Absolut. Există gărzi speciale pe stivă pentru a proteja asta (în principiu compilatorul se ocupă de treabă, dar și OS-ul are safeguard-uri la încărcarea/rularea programelor), iar unul din rolurile memoriei virtuale e exact de a asigura că utilizatorul nu poate să acceseze ce zonă de memorie vrea el.

    Cu alte cuvinte, orice bug de buffer overflow e întotdeauna de prioritate maximă. În plus, verificarea formală a buffer overflow-urilor în cadrul kernel-ului e unul din cele mai tari subiecte de cercetare la ora actuală.

  52. Mircea Popescu`s avatar
    52
    Mircea Popescu 
    Thursday, 23 June 2011

    Da' io altceva am intrebat mei.

    Tu-mi raspunsi ca podurile moderne sunt echipate cu tunuri antiaeriene si rachete antiracheta, aia e din cauza de bombardamente continue si sustinute, nu din cauza ca asa e podu' notional construit, cu tunuri in el.

  53. Păi noa, chestiile astea nu erau standarde în SO-uri acum 20 de ani, dar acum sunt. Nu mai definești în 2011 un sistem de operare, oricare, fără „memorie virtuală”, „proces”, „fișier”, „socket”, „securitate” și „siguranță”. Cel puțin dacă ar fi să ne luăm după Silberschatz, Tanenbaum și alți câțiva din domeniu, care au scris grosul cărților conceptuale pe temă.

    Acum sigur, definiția poți să o lărgești și să o strâmtezi cât vrei până la urmă, fiindcă softul e o chestie mai puțin concretă decât podul. Dar în ziua de azi, unul din scopurile declarate ale sistemului de operare e să protejeze utilizatorul de probleme din astea cum e buffer overflow-ul. Asta nu înseamnă că n-o să îl poți face într-un cadru limitat (programul rulat în mediul utilizator), atât doar că n-ar trebui să poți să crapi sistemul cu el. Dacă merge să faci asta, atunci sistemul de operare e prost construit. De-aia nici Linux și nici Windows 7 nu mai crapă cu una cu două, fiindcă na, e imperativ să nu.

    Cred că se poate totuși pica Linux-ul din userspace (sau cel puțin îl poți face inutilizabil) cu un fork bomb: http://www.cyberciti.biz/faq/understanding-bash-fork-bomb/ . Practic alocarea memoriei nu o să ajungă să strice sistemul cu una cu două, da' crearea de procese noi s-ar putea să dea scheduler-ul peste cap. N-am mai încercat de pe la Linux 2.6.17, nu știu dacă au băgat mecanisme de protecție.

  54. Mircea Popescu`s avatar
    54
    Mircea Popescu 
    Thursday, 23 June 2011

    Nu prea merg fork-bomburile pe multicore pentru ca sistemul e in general suficient de inteligent sa pastreze toti puii pe-un singur core ca default si plaseaza administratia pe celalalt.

  55. @Mircea Popescu

    Este părerea ta. Dar dacă cine doar s-a jucat cu calculatoarele făcând un script simplu are impresia că a programa este mai complex decât a ridica poduri, îţi dai seama cine chiar a programat ce impresie are...

    Pe de altă parte, eu cred că mulţi oameni sunt perfect conştienţi că nu-s programatori, dar încearcă să pozeze în asta. Sau fizicieni. Sau critici literari. Etc. Dar, din nou, este părerea mea....

    Şi analogia ta cu podurile dotate cu sisteme antirachetă nu e bună. O analogie mai bună ar fi cu maşinile de tonaj mare care s-ar putea să treacă pe aceste poduri. De altfel, gândeşte-te ce uşor ar sparge un hacker un sistem de operare principiul că hai să nu tratăm excepţiile că nu e treaba noastră. Apropo, ştii de ce am formulat excepţii şi nu erori?

  56. extra ordinar.

  57. banatul`s avatar
    57
    banatul 
    Saturday, 25 June 2011

    @Dr.A eu nu vorbeam despre programe de arhitectura, vorbeam despre programe de simulare. Incercam sa fac o dovada a complexitatii.

    Mai incerc odata, in termeni non-computationali:

    Tu spui ca programele sint instabile pentru ca programatorii sint incompetenti, si ca dovada aduci faptul ca podurile sint stabile si nu se prabusesc, deci se poate.

    Este echivalent cu a spune ca organismele fac cancer pentru ca natura este incompetenta, si ca dovada aduci faptul ca o anumita specie de cristale, nu ai auzit tu niciodata sa creasca neregulat, deci uite ca se poate.

    Podurile nu se prabusesc pentru ca:
    - se aloca un buget disproportionat (relativ la complexitatea produsului final) pentru a se asigura redundanta necesara, pentru ca este o caracteristica esentiala a produsului
    - construim poduri de milenii, si principiile sint neschimbate, si cu putine variabile.
    - ciclul de viata al unui pod este mare

    Programele crapa pentru ca:
    - fiecare program software este diferit, cu arhitectura diferita, cu miliarde de stari interne pe care programatorii avansati le controleaza impartindu-le pe nivele arhitecturale si module, formind clustere pe care mintea umana le poate urmari pe fiecare in parte si in interactiuni. (Absolut nimeni nu poate sa constientizeze un program in intregimea lui, doar pe parti).

    - a nu crapa niciodata nu este o caracteristica esentiala ceruta de piata. Fiecare produs software are o toleranta mai mare sau mai mica la erori, in functie de cit e de critic sa functioneze perfect.

    - in consecinta, bugetul alocat unui proiect software nu include luxul de a face programul respectiv perfect. Atunci cind bugetul include acest lux, programul functioneaza perfect, end of story.

    - sint foarte multe tipuri de programe si de programatori, piata este in evolutie permanenta, tehnicile de programare sint in evolutie permanenta, cu cicluri de piatza mult mai rapide decit durata de viata a unui pod.

    Pe scurt, vorbim de lucruri complet diferite, care nu admit comparatie la nici un nivel.

  58. @banatul
    Eu explic ca un absolvent de "calculatoare" nu stie sa faca programe care sa testeze structura de rezistenta a unui pod. Pe de alta parte absolventii de constyructii civile au facut asta inainte sa existe calculatoare si dupa ce au aparut ai creat algoritmul de test.

    Genul de argumente adus de tine e tipic pentru o atitudine (incompetenta si extrem de costisitoare) de a programa aplicatii web dupa browser si nu dupa standarde http://mike.kaply.com/2011/06/23/understanding-the-corporate-impact/#comment-10697 cu care se cronfunta toata lumea.

    Vad ca totusi confirmi ca nu exista suficienti oameni competenti/inteligenti petru a creea toate aplicatiile soft realizate azi.

  59. Mircea Popescu`s avatar
    59
    Mircea Popescu 
    Saturday, 25 June 2011

    Sau, ca sa exprimam ideile lui Dr. A intr-o forma indulcita :

    Atit podurile cit si programele sunt eforturi umane destinate unui scop. Sub acest aspect, ele pot fi comparate. Chiar daca ele pot fi comparate sub acest aspect, discutia noastra nu a pornit de la aceasta comparatie, ci de la comparatia intre poduri si programe ca obiecte. Pentru ca pe linga a fi eforturi destinate unui scop, ele sunt si obiecte. Amanunt care ingaduie comparatia si sub acest aspect.

    Aceste observatii invalideaza teza ta cum ca "nu admit comparatie la nici un nivel", pe de-o parte. Faptul ca tu alegi sa discuti un efort indreptat inspre un scop (si nu pornit dintr-o cauza) este sursa prima si ultima a dificultatilor pe care le intimpini in reprezentare (atit obiectiv, in discutie, cit si subiectiv, imi inchipui).

    In rest, presupunerile legate de complexitatea diferita ramin in continuare invalidate, per comentariul #45.

  60. banatul`s avatar
    60
    banatul 
    Saturday, 25 June 2011

    Da, realizez acum ca aveti dreptate. Toti cei care termina calculatoarele sint incompetenti, dar cei care termina Arhitectura, Automatizarile, Matematica, Fizica, etc, sint mult mai competenti, iar programele lor nu crapa niciodata.

    Iar nivelul de complexitate al unui obiect static, cu componente continue/liniare este foarte comparativ cu nivelul de complexitate al unui obiect dinamic, cu multe stari discrete / non - liniare.

    (De asemenea, masinile se strica, deci rezulta ca trebuie sa includem si inginerii care construiesc masini in domeniul incompetentilor. Si sa nu uitam de greselile medicale. Pt ca, nu-i asa, daca podul poate, atunci toata lumea tre ca poate)

  61. Mircea Popescu`s avatar
    61
    Mircea Popescu 
    Saturday, 25 June 2011

    Asa! Recunoaste tot!

    Podul nu este mai static sau mai dinamic, mai liniar sau mai neliniar, mai continuu sau mai necontinuu decit orice altceva. Ca tu ti-l reprezinti intr-un model static-liniar-continuu in timp ce-ti reprezinti altceva dinamic-neliniar-discret nu inseamna neaparat ceva despre obiectele in discutie, se poate intimpla sa insemne ceva despre reprezentarile de le folosesti.

    (Ps zi si tu comparabil sa nu vina ceva grammar nazi cu figuri pe urma).

  62. banatul`s avatar
    62
    banatul 
    Saturday, 25 June 2011

    Gresesti, si stii asta. Totul in inginerie este reprezentare si abstractizare. Modelul folosit este totul. Cel mai simplu model utilizabil, spune totul despre complexitatea unui proiect ingineresc.

    Eh, ne pierdem in argumente, si nici macar nu e prea interesant subiectul. Daca voi vreti sa generalizati, n-aveti decit.

  63. Mircea Popescu`s avatar
    63
    Mircea Popescu 
    Saturday, 25 June 2011

    Ei da.

    Ia modeleaza-mi tu prabusirea unui pod lovit de-un asteroid. De curiozitate.

    Ce se intimpla daca un val de 15 metri loveste centrala nucleara de la Fukushima ?

    Ce se intimpla daca un avion nimereste un zgirienori ?

    Chestiile astea-s "statice", "liniare", "arhicunoscute", "banale" scl pina cind nu-s. Ca si orice altceva din natura, de altfel.

  64. Apropo, am înțeles că japonezii tocma au făcut un supercomputer care s-ar putea să-l depășească pe cel al chinezilor la performanțe. De ce? Păi pentru că Fukushima.

  65. Mircea Popescu`s avatar
    65
    Mircea Popescu 
    Saturday, 25 June 2011

    Pai da.

  66. @banatul
    vezi cam cati ingineri de poduri ies pe an in romania si cam cati programatori. Nici presupunand ca toti cetatenii inteligenti dintr-o generatie se fac programatori in loc de arhitecti medici matematicieni fizicieni, nu ajung sa acopere numarul de "programatori". Asta am zis eu si nu ca nu exista programatori inteligenti sau arhitecti prosti.

  67. @Dr. A: Crecă banatul had a point când a zis că nu poți pune programatorii în aceeași categorie cu inginerii de poduri din punctul de vedere al calificării. Programator poți ieși cu liceu și una-două certificări, pe când inginerul în calculatoare e cu totul altă mâncare de pește. Deci până la urmă, toată problema se reduce la „nu poți pune un programator să facă un soft complex mai mult decât poți pune un muncitor la poduri să proiecteze poduri”.

    A bun, că ies mulți studenți din facultățile de calculatoare, asta-s de acord. Dar foarte puțini în comparație cu câți economiști ies, dacă ar fi să extindem comparația.

    Deci cum ziceam, trebe pus disclaimer când vine vorba de discuții din astea care se întind pe 12 dimensiuni. :D

  68. Mircea Popescu`s avatar
    68
    Mircea Popescu 
    Saturday, 25 June 2011

    Cel mai util ar fi nu programul universal de proiectat poduri, nici podul universal de proiectat programe, ci o dracarie care cumva sa asigure ca toate proprietatile folosite intr-o discutie exista si-s compilate de catre toti discutnicii.

    Aia ar fi mare chestie.

  69. @spyked
    io-s de acord cu ce zici relativ la clarificari.

    Cred ca programatorii in general ies cu studii universitare nu cu liceu. Da is de acord ca rezultatul activitatii economistilor in general nu-i mai stralucit decat rezultatul muncii programatorilor.

  70. anonimosu`s avatar
    70
    anonimosuinsigna de prim sositinsigna de tehnolog 
    Sunday, 26 June 2011

    banatul= lotus?

  71. Mircea Popescu`s avatar
    71
    Mircea Popescu 
    Sunday, 26 June 2011

    E, sa nu exageram, majoritatea oamenilor au dificultati cu proprietatea termenilor si cu domeniile de definitie ale operatorilor, nu inseamna acum ca majoritatea oamenilor = un singur om.

  72. Mircea Popescu`s avatar
    72
    Mircea Popescu 
    Friday, 30 September 2011

    Lol deci uite aici o faza :

    linux-headers-2.6.32-34 (New Install)
    This package provides kernel header files for version 2.6.32, for sites that want the latest kernel headers. Please read /usr/share/doc/linux-headers-2.6.32-34/debian.README.gz for details.

    Changes for the versions:

    Version 2.6.32-34.77: [Steve Conklin]
    * Release Tracking Bug
    - LP: #849228

    [ Upstream Kernel Changes ]

    * Revert "drm/i915: Remove BUG_ON from i915_gem_evict_something"
    * Revert "drm/i915: Periodically flush the active lists and requests"
    * Revert "drm/i915/evict: Ensure we completely cleanup on failure"
    * Revert "drm/i915: Maintain LRU order of inactive objects upon access by
    CPU (v2)"
    * Revert "drm/i915: Implement fair lru eviction across both rings. (v2)"
    * Revert "drm/i915: Move the eviction logic to its own file."
    * Revert "drm/i915: prepare for fair lru eviction"
    Version 2.6.32-34.76:

    [Steve Conklin]

    * Release Tracking Bug
    - LP: #836914

    [ Upstream Kernel Changes ]

    * Revert "drm/nv50-nvc0: work around an evo channel hang that some people
    see"
    * Revert "eCryptfs: Handle failed metadata read in lookup"
    * Revert "tunnels: fix netns vs proto registration ordering"

    Deci bine ? Revert war ftw, ce bine ca facem update ca sa avem ce reversa.

    Idioti.

  73. Hm, în apărarea lor (că vorba aia, io ca zealot nu mă pot apuca să înjur devii de la linux), i915 e un GPU relativ nou, ce vine integrat pe Sandy Bridge-ul de la Intel. Acu', între a nu avea suport deloc pentru el și a avea un suport încă destul de slab, eu personal prefer a doua variantă.

    Problema fundamentală stă în faptul că, la fel ca orice bucată de hardware proprietar, procesorul cu pricina nu vine de la producător cu specificații complete, astfel că durează circa șase luni până la apariția unui driver open source stabil. De fapt cea mai multă muncă se petrece la partea de debugging, pentru că probabil Intel au venit cu un schelet de driver când a apărut procesorul.

    Cât despre restul trei patch-uri, nu știu ce-i cu ele, dar da, probabil că maintainer-ul nu trebuia să le accepte din capul locului.

  74. Mircea Popescu`s avatar
    74
    Mircea Popescu 
    Friday, 30 September 2011

    De ce imi introduci mie in LTS suport pentru chestii la care n-ai suport ? Inteleg, decit sa nu existe driver deloc e preferabil sa existe. Dar NU in 10.04, cind tu ai alta versiune stabila si inca alta versiune in lucru. Mi se pare logic ca daca io am ceva procesor nesuportat sa ma mut pe 11.04 sau 11.10, dupa caz. Nu mi se pare logic sa-mi populezi 10.04 cu cacaturi.

    * Revert “drm/i915: Move the eviction logic to its own file.” << asta ce-i ? Ca sigur, da' absolut sigur nu-i din cauza lui i915.

    Adica ma-ntelegi tu... putina seriozitate in gindire nu are cum sa strice.

  75. Păi stai o secundă, dacă-i LTS, atunci tre să ofere suport și pentru hardware-ul apărut (până) în 2010, și pentru ăla din 2011, idem pentru ăla din 2012, când dispare suportul. Deci eu dacă-mi pun 10.04 Long Term Support pe hardware-ul meu care a apărut cu un an mai târziu și nu-l suportă, atunci ce LTS mai e ăla? Ideea-i că oricum ai da-o, pe hardware-ul respectiv nu poți avea stabilitate garantată (ea poate este, da' nu-i garantată) pe linux deocamdată, pe nici o distribuție. Dar măcar ai un suport existent dacă te-a mâncat să-ți iei hardware de ultimă generație, ceea ce-i mai bine decât nimic.

    Sigur, tu dacă n-ai hardware-ul respectiv, atunci update-ul e degeaba, dar aici iar e problemă de dependențe și legată de faptul că kernel-ul fiind generic vine și cu suport pentru hardware pe care tu nu-l folosești efectiv.

    * Revert “drm/i915: Move the eviction logic to its own file.” << asta ce-i ? Ca sigur, da’ absolut sigur nu-i din cauza lui i915.

    N-am de unde să știu până nu mă uit în cod, dar toate bullet-urile alea par a face parte dintr-un singur patch, deci ori le dădea revert la toate, ori la nimic. Iar restul par a fi chiar rezolvări de bug-uri, nu refactoring.

  76. Also, update-ul respectiv vine la important security updates, sau cum le zic ei? Că dacă nu, poți da disable la canalul ăla de update-uri și le lași doar pe alea critice și măcar așa n-o să îți bage nimeni pe gât chestii inutile. Întreb, că nu am primit nimic de genul pe 11.04.

  77. Mircea Popescu`s avatar
    77
    Mircea Popescu 
    Friday, 30 September 2011

    Poate ca e o diferenta de filosofie aici, dar mie asa mi se pare logic ca un LTS tre' sa ofere suport pe termen lung pentru piesele vechi. Cu alte cuvinte, garantia implicita in LTS nu este ca vei avea in 2015 suport pentru piese din 2015, ci ca vei avea si in 2015 suport pentru piese din 2005, asa cum ai si azi. Ca altfel ce logica mai are, n-am inteles, stai pe ultima versiune si bing, ai suport pe tot ce iese nou. A, sigur, intre timp nu se mai suporta cutare cip din cutare placa de-a ta din laptop, da' nu-i problema, faci tu upgrade cu letconu'.

    Logic privind chestiunea, LTS este garantia ca un sistem care iti merge acuma iti mai merge inca X ani fara sa-i schimbi nimic.

    Sigur, poa sa fie "ori le dadea revert la toate, ori la nimic", dar in acest caz version control-ul e cam stupid, ca n-ar trebui sa ai refactoring-ul dependent de modificari de cod, daca esti sanatos la cap. Cine plm se apuca sa impleteasca refactoring cu modificari ? Cre' ca e gresala dezastruoasa numaru' 1 ce-o poti face, nici Sisoe nu-ti mai descilceste ce-i acolo daca se fute ceva.

    Si evident ca vine la Important, ca doara e cu kernelu'.

  78. Ce-i drept, și aici vina e tot a maintainer-ului, care 1.a acceptat un patch fără să-l testeze la sânge (deși fsm să mă ierte, oricât ai testa o bucată de hardware, la un moment dat tot te lovește cu o problemă dureroasă, da' fix când te aștepți mai puțin) și 2.a acceptat un patch care-i prost prin natura lui, adică nu rezolvă o problemă bine determinată, ci mai multe.

    După câte știu eu, chestia asta nu se întâmplă de obicei în linux-ul upstream, deci o fi într-adevăr prostia echipei din partea Canonical. Pe de altă parte, la fel de bine și Debian-ul nou (ăl cu Linux 3.0) are probleme, motiv pentru care eu încă stau pe Lenny pe server.

    Asta-i o oricum discuție un pic mai amplă, legată de faptul că mai toți dezvoltatorii de soft își scurtează ciclul de dezvoltare pentru a scoate în producție chestii cât mai repede. Și e greu de decis cum e mai bine, pentru că pe de o parte e frustrant să stai să aștepți x luni pentru un update nou (deși cu bugfix-uri nu ar trebui teoretic să se întâmple niciodată asta) și pe de altă parte toată lumea îi înjură pe producători când scot o chestie care nu-i încă matură, și pe bună dreptate.

  79. Mircea Popescu`s avatar
    79
    Mircea Popescu 
    Friday, 30 September 2011

    Apai acuma nimeni nu zice sa fie arsi pe rug sau ceva. Da' pe de cealalta parte, cine sta pe 10.04 si asteapta cu buza arsa drivere la nustiuce nou chipset nu e normal la cap, noa. Si idem nu-i normal la cap cine se ocupa cu rezolvat problemele percepute de aia care nu-s normali la cap. Parerea mea.

  80. Apropo de problema Canonical (care-s până la urmă o mașinărie de marketing și alte asemenea), tot am zis că încerc (da' n-am apucat) Linux Mint, care e bazat pe Ubuntu (sau Debian, după gusturi). Teoretic se vrea a fi cam la fel de ușor de instalat ca Ubuntu, doar că te scapă de toate rahaturile extra, cum ar fi shell-ul Unity (și chiar Gnome 3) sau Ubuntu One. S-ar putea ca ăsta să fie într-adevăr o soluție la toată problema cu branding-ul și marketing-ul și bla.

  81. Mircea Popescu`s avatar
    81
    Mircea Popescu 
    Friday, 30 September 2011

    Io deocamdata nu percep problemele alea, in sensul ca am dezinstalat toate cacaturile (cu dificultati pina la urma minore, in retrospect) si mnoa, asta e.

    Evident ca-i bien sa existe alternative, cum ii ziceam lu' Freud, daca astia o iau razna ii va inlocui cineva si gata.

  82. @Lotus:

    În rest, cineva care făcea un review la Fedora 14 zicea că a doua zi de la data lansării avea deja 50 de update-uri.

    Asta se întâmplă dintr-un motiv destul de simplu. Se preferă livrarea cu erori (buguri) cunoscute, livrării cu erori necunoscute. De altfel nici măcar în etapele etapele intermediare (alpha, beta) nu se trece dacă sunt erori prea grave, ci se amână până se rezolvă.

    Ca fapt divers că tot vorbim de conservatorism, atunci când se fac diverse teste precum EAL (Evaluation Assurance Level), odată ce ai dat softul și hardul spre evaluare, așa rămâne. Dacă schimbi ceva, o iei de la zero ceea ce e al naibii de costisitor. Momentan RHEL 5 (Red Hat Enterprise Linux) a ajuns la EAL 4+/CAPP/RBACPP/LSPP, iar Ubuntu mai are de așteptat/lucrat din câte văd eu. Nu e EAL mare brânză, dar e ceva acolo în special pentru guvernul american.

  83. Mircea Popescu`s avatar
    83
    Mircea Popescu 
    Friday, 30 September 2011

    E destul de mult acolo, de fapt.

  84. Dacă tot ați dat-o în suportul pentru hardware și LTS și în general despre politica actualizărilor, vă recomand să aruncați o privire și pe Red Hat Enterprise Linux Life Cycle. Prima etapă ce durează aproximativ 4 ani include Refreshed Hardware Enablement, după care o lasă mai moale. E un document interesant și merită aruncată o privire pe tabele.

  85. Mircea Popescu`s avatar
    85
    Mircea Popescu 
    Monday, 23 April 2012

    Drept.

  1. [...] Canonical incepe sa ma calce pe nervi [...]

  2. [...] trait s-o vad si pe-asta Luni, 23 Aprilie, Anul 4 d.Tr. | Autor: Mircea Popescu Canonical nu se lasa, semn ca-s pe drumu’ cel bun [...]

Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.