http://www.thewebsiteisdown.com/

KDE 4, asa cum a fost promis, ruleaza nativ sub Linux, Windows, OS X, mai pe scurt, sub orice platforma sub care este suportat Qt-ul celor de la Trolltech. Inainte sa apara eram destul de entuziasmat de vestea aparitiei KDE 4. Tin minte ca din intamplare citisem despre planurile ce tin de KDE 4 inca de acum 2 ani. Eram entuziasmat pentru faptul ca la vremea cand asteptam KDE 4, inca eram user de KDE 3 sub Linux. Faptul ca a fost promis nativ sub Windows/OS X nu a facut decat sa imi creasca entuziasmul.

O mica notificare ar fi faptul ca sub OS X rula KDE 3 si o buna parte a aplicatiilor ce tin de acest desktop environment, dar modul de rulare nu era nativ ci rula sub implementarea Apple a XFree86. Chiar am fost curios sa vad cum arata o mana de aplicatii KDE sub OS X si au iesit momente horror … aratau ca nuca in perete si faptul ca nu rulau nativ era destul de nasol la consistenta. Acum cica s-a rezolvat problema … astept sa vad cum arata treaba in teren.

Sub Windows lucrurile stateau putin diferit datorita anumitor restrictii ce tin de licentierea Qt 3. Da, KDE 4 respecta numerotarea versiunii majore de Qt sub care au fost dezvoltate … KDE 3 a fost dezvoltat sub Qt 3, KDE 4 sub Qt4. Nimic nou sub Soare. Odata ce problemele s-au rezolvat incepand cu v4 a Qt, acest fapt a permis portarea aplicatiilor si sub Windows.

Alaltaseara mi-am pus KDE 4 sub Windows. Installer-ul desi e grafic, cel mai probabil va pune probleme celor nefamiliarizati cu lumea *nix. Mi-e mi-a adus a installer de cygwin, deci concluzia rapida a fost ca baietii de la KDE nu au dorit sa reinventeze roata. Setup-ul a inceput in mod “uzual” – downloadarea pachetelor necesare din repository (uzual – cum ziceam mai sus, precum cygwin). Instalarea nu a decurs fara probleme. La anumite pachete setupul (v0.8.5 – cea mai recenta) claca fara drept de apel. Spre exemplu am dat sa instaleze toate tool-urile de development. Desi rar am avut nevoie de CVS cand de regula gaseam sursele gata arhivate, am dat sa instaleze si TortoiseCVS. Asta a fost OK. A crapat la instalarea TortoiseSVN pe care il aveam instalat deja din moment ce sunt SVN user, ce-i drept aveam o versiune mai veche. Clacatul se traduce prin 100% load si apasarea butonului de ‘Cancel’ se traducea prin proces care continua sa ruleze in background, dar nu facea nimic. Multumesc cerului ca setup-ul nu stie multi-core, deci sistemul nu a fost afectat substantial la viteza, sistemul mutandu-si chestiile pe core-ul celalalt al procesorului. Ar mai fi si alte pachete la care am intampinat probleme, si culmea, pachetele respective nu erau instalate anterior precum TortoiseSVN.

Utilizarea este de-a dreptul seaca. In primul rand trebuie rulate in terminal doua comenzi de configurare … nu am nimic impotriva, dar in documentatie caile erau indicate complet aiurea. Le-am dibut si am rezolvat. A urmat rularea aplicatiilor propriu zise. Practic installer-ul pune executabilele si dll-urile in directorul bin care se gaseste in directorul de instalare al KDE 4. Cum ziceam la un moment dat, poate fi putin ciudat pentru un user nefamiliarizat cu *nix. Pentru mine a fost OK, atata ca in bin este un haos de nedescris. Am dibuit niste chestii cunoscute, le-am rulat, a fost relativ OK. Prima executie a fost mai dureroasa in sensul ca tre sa isi faca in prealabil o chestie care ruleaza in background, dupa care nu mai sunt probleme. Aplicatiile se integreaza bine ca aspect printre celelalte. Inafara de cateva butoane si alte chestii tipice KDE, aplicatiile arata bine. M-am jucat cateva jocuri ce vin in pachet, am editat niste fisiere text folosind Kate si Kwrite, m-am dat pe net cu Konqueror. Desi am fost incantat, inca nu am vreun gand de inlocuire a unor aplicatii ce le folosesc deja sub Windows, exemplu Windows Explorer-ul pimpuit sa il dau la o parte pentru Konqueror din motive de varii instabilitati, feature-uri care nu functioneaza sau nu functioneaza corect, etc. Poate cel putin nu pentru moment. Mai este de lucru … atat la stabilitate cat si la uzabilitate. Oricum, KDE 4 sub Windows inseamna o mana de aplicatii, si nicidecum un full desktop environment, ceea ce lasa un gust semi-amar in gura.

