un argument împotriva închipuitei fragmentări a ecosistemului android

sâmbătă, 17 nov. 2012, 12:35

Acest articol poate fi considerat o prelungire a breviarului istoric ARM, în mare pentru că ilustrează cu mai multe amănunte implicațiile pe care le aduce varietatea dispozitivelor și platformelor bazate pe arhitectura ARM. După cum bine știm deja, problemele software-ului se mapează de multe ori unu la unu pe cele ale hardware-ului de dedesubt, motiv pentru care argumentul va fi extins la proiectul care face cel mai bine uz de această varietate, și anume sistemul de operare Android [i].

Zisul argument vine împotriva tuturor gurilor rele care susțin sus și tare că „Android e un mediu fragmentat”, spre deosebire de iOS-ul de la Apple care nu este și nici nu are cum să fie, dat fiind că vine într-o unică varietate pe o unică platformă hardware (plus minus una-două), bazată tot pe ARM. Cititorul se poate lămuri în legătură cu problema printr-o căutare pe Google după „android fragmentation”, care întoarce literalmente sute de rezultate relevante. Sigur, așa-zisa fragmentare s-ar putea să fi fost o problemă pe versiunile 2.x de Android [ii], însă clar nu se mai poate vorbi despre așa ceva la nivelul Android 4.x, pentru că vedeți în continuare. (mai mult…)

  1. În mod normal câștigătorul ar trebui să fie mediul GNU/Linux, care însă consider că are mari lacune la nivelul portării interfețelor cu utilizatorul și a altor aplicații posibil dependente de arhitectură. [↩]
  2. Care într-un mod ironic acoperă cea mai mare parte a dispozitivelor mobile cu Android de pe piață la ora actuală. Chestia o să devină istorie într-un timp foarte scurt, dacă nu luăm în calcul chinezăriile foarte ieftine, ci doar pe cele suficient de fiabile. [↩]

proiectele closed source sug (uneori)

sâmbătă, 1 sept. 2012, 13:58

[ studiu de caz. ]

Afirmația de mai sus nu vrea să implice faptul că proiectele open source nu sug (uneori), ci că pur și simplu proiectele closed source sug, adică-s nașpa în diferite feluri și din mai multe puncte de vedere, în funcție de ochiul care privește. De exemplu în opinia lui Richard Stallman [i] „closed source”, sau mai bine zis „non-free/libre software” este sursa răului absolut, pentru căcum să ai tu în casă o unealtă pe care să nu o poți modifica după bunul plac, de parcă oamenii incompetenți tehnic – adică majoritatea utilizatorilor de calculatoare – ar fi interesați de asta. Eu aleg să discut aici un punct de vedere mai relevant și absolut practic, și anume eficiența dezvoltării proiectelor software.

Discutam acum ceva timp despre eficiența proiectării programelor pe calculator. Deși aspectul are o importanță deosebită în ceea ce privește fundamentele ingineriei software, lucrurile se complică foarte mult în viața reală, acolo unde apar probleme de coordonare, deadline-uri, secrete și alți astfel de dragoni mai mult sau mai puțin plăcuți. Cu alte cuvinte gradul de „închidere” al unui proiect și dificultatea de mentenanță a acestuia sunt corelate pozitiv fără doar și poate, demonstrația fiind pe cât de evidentă pe atât de banală. În același timp livrarea pe piață [ii] e unul din factorii care pot face diferența între un proiect de succes și un rateu, dat fiind că clienții au nevoie de produs ieri [iii], nu peste un an. Nucleul Linux e în mod evident cel mai bun exemplu de succes, pentru că organizarea sa e de așa natură încât îmbunătățirile sunt aduse în (sau aproape de) producție în maxim trei luni de la apariția hardware-ului – nu musai pe piață. Dar să lăsăm Linux pe altă dată. (mai mult…)

  1. Despre care am putea presupune că contează ca ideolog al lumii software, el fiind unul din cei care au reușit să imprime avântul necesar apariției unor comunități de dezvoltatori care să producă așa-zisul „free software”. Eu am dubiile mele în privința individului, dar în fine, ce-i al lui e al lui – emacs de exemplu. [↩]
  2. i.e. „time to market” [↩]
  3. Și nu, acesta nu este un sofism. Gândiți-vă în felul următor: eu, client fiind, mă gândesc astăzi că mi-ar folosi chestia X. Eu nu sunt capabil și/sau nu îmi doresc să produc X, însă sunt dispus să plătesc mâine. Ori dacă X nu-i disponibil mâine pe piață iar eu m-am gândit deja că îmi doresc X, atunci se poate spune – cam tras de păr aș zice eu – că potențialii vânzători de X – actualii dezvoltatori – lucrează deja în pierdere. Cu alte cuvinte există întotdeauna un risc asociat „supra-marketării”, care poate genera mai mult „hype” decât este necesar. [↩]

