Canonical incepe sa ma calce pe nervi
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!
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.
Wednesday, 22 June 2011
tu chiar citesti lista lu' peste?
Wednesday, 22 June 2011
Io-s om serios, ce pielea.
Wednesday, 22 June 2011
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.
Wednesday, 22 June 2011
Plm ii stie, asa au ei impresia ca-s feshan.
Wednesday, 22 June 2011
deci ti-ai tras teapa singur.
Wednesday, 22 June 2011
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.
Wednesday, 22 June 2011
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.
Wednesday, 22 June 2011
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.
Wednesday, 22 June 2011
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.
Wednesday, 22 June 2011
Î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
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 ?!
Wednesday, 22 June 2011
moot approves this !
Wednesday, 22 June 2011
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.
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!
Wednesday, 22 June 2011
@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.
Wednesday, 22 June 2011
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).
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.
Wednesday, 22 June 2011
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
Wednesday, 22 June 2011
@spyked
Deci cum ? Softul e de ca ca sa nu moara programatorii de foame ?
Wednesday, 22 June 2011
@Dr. A: lol. pei cum să nu, ori suntem comuniști ori nu mai suntem. :D
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.
Wednesday, 22 June 2011
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).
Wednesday, 22 June 2011
Deci, problema din articol era push-ul de cacaturi irelevante, prost documentate si rau etichetate.
Eu folosesc lynx chiar des.
Wednesday, 22 June 2011
moot was invented by teh jews, it's a conspiracy.
Wednesday, 22 June 2011
@Mircea Popescu Continuous deployment!
Wednesday, 22 June 2011
Omg bbq!
Wednesday, 22 June 2011
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.
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.
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.
Thursday, 23 June 2011
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
Thursday, 23 June 2011
* 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
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
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' ?
Thursday, 23 June 2011
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.
Thursday, 23 June 2011
Pai nu tine, ca io de exemplu iti crap ce pod vrei si alegi tu.
Obuze sa fie numa'.
Thursday, 23 June 2011
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).
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.
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.
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.
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...
Thursday, 23 June 2011
Pai cineva poate sa scrie pe-un singur pod toate programele posibile, deci idem.
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.
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...
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.
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.
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 :).
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.
Thursday, 23 June 2011
@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.
Thursday, 23 June 2011
@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.
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,
Pe tema cu windows si silent updates, vezi de ex 1, 2 etc.
Thursday, 23 June 2011
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ă.
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.
Thursday, 23 June 2011
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.
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.
Thursday, 23 June 2011
@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?
Thursday, 23 June 2011
extra ordinar.
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.
Saturday, 25 June 2011
@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.
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.
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)
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).
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.
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.
Saturday, 25 June 2011
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.
Saturday, 25 June 2011
Pai da.
Saturday, 25 June 2011
@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.
Saturday, 25 June 2011
@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
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.
Saturday, 25 June 2011
@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.
Sunday, 26 June 2011
banatul= lotus?
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.
Friday, 30 September 2011
Lol deci uite aici o faza :
Deci bine ? Revert war ftw, ce bine ca facem update ca sa avem ce reversa.
Idioti.
Friday, 30 September 2011
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.
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.
Friday, 30 September 2011
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.
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.
Friday, 30 September 2011
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.
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'.
Friday, 30 September 2011
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.
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.
Friday, 30 September 2011
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.
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.
Friday, 30 September 2011
@Lotus:
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.
Friday, 30 September 2011
E destul de mult acolo, de fapt.
Friday, 30 September 2011
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.
Monday, 23 April 2012
Drept.