Sub Linux totul a fost destul de scurt … dupa aproximativ 15 secunde de gugălit am gasit un repository neoficial in care sa fie KDE 4 pentru ubuntu. L-am instalat usor pentru ca package managementul si-a facut treaba. Mici probleme au fost la anumite aplicatii specifice, desi in general treaba a mers OK. Desktopul plasma arata bine, pare o revolutie peste KDE 3, desi mie inca nu mi-a sters impresia ca Vista Sidebar cu ale lui gadgets s-au mutat si s-au intins pe tot desktop-ul. La un moment dat a inceput chiar sa ma enerveze acest aspect. Interfata este mult mai bine lucrata din punctul de vedere al consistentei fata de KDE 3, multe chestii seamana, dar la anumite optiuni de configurare nu s-au eliminat dialogurile interminabile si putin uzabile. Am incercat sa schimb stilul ferestrelor de pe Oxygen (cel implicit si fresh pentru KDE 4) pe alte stiluri tipice KDE 3, dar a dus la scaderea caliatii vizuale. Oricum, la nivel de interfata, vizual vorbind, KDE 4 este peste KDE 3, desi inca nu s-au reparat unele din pacatele trecutului. Ce am apreciat a fost faptul ca s-a implementat meniul tabular care are motor de cautare pe care il stiu de sub openSUSE.

Aplicatii nu am prea testat pentru ca sincer nu ma interesau aplicatiile in sine, ci desktop environment-ul. Oricum, aplicatiile tipice KDE le rulez cu succes si sub Gnome, si chiar daca arata putin ciudat, tot raman in sfera acceptabilului. Desi de aproximativ 4 luni am trecut de la KDE 3 la Gnome, sincer sa fiu, nu m-as mai intoarce nici pentru KDE 4. In plus, desi initial erau o mana de chestii care in KDE le gaseam imediat si sub Gnome sapam dupa ele, cu timpul situatia s-a inversat. Exact aceasta a fost senzatia cand am trecut acum din sesiunea de Gnome in cea de KDE 4. Au inceput imediat sa imi lipseasca chestii, sa ma enerveze alte chestii, sa imi lipseasca Compiz-Fusion (da, dupa un an si ceva de OS X – am ramas fan al desktop-urilor 3D).

Pe total KDE 4 a fost pentru mine o semi-dezamagire, sau poate ca asteptarile mi-au fost prea mari. Vom vedea ce vor aduce versiunile mai noi, pentru ca desi e release, mie inca nu imi sterge impresia de preview release.

Chiar si Google, YouTube, Yahoo sau Wikipedia, FaceBook, Nokia folosesc platforma MySQL. Este nu doar o platforma open source, ci si foarte buna, stabila, usor de instalat, administat sau upgradat ulterior. Sun Microsystems vrea sa transforme solutia MySQL intr-o plartforma pentru companii.

Serverul de baze de date MySQL produs de compania MySQL ocupa aproximativ 80% din piata serverelor Web, un fapt bine cunoscut de altfel. Sun se asteapta sa dea lovitura cumparand MySQL prin integrarea serverului de baze de date in solutiile oferite de acestia, marind in acelasi timp canalele de distributie MySQL.

Avand in vedere cota de piata MySQL, se poate spune cu usurinta faptul ca aceasta tranzactie va schimba fata Internetului prin prisma impactului pe care il va avea aceasta tranzactie.

