Kontrolni centar za Debian/Ubuntu

[linux suks]

e ... ovak meni se ideja jaaako svidja i spreman sam pomoci... samo jedna mala digresija ... nebi se slozio iskljucivo sa jezikom c ... pogotovo zato kaj bi se bash skripte jako mogle evikasno iskoristiti pogotovo kod postavljanja ip adrese koristenja razno raznih naredbi itd... bolje se orjentirati na neki visi jezik pa se unutar njega mogu koristiti i ostali... c++ moze lako izvoditi c kod... python oboje ... a nisam siguran da obrnuto i ide bas


sucelje se moze jednostavno izvesti pomocu kdevelop paketa

[Tux Slave]

Od mene onda nema srece. Kosim se sa jezicima sto si naveo shrike. Jedino u cemu radim je C++/Qt i to onako sa zeljom da se zabavim. Ako se jos uvijek radi na ovome jedino sto mogu pomoci je IPTables i conf fileovi.

[shrike]

KDE ne dolazi u obzir. Kao što sam rekao, ovo je za Debian namjenjeno i Ubuntu, pa je GNOME u pitanju. Moja ideja je da stvar bude modularno sagrađena, tako da centralni dio programa može biti C, a ostalo po volji. Python je prespor za nešto realno. Da budemo jasni, što manje jezika to bolje. Potrudimo se da budu samo dva klasična jezika i dva skriptna pod maksimum. Ono što želim izbjeći je pisanje aplikacije koje se vrti ultra sporo i koja za sobom vuče boga pitaj što sve ne za sobom (tipa, python JAR, ...). C++ teži ka golemim dizajnima i megalomanskim programima. Što manje, to bolje. Gade mi se programi koji imaju 600 mb za nešto što nisam ni siguran što radi. C ima dobru infrastrukturu i brz je. To se broj. Trenutno ima previše aplikacija koje jedu jako, jako, jako puno resursa a među njima definitivno KDE drži primat.
Doduše, kad se probudim shvatim da ljudi rade najviše u C++-u, no meni taj jezik baš i nije najprivlačniji (trenutno).

Sad ono bitno. Mislim da jezik nije toliko bitan, jer sam razmišljao da se naredbe i konfiguracija nemora nužno direktno izvršavati, nego da algoritmi u klasičnim jezicima ispišu bash skriptu koja se izvrši. Poanta je u tome da bi se tako mogla kreirati jedna golema skripta koja bi se mogla koristiti za automatsko postavljanje sustava po želji nakon reinstalacije ili nakon masivnog zezanja po sistemu. Što mislite o tome?

Projekt je u fazi mojeg učenja. Tijekom ljeta moram proučiti Linux sustav u detalja, dodatno naučitit C i onda na jesen počet pistai prvi kod. Naravno, moramo se i svi složiti što će se i kako raditit.

[Sokac]

Moja preporuka je kombinirati C (i/ili C++) i Python.
Python za GUI jer je lakše raditi to u njemu, a C za izvršavanje jer je brži.

[shrike]

GTK2 za GUI, C/C++ jezici+skriptni po potrebi. Python je spor.

[shrike]

Zanima me da li je netko upoznat sa Plan9? Bil bi zgodno kada bi se mogla implementirati /net. Mogli bi imati ekipu koja bi se samo time bavila i shodno mogla pisati u kojem god jeziku želi.

[linux suks]

dakle ... kaj sada se radi kontrol centar ili ne ???

[shrike]

Kada počnu ferije počinjem a pisanjem. sada nemogu. Ispiti. Nemam vremena toliko se zezat sa programima i tražiti informacije. Ako si voljan pomoć ok. Sjeti se samo da ja nisam profesionalni programer.

[DoDo]

GTK2 za GUI, C/C++ jezici+skriptni po potrebi. Python je spor.

To je istina. Python je preespoor. Ako već kaniš koristiti spore jezike, uzmi javu - ona je "najbrži spori" jezik (tj. puuno sporija od C-a i C++-a, ali opet puuno brža od phythona i .net-a). Od jave bi se recimo moglo iskoristiti sučelje (GUI), makar smatram da je Gtk2 relativno sličan Swingu (nisam nikad radil u Gtk2-u, kanim početi ovo ljeto - treba mi jedan mali konfigurator servera). Što se pak tiče izbora C-a - to je dvosjekli mač - istina je da je najbrži, ali i najkompliciraniji - ubiješ se prilikom obrade stringova, dok je u C++-u i javi to maksimalno pojednostavljeno, uz cijenu nešto većeg potroška memorije i malo sporijeg rada, no to se može kompenzirati dobrim i brzim algoritmom. Također se prilikom programiranja u C-u i C++-u lako mogu pojaviti memory leakovi, a to moramo izbjeći pod svaku cijenu. Debugiranje je također mukotrpno u C-u i C++-u.

I još jedna stvar - u prvom postu si rekao da bi se pozivale naredbe koje obrađuju neke config fajlove - to je izvrsna ideja za neke "common-used" naredbe, no može predstaviti problem u slučajevima kad pokoja naredba nije dostupna na sustavu - tako da imamo opet dependencyje. Također imamo dependencyje ako želimo koristiti gtk2. Takav program se ne bi vrtio na debianolikoj distribuciji koja nema gtk libraryje instalirane (npr. kubuntu). Ako želimo napraviti softver koji bi se vrtio stvarno na svim debianolikim distribucijama (dakle debian, ubuntu, kubuntu, xubuntu, itd.), moj izbor bi bila java.

[shrike]

Ali gle, ideja je da je to program za Debian i ubuntu, ne za sve debian derivative ili KDE. Java je i dalje pre spora. Ako želimo imati takvu interoperabilnost, onda se može odmah pisati aplikacija u web pregledniku i radit će i na windwosu ,a ne samo na linuxu. Pitanje je čemu to kada se aplikacija piše za Debian/Ubuntu. Minimalno dodavanje gtk2+ kao dependency nije tako strašno jer će u svakom slučaju biti NEKI dependency. Druge disre već imaju svoj Kontrolni centar, da li je potrebna takva ultimativna prenosivost? C++ vodi na gradnju gigantskih programa. Ne želim imati program veličine 600 MB koji se jedva pokreće. Dakle, a pojednostavim, ne želim imati OOo-like aplikaciju koja se pokreće jako sporo i koja zauzima monstruozne resurse. Također, nemora biti unificirani način mjenjanja postavki. 90% uobičajenih stari se može napraviti izravnim izvršenjem narpede, za onih 10% program ispisuje skriptu u bash-u koja poziva standardne programe debiana i problem je riješen. Naravno, ako bude riječ o bizarnim programima, može se pribjeći alternativnom riješenju dependency problema: tako da uzmemo kod drugog programa i ukomponiramo ga u naš. Ako je moguće, naravno.

U kratko, ovo je moja ideja. Da se čitava stvar narpavi modularno. Znači ,svak imodul odrađuje specifičnu zadaću: jedna kontrolira multimediju ,jedan mrežne postavke, ... Svaki modul se može maknuti ili dodati interaktivno. Svaki progrmer uzme po jedna ili dva modula i radi na njima tako da se distribuira rad.