tutorial: construirea unui mediu minimal bazat pe gnu/linux

sâmbătă, 18 aug. 2012, 00:47

Acest text pe care eu l-am numit „tutorial”, nu este – v-am mințit – de fapt un tutorial propriu-zis, ci mult mai puțin de atât. Problema cu tutorialul stă în faptul că nu m-am trezit eu atât de muncitor încât să stau să explic omului pas cu pas, amănunțit, cum să își construiască un mediu de programe, Interneții oricum dând pe dinafară de așa ceva. Și nu numai asta, dar trăiesc cu nădejdea că nu s-au trezit cititorii mei atât de proști încât să nu poată improviza cu Google în față, primind de la subsemnatul doar un set de idei generale care să îi ghideze spre soluție.

Să descriem întâi pe scurt lumea desktop-ului Linux așa cum se prezintă dânsa la ora actuală: un haos de nedescris. Anticipam într-un articol trecut că probabil nici 2011 nu va fi anul desktop-ului și pot spune cu aceeași tărie că lucrul e valabil și în cazul lui 2012 și poate și în ceea ce privește 2013 și 2014. În același paragraf susțineam sus și tare că dacă lucrurile se împut îmi bag picioarele în toate distribuțiile lor fancy și revin la ceva mai „basic” și sănătos și m-am ținut de cuvânt, ocazie pe care o voi folosi pentru a vă povesti cum am făcut asta și în ce stadiu am ajuns. (mai mult…)

mediul de programe unix: descrieri, exemple.

duminică, 24 iun. 2012, 17:32

Un aspect pe care l-am omis când am analizat interacțiunea cu calculatoarele ca act de comunicare este acela că modul text are și el interfețele lui pseudo-grafice. Astfel pentru a distinge între linia de comandă și interfețele text folosim sintagma „Text-User Interface” sau TUI. Acestea sunt prezente în lumea calculatoarelor încă de la începuturile acesteia, fiind incluse și în DOS și Windows {1,2,3}.0 [i], având însă un grad mare de răspândire în lumea *nix.

Povestea pleacă de la faptul că la un moment dat a existat nevoia ca terminalele virtuale să fie independente de mașina fizică pe care rulează. Astfel au apărut bibliotecile terminfo și termcap, peste care au fost dezvoltate curses și mai apoi ncurses. Ultimele două au un API care îl ajută pe programator să aranjeze textul și să deseneze chestii cum dorește dânsul, dând astfel naștere unei interfețe care să fie mai intuitivă pentru utilizator decât CLI-ul.

Ceea ce mulți utilizatori Unix [ii] nu știu sau nu vor să știe e că traiul zilnic poate fi dus la fel de bine înafara modului grafic, ceea ce e mai ales util în cazul în care nu vrem să fim deranjați de chestii frumos colorate. Prin urmare vom purcede la a face o listă a programele de bază care alcătuiesc sau pot alcătui după pofte și nevoi mediul zilnic al unui utilizator Unix – cu mențiunea că unele din ele s-ar putea să fie disponibile decât pe GNU/Linux, din motivul că utilizatorii de BSD sunt probabil prea preocupați să-și miroasă bășinile pentru a le porta; glumesc, dar adevărul e pe undeva prin zonă. (mai mult…)

  1. Care-i de fapt un TUI foarte împopoțonat și cu suport mai bun pentru mouse. [↩]
  2. Adică inclusiv de Linux, chiar dacă Linux e prin definiție „not Unix”. [↩]

cum reducem consumul de energie al pisiului

duminică, 17 iun. 2012, 17:35

Articolul de față nu își propune să dea apă la moară ecologiștilor și altor specii formate din indivizi mai mult sau mai puțin ciudați care populează grădina vastă a Domnului. Cu toate astea o să merg până la a afirma că consumul de energie e o problemă importantă pentru viața de zi cu zi a individului mediu; în primul rând pentru dispozitivele gen laptop, pentru care optimizarea consumului de energie prelungește viața bateriei și asigură funcționarea în timpul călătoriilor lungi cu trenul sau cu avionul; în al doilea rând pentru dispozitivele desktop sau server, a căror funcționare se regăsește într-o oarecare măsură pe factura de energie electrică.

Acestea fiind spuse, să presupunem că rulăm o distribuție GNU/Linux oarecare cu un nucleu aflat la 3.0 sau mai nou. Hardware-ul trebuie și el să fie Intel, pentru că AMD au susținut sus și tare că nu prea sunt interesați de problema sus-numită. Procesorul ar fi de preferință să fie minim Core i3, având în vedere că Core-urile în general și i-urile în particular au facilități de power management destul de bine puse la punct. Pașii necesari (dar nu musai și suficienți) sunt următorii: (mai mult…)

« Articole mai vechi