“Cumparam astazi o solutie pentru baze de date care a fost aleasa de clientii din toata lumea cu o viteza extraordinara”, a spus Schwartz. “Titanii web-ului folosesc toti MySQL, banci, companii auto, toate firmele din Fortune 500 folosesc MySQL”, a adaugat el.

Chiar nu mai am nimic de adaugat … speechless …

Sursa 1 Sursa 2 – oficiale

Sursa 3 – neoficiala

Stateam si ma gandeam zilele acestea la o metoda de a proteja anumite aplicatii de accesul neautorizat in ceea ce priveste accesul fizic la o masina. Problema sta cam asa: un sistem securizat priveste utilizatorul ca un potential risc … deci nu este o entitate in care se pune incredere (si bine face, dar despre asta in episodul urmator). Chiar daca utilizez deja sistemul sub un cont de user dupa cum va povesteam aici, browserul, clientul de mail au master password care cripteaza parolele stocate in managerele proprii … sistemul prezinta o vulnerabilitate asupra accesului direct …

Se intampla sa vina prieteni pe la mine (din care unii evident – impart ocupatii asemanatoare), si cum nu am o masina dedicata pentru fiecare chestie in parte, sa zicem ca muzica canta de pe aceeasi masina de pe care fac development, browsing, si alte chestii. Momentan mi s-a pus pata pe cookie-uri, desi exista si alte date confidentiale care ar trebui sa ramana pe disk-urile proprii si numai acolo. Daca eu, ca detinator al sistemului … folosesc un model de securitate prin care eu nu sunt crezut fara autentificare ca superuser … de ce ar fi altii crezuti? Simplu … ei nu ar trebui sa fie, dar sunt. Browserul isi stocheaza profilul in directorul de “user data”. Chestia asta e valabila si sub *nix … deci vorbesc la cazul general, indiferent ca e vorba de /home/{user_name} sau de %systemroot%\Documents and Settings\{user_name}\Application Data (pe scurt %appdata%). Din moment ce browserul ruleaza sub un anume user … drepturile din “user data” sunt drepturile complete ale aceluiasi user. Simplu ca buna ziua. De ce nu mi-as crede proprii prieteni? Hmm … nu stiu … cred ca de cand am inceput sa citesc documentatie despre securitate … am devenit paranoic. In fine, sa continuia asupra ideei lansate.

Morala este simpla … se creeaza un utilizator cu acces limitat. Sub Windows (prin modelul prezentat in articolul anterior dedicat acestui fapt) este obligatoriu ca acesta sa aiba parola diferita de o parola nula pentru a permite utilizarea runas. Sub *nix este necesara prezenta loginului daca nu exista sudo, in caz contrar un sudo su {user_name} – ar loga un utilizator fara drept de login. Smecheria asta cu sudo am descoperit-o cand ma chinuiam sa dau drepturi de acces unui server HTTP (Apache 2) la un director SSH montat ca local prin sshfs. Solutia a fost sa montez directorul ruland comanda de mount de sub userul serverului … dupa ce in prealabil am dar acces mai larg la montare.

Dupa ce utilizatorul este creat … se muta user data-ul in directorul userului nou, se interzic drepturile de acces (citire) in ceea ce priveste fisierele utilizatorului (in cazul in care grupul/others au acces de citire la fisiere), iar aplicatia care se doreste a fi rulata protejat, se ruleaza folosind noul utilizator … astfel in momentul in care aplicatia este inchisa … datele sunt in siguranta. Ideea este simpla … punerea in aplicatie cere niste consum de taste in plus.

