OSNews - Edd Dumbill, pomemben razvijalec in član projekta GNOME ter avtor knjige "Mono: A Developer's Notebook", je v svojem blogu strnil misli o nadaljnjem razvoju namiznega okolja. Izraža nezadovoljstvo nad uporabljeno tehnologijo in priporoča, da gre v prihodnje razvoj po poteh Novella in Mona ter Canonicala in Pythona. Izvirno sporočilo v Dumbillovem blogu.
Meni osebno ni jasno kaj tipu ni jasno?! Ce ga prav razumem zeli, da bi se nadaljni razvoj izvajal samo v jezikih/platformah kot so Python, Java in Mono. Ampak cemu!? Pravi, da mu ni usec, da mora vzdrzevat C kodo za Bluetooth knjiznice. A mu kdo to zapoveduje? A kje pise, da jih ne sme prepisat v katerikoli drugi jezik?
Call me dumb, ampak res ne vidim razloga, zakaj se ne bi mogel GNOME razvijati tako kot se sedaj, v vecih jezikih. Naj bo pac osnova v C, ker je potreba po hitrosti. Ostalo uporabnisko programje pa naj bo napisano v tistem jeziku kot komu pase. Mene kot koncnega uporabnika prav malo briga ali je program za GTK vmesnikom napisan v javi, c# ali pythonu - dokler opravlja svojo nalogo (dobro) in ima poenoten vmesnik z okoljem. Ce je ze point OSS developmenta deversity and choice, potem naj pac folk dela to in v tistem okolju/jeziku kar ga veseli.
Ali sem totalno ustrelu kozla?
Certainty of death. Small chance of success. What are we waiting for?
zakaj se ne bi mogel GNOME razvijati tako kot se sedaj Ker se oblikujeta dve skupini z različnimi cilji pri razvoju GNOME-a. Dokler ne bodo Monojevci silili ljudi v GTK# bo v redu, drugače bo pa fork.
Trou·bles, The [ee trúbb’lz] npl civil war in Northern Ireland: the political and civil unrest in Northern Ireland during the period from 1919 to 1923 and after 1969
Jebiveter: verjetno je tezava v tem, da ne mores kar tko mesat python, java in c#. Tecno je potem skupno funkcionalnost prepisat v c, ko bi jo rabil. C suxx za aplikacije, to se 100% strinjam z avtorjem kritike. Lahko pa vse nardis v c++ in se ne sekiras -> KDE. Ali pa vse baziras na enem VM-ju (java/.net). Tretja moznost je pa komponentno programiranje, samo pri njem se zreduciras na en storast subset vseh podprtih jezikov.
Eden je že prej mislil naredit GNOME fork, imenovan gonome oz. neki podobnega. Sam človek je sam govoril, skoraj nič pa ni naredit. Vse kar je od forka ostalo so patchi za zaporedje nekaterih dialogov. Mislim da je še "uradna" stran goneme še na netu.
Problem gnomea je pa precej velik. Sta dve strani. Ena je java in druga c#&mono naveza. Javo močno pritiskata Red Hat in Sun, Mono pa Novell z SUSE. In zdej se programerji enostavno ne morejo dogovoriti v kero smer. Neki časa se že tudi govori o gnome 3 (http://live.gnome.org/ThreePointZero) in o tem, kako bodo integrirane nekatere mono aplikcaije, a zaenkrat so to samo ugibanja.
"If you die, you die. But when you live you live. There is no time to waste."
Wrong! Wrong! Problem sploh ni v Javi, Python ali Mono/C#. Ker v končni konsekvenci so to le extenžni za GTK Lejte, problem je v "core" od Gnome!! Le ta je pisan v C-ju, kar je zelo zelo težko gledat in vpisovat vse tiste hudičeve parametre (kot so hadli windowsom, pointerji raznim strukturam in itd.)
Skratka, bottom line is.. programerji "core" Gnome imajo polen kufer C-ja!! Ker Miquel Del Icaza se je uštel, ko je leta 1996 začel razvijati striktno v C-ju, namesto kot kolegi pri KDE v C++. Poglejmo KDE iz verzije 3.3 v 3.4 so skodirali (vsi KDE developerji skupaj) okoli 60.000 vrstic kode v C++ in pri tem "našli&ubili" okoli 4.000 žuškov (beri: bug-ov) Podobno želijo rzvijalci Gnome in C je postal velika cokla! Razmišljali so, da bi celoten Gnome razvijali bodisi v C++ ali v Eiffel-u! Skratka v nekem naprednem objektnem jeziku, kot pa v C-ju. To je srž problema! Ostalo so pa le extenžni za ostale objektne jezike (Python, Java, C# in itd.).
To ni nič narobe, samo je pa narobe, ker je "core" ozr. "jedro" Gnome pisano v C-ju! Niso problem jeziki, ker so itaq to bindingi in ne igrajo nikakršne vloge!
Po domače povedano, problem je popravljat in vzdrževat knjižnice, ki so pisane v C-ju ki jih uporabljajo drugi jeziki.
Ker drugi jeziki (python, C#, java) uporabljajo GTK in Gnome knjižnice in te so napisane v C-ju. Ok !?
Ce je stvar lahko vzdrzevat, potem sploh ni vazno v cem je pisano. Ce imajo pa razvijalci s tem probleme in tezave pri nadgradnjih in izboljsavah, potem je pa tu tezava.
Sem ravno updejtal svoj GEnto na Gnome 2.10 in meni osebno se zdi zelo zabaven- oziroma recimo raje uporaben.
Zelo lepo dela, za razliko od marsičesa drugega v portage drevesu.
Kar se razvijalcev tiče, upam da se bodo že kako zmenili in da to ne bo ubilo relativne hitrosti zadeve.
BTW: Iz zornega kota laika: Kaj tako zelo manjka Cju kar ima C++ ? Ja, vem za ta OO crap ampak kot jaz to vidim, gre v bistvu za šminko, ki bi jo lahko realiziral tudi v Cju z malo discipline...
No, saj, bojo že sami našli rešitev.
Gnome je iz čiste mazohistične izkušnje prerasel v zelo lepo in uporabno okolje.
V tazadnji verziji lahko celo aktiviram service, nastavljam parametre mrežne itd. Ne bom spraševal, kako se to ujame z obstoječim gentoo frameworkom. Če dela, who cares in v tem trenutku je videt, da čisto lepo dela.
> Ja, vem za ta OO crap ampak kot jaz to vidim, gre v bistvu za šminko, ki bi jo > lahko realiziral tudi v Cju z malo discipline...
No ja, OOP ni samo sminka (ok res je, da je OOP marsikje overkill), ce se stvari pametno porabijo, potem znajo biti zelo uporabne. Vsega, kar se da v C++ ne mores izvest v Cju.
Verjamem, da so taki primeri, vendar je veloiko vprašanje, kako se ubogi compiler znajde glede optimizacije. In ker se vse na koncu prevede v assembler, ni vseeno kako se optimizira.
A ma kdo kake pametne izkušnje s tem ? Mislim, kako se C++ primerja s Cjem v nekih realnih primerih- glede na hitrost kode ?
Razlika v hitrosti je v prid C-ju, ako v C++ uporabljaš RTTI in izjeme, drugače pa le stvar uporabljenih knjižnic in uporabljenega prevajalnika.
OOP se kar pozna, četudi pustimo razne vzorce ob strani imaš še vedno dedovanje, ki precej zmanjša podvajanje kode in posledično možnosti za napako. Še dve veliki prednosti C++ za razvijalca sta reference in kalupe.
Ne gre se za hitrost kode. Hitrost je precej odvisna od prevajalnika. Dober prevajalnik za C++ je pa precej tezje narediti kot prevajalnik za C.
Gre se predvsem za preglednost kode in uporabnost, ter ponovno uporabnost. Torej dedovanje razredov. Ko imas nek razred, ki opisuje kako deluje en knof. Pa bi rad nekaj spremenil pri tem knofu, enostavno izpeljes razred moj_knof in popravis kar te muci, z vsem ostalim pa se niti ne obremenjujes, tisto ostane tako kot je bilo prej.
Hm, no, jaz sem bil vcasih hardcore C pristas, pa sem se premislil, ker C++ ima svoje prednosti in ce je kje uporaben, potem je to sigurno pri nekem desktopu. Tukaj se lahko izkaze.
Ne gre se za hitrost kode. Hitrost je precej odvisna od prevajalnika. Dober prevajalnik za C++ je pa precej tezje narediti kot prevajalnik za C.
Seveda gre za hitrost kode. Kaj mi bo desktop, ki se vleče ko razlita marmelada? Ravno zaradi tega feelinga sem prešaltal na GNOME in tu ostal.
Če vemo,da 99,9% procentov Linux populacije uporablja gcc, je kot na dlani, da bodo programi v C++ počasnejši. Razen, če bo verzija 4.x s svojimi izboljšavami tu sčasoma kaj prida not prinesla...
Seveda gre za hitrost kode. Kaj mi bo desktop, ki se vleče ko razlita marmelada? Ravno zaradi tega feelinga sem prešaltal na GNOME in tu ostal.
brez kakega branja med vrsticami, prosim. samo vprašam (nimam pojma o C, C++ in skoraj nobenemu drugemu jeziku). a se ti zdi gnome res hitrejši od kde? sam uporabljam gnome, samo ne zaradi hitrosti. hja, za kako stvar v gnome-u naredim še kak krog s palci več kot pa v kde. sicer sem pa enkrat bral ene smernice za *nix programerje in sem bil kar malo frapiran nad tem, da skoraj v vsaki točki je bila dana prednost preglednosti, enostavnosti, uporabljanju standardnih rešitev, odlaganja ultra optimizacij do točke, ko drugače več ne gre, itd... sploh pa naj bi bilo vse to še posebej važno pri open source projektih, kjer bi naj bilo dodajanje kode na umotvore nekega genija za povprečnega programerja, ki ima trenutno nekaj prostega časa, vse prej kot trivialno.
mogoče najdem link, sam verjetno sigurno tukaj kdo ve o čem laično in po slabem spominu govorim?
Tudi meni je gnome všeč, kot tudi kde, ... nevem pa kaj tip sanja, saj mas tudi za gnome na voljo http://gtkmm.sourceforge.net/, ki ga uporabljam tudi sam. Mogoče ja pa on malo zaspal in se mu zdi, da vse umira.
Med samim gcc-jem pa g++-som je tako malo razlike, da ni omembe vredno. Ja, se da narest take ultraumetne teste, kjer bo pure C koda 10% hitrejsa od C++. Vecinoma so to take stvari kot exceptioni, ki jih C nima. Je pa dejstvo, da si lahko v C++-su privoscis dalec bolj elegantno programiranje kot v C-ju, brez omembe vredne izgube hitrosti. Vcasih lahko celo pridobis na hitrosti (template-i) napram C-ju.
Od oka lahko recem, da 99.99% razlike v hitrosti (kakrsnokoli ste ze opazili) pri GNOME-u/KDE-ju odpade na izbrano arhitekturo sistema in algoritem za renderiranje graficnih komponent.
KDE ni pocasen, sploh od 3.x naprej samo pospesuje :)
Med C++ in C je ena velika in pomembna razlika, ki postaja vedno bolj pomembna: maintainance C kode je pri ustrezni uporabi jezika _bistveno_ drazji, kot pri C++ kodi (spet ob ustrezni uporabi jezika). Poglejte kdaj KDE kodo, pa boste videli, da zgleda proti gnome blazno lustkana (zato gre KDE tudi bistveno hitreje in skladneje naprej).
Nad gnome so izvedli kopico odlicnih idej, ampak ker je to free software, zdaj vecino dobrih idej najdemo v KDE, samo da praviloma delujejo bolje.
Pa meni se zdi KDE bistveno hitrejsi od gnome, ampak to verjetno zgolj zato, ker znam KDE oklestit vsega eye candy (tam na zacetku izberes best performance, namesto best looks :)
Ok, sem se vseeno zarekel. g++ generira tako kodo, da se zelo dolgo linka. To je verjetno tudi razlog, zakaj se KDE veliko dalj loada na zacetku kot GNOME. g++ 4.0.0 naj bi to obcutno popravil, se pa da zdaj zadeve resevat s prelinkanjem, nisem se pa s tem kaj veliko igral.
brane2: bighwhale in ostali ti hočejo razložit, da je razlika v hitrost minimalna če jo primerjaš z tem kar pridobiš na hitrosti pisanja kode in popravljanja..
je pa tudi nekaj res kar je en nad mano napisal.. da ni važno kako se tale foss koda piše samo da dela. mislim to mi je povsem zgrešeno, da nihče ne gleda na kake optimizacije. močno upam da se projekti kot je kernel, kde ali pa gnome ne držijo tega načela. recimo mozilla se kr tega drži, zato pa je taka debela bajsa.
En zanimiv link: Bounties for Gnome's Optimization. Samo zal je zgleda original objava mrtva, could not connect to server. Se pa spomnim glede optimizacij gnome-terminala - cilj je bil da ga spravijo vsaj priblizno na nivo potratnosti KDE konsole
btw.: Jaz sem hotel povedat da je izbira algoritmov neskoncno pomembnejsa od hitrostne razlike med samim c in c++. Recimo beosov GUI, ki naj bi bil zelo odziven (ne morem sam ocenit, ker nisem veliko uporabljal), je napisan komplet v c++. Zeta tudi uporablja g++. Mogoce pa bolje, da ne pisem tehnicnih razlag, ker bo nekdo ziher narobe interpretiral :)
Jasno, da se optimizirajo zadeve, da cim hitrejer laufajo. Saj ljudem je interesu, da stvari laufajo. Lej kde na primer, kot je ze jure povedal nekje, od verzije 3.0 naprej dela vsakic hitreje.