Apropo de paranoia care o ziceam mai sus … nu e 100% absurda. Au existat cazuri (da, la plural) cand din vina prietenilor mei, primeam acces la datele lor fara sa fac efort … mi se oferea un authentication_id (o metoda stupida de a autentifica calculand un hash obosit pentru a scuti utilizatorii unui site de actiunea de a tasta user+pass – si care ramane constant daca se schimba parola – deci algoritmul de generare este prost pentru ca nu stie de modificari, securitatea este precara datorita faptului ca un URL de acest gen este trimis in mod plain text prin retea), sau o usa de acces la chestii din sistem – si evident – nu ratam ocazia unui prank de zile mari. Motivul pentru care mi s-a pus pata pe cookie-uri care ar putea fi folosite pentru un prank la adresa proprie … motivul pentru care am varsat literele de mai sus … cu un singur catch … aplicatia nu trebuie sa ruleze ca utilzatorul respectiv in momentul in care se primesc vizite dupa modelul celui de mai sus (si chiar in general).

Disclaimer

O sa le tratez pe rand.

1. Masinile virtuale cele mai uzuale sub OS X sunt Parallels Deskop si VMWare Fusion. Ambele sunt produse disponibile sub o licenta comerciala, deci trebuie sa platiti pentru acestea. Initial Parallels era peste VMWare, dar intre timp s-au cam schimbat lucrurile. Cea mai interesanta chestie legata de VMWare este rularea rootless, adica aplicatiile de Windows pot fi scoase din mediul lor desktop nativ, si plimbate de colo-colo pe desktop-ul grafic al OS X.

Exista si o solutie open source, mai lenta si mai instabila numita Q. Q este un port Cocoa al emulatorului QEMU, si doreste sa devina alternativa OSS la masinile virtuale pomenite mai sus.

Linkuri utile:
http://www.parallels.com/
http://www.vmware.com/products/fusion/
http://www.kju-app.org/kju/

2. Utilizarea WINE/CrossOver presupune rularea aplicatiilor fara a necesita o instanta de Windows care sa ruleze deoarece WINE ofera un fake Windows API on top of UNIX.

Le-am pomenit pe amandoua pentru ca WINE este practic baza CrossOver. CrossOver este o solutie comerciala care se instaleaza din mediul grafic si ofera un management complet asupra pachetelor software de Windows instalate in “bottles”. Practic acele “bottles” sunt instante de “fake Windows” instalate pe baza WINE.

Avantajele utilizarii CrossOver sunt: consumul de resurse mai mic decat in cazul utilizarii unei masini virtuale, interfata grafica pentru managementul WINE (care vine sub forma de utilitare de consola).

Dezavantajele sunt: incompatibilitatea cu anumite pachete software Windows, viteza mai mica decat in cazul rularii WINE.

WINE ofera avantajul ca este free (Open Source), si in acelasi timp ofera o performanta ceva mai mare decat CrossOver. In schimb lucrul cu acesta necesita niste cunostinte de lucrul cu shell-ul. Deasemenea instalarea acestuia poate sa puna probleme in cele mai multe cazuri, deci aici intervine tutorialul.

Tutorial instalare WINE sub OS X:

Chestii necesare:
1 – DVD-ul cu OS X.
2 – MacPorts.
3 – Xcode cu X11 SDK.
4 – rabdare

1. Verificati daca exista urmatoarea aplicatie: /Applications/Utilities/X11. Daca nu exista, cautati-o pe DVD-ul cu OS X si instalati-o.
2. Downloadati si instalati MacPorts. http://www.macports.org/
Instalati/updatati urmatoarele pachete: freetype si fontforge. Daca nu stiti care sunt comenzile de update, scrieti in consola urmatoarele:

sudo port install freetype && sudo port install fontforge

Dati parola voastra cand este ceruta . Nu mai stiu daca sunt dependente unul de celalalt, deci comanda de mai sus ar trebui sa functioneze corect in toate cazurile. Trebuie sa aveti rabdare pana se compileaza pachetele, deoarece MacPorts este un package manager care instaleaza aplicatiile folosind surse.

3. Apple livreaza pe DVD-ul de instalare o versiune de Xcode Tools. Din pacate versiunea livrata nu este in stare sa compileze WINE deoarece da o eroare la compilarea fisierului mach.c. Este nevoie de o versiunea 2.4.1 sau mai mare, pusa la dispozitie de catre Apple aici: http://developer.apple.com/tools/download/ – este pachetul ala mare de 900 si ceva MB. Necesita inregistrare (e free). Dupa ce downloadati chestia aia mare, instalati/updatati (dupa caz) Xcode Tools, si deasemenea instalati/updatati (dupa caz) X11 SDK, care este disponibil in acelasi pachet.

4. Partea de rabdare este necesara acum. Daca ati facut cele mai de sus, atunci sunteti gata sa instalati WINE din surse folosind MacPorts. Tastati in Terminal urmatoarea comanda:

sudo port install wine

Dati parola voastra. Acum asteptati sa se instaleze. Daca procesul se termina fara erori (asa cum ar trebui), la sfarsit o sa aveti instalat WINE pe OS X.

Locatia de instalare a WINE de catre MacPorts este /opt/local/bin – important!

Inainte de a rula pentru prima data o aplicatie de Windows, este recomandat sa rulati:

/opt/local/bin/winecfg

Aplicatia aceasta creaza instalarea fake de Windows si configureaza WINE. Va crea directorul $HOME/.wine/drive_c/

$HOME este directorul vostru de Home din /Users ($HOME este environment variable – Google pentru detalii). .wine este un subdirector din aceasta, ascuns. In notatia UNIX directoarele/fisierele care incep cu punct (.) sunt ascunse. Pentru listarea lor in Finder utilizati scripturi dezvoltate in acest sens daca este nevoie, iar in consola se poate utiliza

ls -a

In interiorul lui drive_c veti gasi un director windows si unul Program Files care vor fi folosite de aplicatiile care au installere.

Aplicatiile de Windows se lanseaza utilizand comanda:

/opt/local/bin/wine nume_aplicatie.exe [parametrii]

Acei [parametrii] – sunt optionali si se utilizeaza doar la nevoie. de regula nu sunt necesari.

Ponturi:

1. pentru instalarea unui pachet .msi – exista installere care nu vin ca executabile, ci vin ca .msi care sunt executate de Windows Installer – folositi urmatoarea comanda:

/opt/local/bin/wine msiexec /i nume_pachet.msi

2. este recomandat sa adaugati /opt/local/bin in $PATH. Daca faceti aceasta, veti putea rula mult mai usor wine si winecfg deoarece comenzine vor fi mai scurte. In loc de:

/opt/local/bin/winecfg

sau

/opt/local/bin/wine

veti rula simplu

winecfg

sau

wine

Cea mai usoara solutie este sa deschideti Terminal-ul si sa tastati:

nano .profile

nano este un editor text care ruleaza in text-mode, .profile este fisierul utilizat de bash pentru a defini setarile tipice pentru un user anume. Puneti acolo in fisier urmatoarea chestie:

export PATH=/opt/local/bin:$PATH

Daca exista ceva de acest gen in fisierul respectiv, spre exemplu exista deja o chestie:

export PATH=/usr/local/bin:$PATH

atunci adaugati locatia in modul urmator

export PATH=/usr/local/bin:/opt/local/bin:$PATH

Nota: caile catre directoare trebuie sa se termine in (:). Mai sus am doua cai, deci se observa faptul ca am utilizat de doua ori acele (:).

Salvati fisierul folosind Ctrl+O si inchideti editorul folosind Ctrl+X. Restart la aplicatia de Terminal.

3. Nu utilizati teme de Windows pentru WINE. O sa arate aplicatiile ceva mai bine, dar chestia aceasta va duce la o scadere dramatica a performantei.

Atentie:
Am uitat sa adaug: rularea aplicatiilor cu WINE se va face deschizand aplicatia X11 din /Applications/Utilities. Se utilizeaza consola acestuia (xterm) si nu Terminal pentru ca in caz contrar, wine nu va rula pentru ca nu gaseste Window Serverul. Pentru a putea utiliza fisierul de .profile, trebuie sa modificati setarile de la X11. X11 Menu >> Applications >> Customize Menu, iar acolo comanda ‘xterm’ se seteaza ca ‘xterm -ls’ pentru a-l face login shell. Se rezolva problema .profile si a X Window Server care sa convietuiasca pasnic.

Disclaimer