A méret a lényeg!

> Ezeket a kódokat rengetegen nézik át, sok egyetemista tanulja meg ezeken keresztül a programozás szépségeit.

Igen, pl. ilyen peldakbol(fs/namei.c):

+++

static int do_lookup(struct nameidata *nd, struct qstr *name,

struct path *path)

{

struct vfsmount *mnt = nd->mnt;

struct dentry *dentry = __d_lookup(nd->dentry, name);

if (!dentry)

goto need_lookup;

if (dentry->d_op && dentry->d_op->d_revalidate)

goto need_revalidate;

done:

path->mnt = mnt;

path->dentry = dentry;

return 0;

need_lookup:

dentry = real_lookup(nd->dentry, name, nd);

if (IS_ERR(dentry))

goto fail;

goto done;

need_revalidate:

if (dentry->d_op->d_revalidate(dentry, nd))

goto done;

if (d_invalidate(dentry))

goto done;

dput(dentry);

goto need_lookup;

fail:

return PTR_ERR(dentry);

}

+++

Nagyon szep, valamint a goto hasznalata Dijkstra ota helytelen!

A programozas szepsege nem a sokfele kez altal osszeganyolt ANSI C kodokbol tanulhato, hanem a megtervezett, specifikalt (objektumorientalt) projektekbol. Persze ha az az egyetemista coder es nem programozo, akkor rajta!

Na meg persze, ha az az egyetemista hulye, es nem akar penzt keresni a munkajaval, akkor nyugodtan pazarolja az idejet opensource projektekre (persze egyedi programoknal nincs gaz). A munkahelyeken nem azt kerdezik, hogy milyen opensource projekteken dolgoztal eddig, hanem azt, hogy milyen cegeknel dolgoztal, es milyen technologiakat ismersz, stb.

> Szerintem a GCC piaci részesedését megszorítani kizárólag egy olyan open source projekttel lehetne, ami kezdetben mindenképpen jelentősen támaszkodna a GCC kódjára

A GCC-nek milyen piaci reszesedese van? En meg nem lattam a polcon ilyen forditot, csak amikor telepitettem pl. egy GNU/Linux-ot, akkor ahhoz kaptam egyet ingyen, amiert nem fizettem. Piaci reszesedese a Visual C++-nak vagy pl. a Metrowerks Codewarrior-nak van.

Tudod kinek van piaci haszna a gcc-bol?

Pl. annak, aki a gcc-t, mint kiegeszito termeket hasznalja a PDA-ja szoftware-enek a leforditasara (Joel). O hasznalja a gcc-t, olcsobban adja a PDA-t, mert olcsobb a software, es szerintem rohog az opensource-os fejlesztokon, akik ingyen dolgoznak neki. Most, hogy mar egy ideje nagy cegek hasznaljak fel az opensource-os "termekeket", es nemcsak egy kisebb felhasznaloi tabora van a dolognak, hanem a hasznot elrakjak a nagycegek (RedHat, Novell, IBM, stb.), hulye, aki opensource kodot is.

Most tobb dologba nem kotok bele. :)

bocs.

A goto-rol megoszlanak a velemenyek. A strukturalt programozas alapjaiban valoban benne van a "keruljuk a goto, break, continue harmast" csakhogy a valo vilagban rendkivul tapasztalt programozok ezt mashogy gondoljak. Errol volt is egy korabbi (Linux: a 'goto' ártalmas a kernel kódban?). Linusnak mas a velemenye.

> Nagyon szep, valamint a goto hasznalata Dijkstra ota helytelen!

Iskolaban valoban helytelen, ott a strukturalt programozasban hisznek, igaz nem nagyon tudjak megindokolni, miert.

En hasznalok break-et, continue-t, es neha goto-t is, meg egy fuggvenynek siman csinalok tobb kilepesi pontot, tehat nagy ivben teszek a stukturalt programozas dogmaira. A programjaim ennek ellenere mukodnek :-)

Andras

a megfigyelés jó, a következtetés rossz.

a sokakat érdeklő alaprendszer, böngésző, szövegszerkesztő ... ideális az opensource világnak. ez nyilvánvaló, meghalni nem fognak soha, igazi vetélytársuk nem lesz.

Azt azonban ne felejtsük el, hogy N kódba buherálótól nem lesz jó kód, csak ha igazi szakértők veszik kezükbe a dolgot.

A fontosabb: ne álmodozzunk, vannak nem az 1.0-ás usert érintő problémák, ahol egyedi fejlesztésre lesz szükség, és az a legtöbbször keményen üti az opensource-t. tehát sok helyen az opensource SOHA nem lesz alkalmazható.

Pl hol nem fog igazi alternatíva lenni az OS soha:

1. egyedi üzleti modellhez kötődő dolgok /ilyen _rengeteg_ van/ pl már egy nagyobb, nem tipikus website se oldható meg egyedi fejlesztés nélkül, vagy egyedi ügyvitelt követelő dolgok stb

2. ipari termékhez szorosan kötődő programok. az összes digitális vezérlésű hardver pl mobilok, ipari berendezések stb

3. gyors termékciklusú programok pl könyvelés, jogrend

4. nagy megbízhatóságú rendszerek egészségügy, katonaság, űripar

stb szóval maradjunk a Földön.

> Nagyon szep, valamint a goto hasznalata Dijkstra ota helytelen!

Nem "ota", hanem "szerint". Ez egyetlen velemeny a sok kozul.

Eleg ha a switch() break - jere gondolsz ... Megnezem azt a programozot aki megoldja nekem break nelkul a tobb elagazas normalis kezeleset :)

Nem azt mondom hogy esz nelkul kell hasznalni, ellenben ha lehet kerulni kell. De adodhat olyan eset amikor jobb mint agyon strukturalni. Gondolj csak arra hogy a P4 20 lepcsos csovezeteket tartalmaz ...

Vagy ott az if else paros. Lehet hogy te nem latod, attol meg a kompajler egymillio kondicionalt (ezt gyu - tol tanultam:) vagy feltetel nelkuli jump - ra forditja le. :)

Minden komolyabb program tartalmaz goto - t. Akarki akarmit mond :) Szerintem Ma$ OS kerneleben is van egy halom ... bar abba szebb huzasok is akadnak idonkent ...

Vegso soron minden program csak ugy hemzseg a gotoktol :)

Pontscho

> Na meg persze, ha az az egyetemista hulye, es nem akar penzt keresni a munkajaval, akkor nyugodtan pazarolja az idejet opensource projektekre (persze egyedi programoknal nincs gaz).

De, az se referencia.

> A munkahelyeken nem azt kerdezik, hogy milyen opensource projekteken dolgoztal eddig, hanem azt, hogy milyen cegeknel dolgoztal, es milyen technologiakat ismersz, stb.

Igy van. Ezert szopok most kemenyen az allaskeresessel ...

A hiedelmeket eloszlatva, loszart se jelent allaskereses ugyben az hogy kozom van mplayer - hez ... Sajnso.

Pontscho / a jolkepzett munkanelkuli

> Igen, pl. ilyen peldakbol(fs/namei.c)

asszem egy jozan ember sem fog nekiesni a kernel forrasnak, ez egy nagyon eroltetett pelda volt.

> Nagyon szep, valamint a goto hasznalata Dijkstra ota helytelen!

Böhm es Jacipini 1966-ban bebizonyitotta, hogy barmely program megirhato a goto parancs hasznalata nelkul, pusztan a strukturalt programozas alapelemeivel. forras:

Böhm, C. es Jacopini G.: Flow diagrams, Turning machines and languages with only two formation rules, Communication of the ACM, Vol. 9, No. 5, 366-371. old. 1996 majus.

bizonyos helyzetekben, pl. ha a sebessegre van kihegyezve a program a goto hasznalataval gyorsabb futas erheto el. valoszinuleg a namei.c-ben sem veletlenul van igy. ha szerinted goto nelkul gyorsabb kodot kaphatsz, ird meg a goto mentes namei.c-t es postazd az LKML-re.

> A programozas szepsege nem a sokfele kez altal osszeganyolt ANSI C kodokbol tanulhato, hanem a megtervezett, specifikalt (objektumorientalt) projektekbol.

ganyolasbol valoban nem jo tanulni, de ezt ugy mondod mintha az OS projektek ganyolassal keszulnenek. remelem nem altalanositottad ennyire a dolgot.

> A munkahelyeken nem azt kerdezik, hogy milyen opensource projekteken dolgoztal eddig, hanem azt, hogy milyen cegeknel dolgoztal, es milyen technologiakat ismersz, stb.

ha mar az n-ik munkahelyen is tul vagy valoszinuleg tudsz mit "felmutatni" az interjun. de mit tegyen egy palyakezdo? modja azt hogy: "elolvastam 100 konyvet hogy mikent vegyunk reszt nagy projektekben!" ? szerintem ennel jobb fenyt vet rad, ha OS projektekbol mar van nemi tapasztalatod.

> A GCC-nek milyen piaci reszesedese van? En meg nem lattam a polcon ilyen forditot, csak amikor telepitettem pl. egy GNU/Linux-ot, akkor ahhoz kaptam egyet ingyen, amiert nem fizettem.

attol, hogy nincs dobozos verzioja, nem lehet piaci reszesedese? es mi van az Apache-csal?

> Most, hogy mar egy ideje nagy cegek hasznaljak fel az opensource-os "termekeket", es nemcsak egy kisebb felhasznaloi tabora van a dolognak, hanem a hasznot elrakjak a nagycegek (RedHat, Novell, IBM, stb.), hulye, aki opensource kodot is.

a nagy cegeknek valoban megeri OS szoftvereket hasznalni, azonban a helyezet kozel sem olyan egyoldalu, mint ahogy vazoltad. az emlitett cegek sokszor ajanlanak fel pl. hardver eszkozoket az OS projektek szamara.

arrol meg, hogy hulye aki OS kodot ir... tudod, van akinek a hobbija is az, ami a munkaja. a tobbit a kepzeloerodre bizom!

> Most tobb dologba nem kotok bele. :)

amig az embernek nincs elegendo informacioja egy temarol ahhoz, hogy megfelelo velemenyt alkosson rola, addig jobb ha nem szol hozza. az hozzaszolasodbol pedig nekem nem ugy tunt, hogy rendelkeznel ezzel az "elegendo" mennyisegu informacioval.

bocs.

A goto egy erdekes allat. Nalunk (BME VIK) azert nem szeretik, mert a kezdo programozo ugyis hulyen/foloslegesen hasznalna, es csodalatos spagettikodot generalna. A profikkal mas a helyzet, ok mar ismerik annyira a nyelvet, hogy jol tudnak banni akar a gotoval is, ez a helyzet a kernelben is.

Egy egyszeru pelda atlathato gotos kodreszletre pl 3 fuggveny, melyek mindegyike megnyit valamilyen descriptort es a programnak a helyes mukodeshez mindharom kell. Mondjuk az utolso hivas meghal valamiert, az elso ket hivasbol kapott descriptorokat fel kell szabaditani (pl egy szemafor).

A fuggveny vegen a felszabaditast forditott sorrendben vegzed, es ha a 3. hivas behalt akkor az az utani goto labelre ugrassz, ami utan jon a masik ket descriptor felszabaditasa. Ez atlathato, es pl ilyen hibakezelesre van egy par pelda a kernelben.

Abban az esetben amit te irtal (kernel reszlet) a goto azert van, hogy folosleges valtozokat ne kelljen bevezetni a goto-s esetek kezelesere. Ha szepen strukturaltan csinalnad lenne egy int ed arra hogy need_lookup egy arra hogy fail... es ezeket tesztelned if-el, ez kb 4 folosleges valtozo egy nagyon surun hasznalt fuggvenyben.

Nem azt mondom hogy szep megoldas, bar ketsegtelenul kenyelmesen olvashato :), csak azt hogy vannak megmagyarazhato helyzetek a goto hasznalatara.

Zod.

Nem ertek veled egyet!

Nezd meg a www.top500.org oldalt! A jelenleg uzemelo leggyorsabb szamitogepek kozott is van mar linux (3. vagy 4. emlekeim szerint), ez abszolut nem az 1.0-s useres "lakodalmas informatika" kategoriaja.

Ha valaki mostanaban 64 bites AMD rendszert vasarol, akkor kenytelen linuxot hasznalni (pl. a kinaiak viszik, mint a cukrot).

Lattal te mar ipari berendezest kozelrol? En egy evente 12000-15000 tonna acelt megmunkalo gepsort programoztam (ez Europaban is kiemelkedonek szamito volumen), aminek az elso oprendszere Win98 volt (nem rohogni :) ). Ja es meg tudok parrol, ami ennel is tobbet produkal es DOS v. Windows NT futkarozik alatta.

A mobilpiacon nem gyozok rohogni, mert lassan mar nem kapsz olyan telefont, ami nem fagy ki, jol kezeli az ekezetet (nem Unicode-al!!!!).

Uriparban nem vagyok kompetens, de ott is kallodott el muhold egy elutesen ("," helyett "." :))) Fortran power), meg a Columbia sem egy elszabadult lufi miatt robbant fel.

A legtobb ilyen hagyomanyosan custom fejlesztest igenylo teruletet lassan fel fogja valtani valami mainstream felol erkezo rendszer. Pl. QNX-et nagyon jo beagyazott oprendszernek tartjak, de en megjosolom neki, hogy evrol-evre piacot fog vesziteni a Linuxal szemben.

Az en konkluziom az, hogy nem a technologia a fontos, hanem technologiat alkalmazo szurkeallomanyt. Az MPlayert nem attol fogom jo lejatszonak tartani, mert "szep" a kodja. Leszarom mennyire szep a kod, es hogy mennyire szabadszajuak a fejlesztok, es hogy nem komaljak a Debiant. En azt a szoftvert egy hatekony eszkoznek tartom bizonyos feladatok elvegzesehez es kesz. Ez a bizonyos szurkeallomany a Linux mogott latszik koncentralodni es ez az, ami szerintem szamit. Szerintem a technikailag kepzett emberek atcsabitasa a Linux legnagyobb kihivasa, nem az 1.0 user kezebe adott szovegszerkesztok szamitanak.

- en nem tudok Linuxra jo ingyenes CAD rendszert (a mernokok meg mindig AutoCAD, CADkey stb-t hasznalnak).

-nem tudok a pingvinen futo GPL-es Fortran 90-95 forditot, pedig valamivel le kell forditani azokat a nyamvadt szimulaciokat.

....

Es itt most sok emberke sorolhatna, hogy az o szakteruleten milyen alapveto szoftver hianyzik.

Az utobbi idoben sokat programoztam Fortranban. Lehet, hogy a Fortran gyengebb technologia, mint a C++, de olyan merhetetlen tudas van egy-egy 10000-20000 soros programban, amibol egy atlagos "strukturalt" vagy "objektumorientalt" programozo 50-60 sornyi kod ertelmet csak hetek-honapok komoly tanulasaval foghatja fel. Lassuk be, hogy emellett eltorpul az a teny, hogy goto-t meg miegymast hasznalunk-e.

Itt valaszolni fogok a masik kollega strukturalt programozas, OOP beszolasara. Jobb az elejen leszogezni, hogy ezeket az eszkozoket azert hoztak be az informatikaba, hogy a kozepszeru programozo egyedeket termelo munkara lehessen fogni. Egy profi programozo tok jol erzi magat az assembly,c,fortran tarsasagaban, es ezek a nyelvek a tobb tankonyvben bemutatott gyengesegeik dacara koszonik szepen jol vannak, pedig mindegyik tul van mar a harmincadik szulinapjan.

Az a baj, hogy az OOP szemleletu emberek (tisztelet a kivetelnek) olyan esztetikai kivanalmaknak probalnak megfelelni, amik teljesen irrelevansak. Senkit nem erdekel, hogy jol karbantarthato a program, senkit nem erdekel, hogy mennyire strukturalt a megkozelitesed. Ha jo kodot irsz akar evekig nem kell hozzanyulni, utana meg ugyis ujra fogod irni.

Egyik kedves tanarom mondta kod ket fele van: hatekonyan mukodo vagy szar. Az programozashoz kapcsolodo egyeb szempontok csak a hobbikerteszeket erdeklik.

Andrei

> bizonyos helyzetekben, pl. ha a sebessegre van kihegyezve a program a goto hasznalataval gyorsabb futas erheto el. valoszinuleg a namei.c-ben sem veletlenul van igy.

Ha jol megnezed a kodot, akkor tele van az egesz fuggvenyhivasokkal (push-ok, call, stack-buheralas, tenyleges vegrehajtas, ret). Ezzel szemben a goto 1 db jmp utasitas, ami megfelelo branch prediction+prefetch-el rohadtul optimalis, tehat itt a processzoridot nem a goto viszi el, hanem a push, a call, es a ret.

Mellesleg a break-et, a continue-t es a fuggveny kozbeni return-t en is szoktam hasznalni. A goto-t azert nem, mert nehez kibogozni, hogy hol a kod fule meg a farka, mint pl. a namei.c-ben.

> de mit tegyen egy palyakezdo? modja azt hogy: "elolvastam 100 konyvet hogy mikent vegyunk reszt nagy projektekben!" ?

Nem. Kisebb cegek eloszeretettel alkalmaznak egyetemistakat kisebb feladatok megoldasara. Nem kapsz oriasi nagy penzeket, de lesz referenciad. Tudod mi az a referencia? Majd megtudod.

A vilag nem olyan, mint ahogy elkepzeled.

> attol, hogy nincs dobozos verzioja, nem lehet piaci reszesedese? es mi van az Apache-csal?

Konkretan, akik ezeket a software-eket fejlesztik mennyi bevetelt termelnek a sajat zsebukre?

Mint mondtam, a bevetelt azok a cegek termelik, akik Apache webserver-t tesznek az oldaluk ala. Kinek is eri meg a gcc es Apache hasznalata leginkabb? Mar mondtam, a cegeknek. Tehat az OS fejlesztok kulonbozo (nagy)cegeknek "dolgoznak", akiktol nem kapnak fizetest.

> emlitett cegek sokszor ajanlanak fel pl. hardver eszkozoket az OS projektek szamara.

Aha, kapnak morzsakat! A bevetel nagyon kicsi reszet.

> az hozzaszolasodbol pedig nekem nem ugy tunt, hogy rendelkeznel ezzel az "elegendo" mennyisegu informacioval.

Na kedves baratom, te erosen el vagy tevedve. Tudod, teged az tevesztett meg, hogy kimondtam a korubeluli igazsagot. Nem baj, ha faj, majd megszokod.

Sokszor egy kalap ala szoktak venni azt, amikor valamilyen OS OS-t hasznalsz, valamint azt, hogy kuzdened kell a zart forras ellen, es az OS "termekeket" kell gyarapitanod, arra kell pazarolnod a munkad utan a szabadidodet, hogy azert dolgozz, hogy masnak jo legyen. Nagyon sokan rajonnek (mondjuk az egyetem utan), hogy ez nem jarhato ut, mivel valamibol meg kell elni, csalad, stb es Pontscho peldaja.

> Ha jol megnezed a kodot, akkor tele van az egesz fuggvenyhivasokkal (push-ok, call, stack-buheralas, tenyleges vegrehajtas, ret). Ezzel szemben a goto 1 db jmp utasitas, ami megfelelo branch prediction+prefetch-el rohadtul optimalis, tehat itt a processzoridot nem a goto viszi el, hanem a push, a call, es a ret.

valoban, csak ha nem goto-val lenne megoldva me'g lassabb lenne. talan nem kell magyaraznom hogy miert.

> Kisebb cegek eloszeretettel alkalmaznak egyetemistakat kisebb feladatok megoldasara.

szerintem az egyetemista != palyakezdo, de javits ki ha tevedek.

> Konkretan, akik ezeket a software-eket fejlesztik mennyi bevetelt termelnek a sajat zsebukre?

keveset, de az sem ritka, hogy semennyit. az OS nem elsosorban a profitrol szol ha nem tunt volna fel.

> Tehat az OS fejlesztok kulonbozo (nagy)cegeknek "dolgoznak", akiktol nem kapnak fizetest.

> Aha, kapnak morzsakat! A bevetel nagyon kicsi reszet.

hahh! kizsakmanyolas meg a tobbi, mi? ugy latszik nem olvastad el eleg figyelmesen a valaszom. az OS szoftver fejlesztoinek tobbsege hobbibol, nem a penz altal motivalva hoz letre valamit. ennyibol a freeware szoftvert fejlesztok is hulyek, meg mindenki, aki onzetlenul tesz valamit.

> Na kedves baratom, te erosen el vagy tevedve. Tudod, teged az tevesztett meg, hogy kimondtam a korubeluli igazsagot.

azt hogy ki van eltevedve, javaslom inkabb bizzuk az idore hogy eldontse! ha szerinted ez a "korulbeluli igazsag", akkor en csak annyit fuznek ehhez, hogy az nagyon korulbeluli.

> Nem baj, ha faj, majd megszokod.

haha! nem faj, csak a demagog hozzaszolasok mellett nem mindig megyek el szo nelkul.

> Sokszor egy kalap ala szoktak venni azt, amikor valamilyen OS OS-t hasznalsz, valamint azt, hogy kuzdened kell a zart forras ellen, es az OS "termekeket" kell gyarapitanod, arra kell pazarolnod a munkad utan a szabadidodet, hogy azert dolgozz, hogy masnak jo legyen.

van egy olyan dolog, hogy szabad akarat. senki sem kotelez arra, hogy OS szoftvert fejlessz.

a kornyezetemben mindenkinek volt kozvetlen vagy kozvetett haszna az OS szoftver fejlesztesebol (igen, elhelyezkedesnel is). persze lehet, hogy o"k voltak az elsok es az utolsok a Foldon! ;>

Hali! Szerintem önmagában jó vagy rossz eszköz nincs, csak jól vagy rosszul használt eszköz. A goto pedig a programozó számára egy eszköz. Ez akkor látható igazán, amikor muszály használni. Pl. amikor assemblyben programoztam, akkor így volt. Ha nem láttam át mit miért csinálok fagyott a gép. Ha a józan paraszti eszemmel átgondoltam a dolgokat működött a program. A goto-k számától függetlenül. Tehát az eszközt ne tévesszük össze annak helyes vagy helytelen használatával. Üdv. dacas

> Ha jo kodot irsz akar evekig nem kell hozzanyulni, utana meg ugyis ujra fogod irni.

Hűha, ezt ugye nem mondtad komolyan? Évek óta abból élek, hogy az ügyfelek folyton változtatják az igényeiket. (Isten áldja meg e jó szokásukat :-)

> valoban, csak ha nem goto-val lenne megoldva me'g lassabb lenne. talan nem kell magyaraznom hogy miert.

Te a O(1)-t es az O(n)-t is egy kalap ala veszed?

> szerintem az egyetemista != palyakezdo, de javits ki ha tevedek

Nem voltam vilagos. Ha mar egyetemistakent dolgozol (mondjuk 20-30 oraban), akkor az egyetem utan konnyebben kapsz allast. Mert fel tudsz mutatni valamit. Ha egyetemistakent OS projekteken bohockodsz, amit az iparban szarnak sem tekintenek, akkor meg majd csak nezel szepen ki a fejedbol.

> az OS szoftver fejlesztoinek tobbsege hobbibol, nem a penz altal motivalva hoz letre valamit

Ezert hulyek.

Tudod mit? Fejlessz hobbibol a Microsoft-nak! Ennyi erovel megtehetned.

De nem vitatkozok veled tobbet, mert ugy latom nem erdemes. Majd felnosz!

> Egy profi programozo tok jol erzi magat az assembly,c,fortran tarsasagaban, es ezek a nyelvek a tobb tankonyvben bemutatott gyengesegeik dacara koszonik szepen jol vannak, pedig mindegyik tul van mar a harmincadik szulinapjan.

Epp ellenkezoleg. Az OOP olyan eszkoz, amelynek a hasznalata egy absztraktabb szemleletmodot kovetel meg. Ezt sokan keptelenek felfogni, igy maradnak az alacsony szintu, elavult nyelveknel. A C++-t, C#-ot, Java-t, stb a nagy projektek eletkozelibb modellezesere hoztak letre, csak valaki ezt nem latja. Pl. azok, akik meg nem probaltak, csak beszelnek.

Ezt nemcsak az iskolaban tanitjak, hanem tapasztalhato a munkad soran

> Senkit nem erdekel, hogy jol karbantarthato a program, senkit nem erdekel, hogy mennyire strukturalt a megkozelitesed. Ha jo kodot irsz akar evekig nem kell hozzanyulni, utana meg ugyis ujra fogod irni.

Ebbe mar belekotottek. De en is belekotok, es ugyanazt tudom csak mondani.

> Te a O(1)-t es az O(n)-t is egy kalap ala veszed?

egyaltalan nem.

> Nem voltam vilagos. Ha mar egyetemistakent dolgozol (mondjuk 20-30 oraban), akkor az egyetem utan konnyebben kapsz allast. Mert fel tudsz mutatni valamit. Ha egyetemistakent OS projekteken bohockodsz, amit az iparban szarnak sem tekintenek, akkor meg majd csak nezel szepen ki a fejedbol.

talan csak olyan cegekkel talalkoztal ahol azt sem tudtak mi az OS. persze ha egy vallalat a referenciat nem a raforditott munkad minosegebol iteli meg... termeszetesen elofordul, hogy egy nagy ceg neve onmagaban is eleg a sikeres palyazashoz, de maradjunk inkabb az OS-szal elerheto lehetosegeknel! te (mint "kis ceg" vezetoje) szivesebben alkalmaznal olyan egyetemistat, aki me'g nem dolgozott be valamilyen projektbe, ha van OS-os tapasztalattal rendelkezo jelentkezo is?

> Tudod mit? Fejlessz hobbibol a Microsoft-nak! Ennyi erovel megtehetned.

szerintem nekik ez nem lenne megfelelo. mondjuk nekem sem.

> De nem vitatkozok veled tobbet, mert ugy latom nem erdemes. Majd felnosz!

no comment.

Ja, qrwara csak az szamit hogy mennyi penzt fogsz hozni a konyhara.

Bitfakk, szinten munkanelkuli programmer :(

1. Szerintem az egyedi megoldások sokkal jobban megoldhatóak nyílt forráskóddal, mint zártal. A zárt forráskódú moduláris rendszerek is csak félkész megoldások, soha nem működnek úgy ahogy a használó valóban szeretné és fejleszthetetlenek is. Jómagam leginkább Perlben fejlesztek webfelületeket és gyakorlatilag bármi megoldható elég gyorsan. Perlben készült az Amazon.com is, elég egyedi, elég nagy.

2. Szvsz minden oprendszer támogatja a párhuzamos és soros port programozását így nem értem miért ne lehetne ipari eszközöket vezérelni. Linuxos mobil meg már most is van (Sharp, Motorola).

3. Lásd LafiSoft X-Raktár, hamarosan talán könyvelőprogijuk is lesz. Nem látom akadályát miért ne lehetne gyors termékciklusú nyílt forrású programot készíteni. Akár kormánytámogatással is.

4. Ez egyszerűen nem igaz.

Szerintem ne becsüld le az alacsonyabb szintű nyelveket. Az OOP bonyolultabb szemlélete valóban alkalmasabb összetettebb feladatok megoldására, ugyanakkor az egyszerűbb, adott esetben gépközelibb szemlélet viszont optimálisabb megoldásokat szülhet optimalizáló ide vagy oda. Ha valaki nem komálja az OOP-t attól még fel tudja fogni - amúgy sem egy nagy wasistdas. A legfontosabb szvsz hogy számodra kellemes munkakörnyezetben - szemléletmóddal és nyelven - dolgozz. Ezért agyalták ki a nagyokosok több cégnél is, hogy tök mindegy milyen nyelven írod a kódod, miután lefordítod be tudod illeszteni a projektbe.

Összekeverted a OS eszközökkel fejlesztés és az OS szoftverek fejlesztésének fogalmát. Az Amazon.com forrása nem nyílt, az X-Raktáré sem, ha jól tudom.

Na akkor csinalj meg nehany IGAZAN utos problemat.

"Epp ellenkezoleg. Az OOP olyan eszkoz, amelynek a hasznalata egy absztraktabb szemleletmodot kovetel meg. Ezt sokan keptelenek felfogni, igy maradnak az alacsony szintu, elavult nyelveknel. A C++-t, C#-ot, Java-t, stb a nagy projektek eletkozelibb modellezesere hoztak letre, csak valaki ezt nem latja. Pl. azok, akik meg nem probaltak, csak beszelnek."

Es te mit fejlesztesz Javaban vagy C#-ban. Szamlazoprogramot? Telefonkozpontot? Appletet? Ne rohogtess. Ezek iszonyatosan nem nagy projektek, meg akkor sem ha tizezer programozo dolgozik rajta (sot eppen ez mutatja, hogy annyira nem nagy dolog, ha gyakorlatilag barki kepes csinalni). Ja megvalami: probalj mar meg Javaban az MPlayerrel osszemerheto teljesitmenyu lejatszot irni! Nem fog menni, meg akkor sem, ha te vagy a legzsenialisabb Java fejleszto. Hajra!!!

Kapisgalod mar, hogy miert szinte csak a szurkeallomany szamit? A jo fejek nem szeretik, ha megmondjak, hogy hogyan csinaljanak valamit (mennyit indenteljenek, osztalyokat gyartsanak, ) nekik egy kelloen sokoldalu eszkoz kell, amivel kepesek a munkajukat elvegezni!

Ja, a userek modositasi igenyei. Az aki nem tudja elore, hogy mit akar szamitogeppel csinalni arra kar szot fecserelni. Lehet, hogy most jot rohogsz rajta, meg egy kalap penzt keresel vele, de 5 ev mulva hanyni fogsz az igenytelensegtol, amivel nap-nap utan szembesulsz. En kb. 1 ev alatt elegeltem be az ilyen projektekbol. Most numerikus algoritmusokon dolgozom, meg cluster/SMP programozason. Kurvara nem hianyzik az "absztrakt latasmod", meg az OOP, a virtualis gepen meg jot vigyorgok. Ennek ellenere ez az eddigi legerdekesebb melom, itt tenyleg lehet jopofa dolgokat csinalni.

Andrei

idézetek ava-tól:

> Tudod mi az a referencia? Majd megtudod.

> A vilag nem olyan, mint ahogy elkepzeled.

> De nem vitatkozok veled tobbet, mert ugy latom nem erdemes. Majd felnosz!

mindíg szerettem ezeket a kijelentéseket :-), és persze azokat embereket is akik a saját - beszűkült, egyoldalu, stb... - nézeteiket akarják ráerőltetni másokra. ráadásul a vitában(?) a fentiekhez hasonló "érveket" villogtatva fikáznak. szerencsére a világ ennél sokkal színesebb.

> a világ ennél sokkal színesebb.

A kis alomvilagod. :)

Andrei, ne csapongj, maradj a témánál!

miről van szó? az OS fejlesztésekről, ahol a forráskód nyílt, és sok önkéntes készíti a programot (nem linux és nem fortran flame).

Ha azonban egyedi igényei vannak egy felhasználónak, akkor meg kell valakit bíznia, hogy azokat megírja neki. Ha sok egyedi igénye van, akkor sok programozó kell neki, és egyre kevésbé éri meg az igen drágán kifejlesztetett szoftvert visszaadni a köznek, beleértve a vetélytársakat is.

A bazár jellegű fejlesztések egyedi igények gyors kielégítésére alkalmatlanok.

A modern eszközök lehetővé teszik nagy problémák több ember közötti megosztását.

Az átgondolt, tiszta kód pedig lehetővé teszi a programozók helyettesítését.

Annál szörnyűbb nincs, mint amikor van a cégnél egy "zseni", aki több tízezer sor nem kommentezett, spagettivé goto-zott, módosíthatatlan, rejtett hibák százait tartalmazó FORTRAN vagy C vagy akármilyen kódot hagy maga után, amikor elmegy a cégtől, megsértődve, hogy határidőt kérnek rajta számon.

Emiatt rémületesen rosszak a magányos hackerek nagy rendszerek összerakásánál.

Legyen több, átlagos programozó, és legyen egy, aki szervez és koordinál, akkor megy a szekér és az elkészült termékre büszke lehet mindenki. Komoly cégeknél csak ez a járható út.

Az MS ujrairja a teljes forditoprogram infrastrukturajat Managed C++-ban. Gyakorlatilag build opcio, hogy CLR-re vagy nativ kodra fordul. Ez szerintem nem kis projekt, megis OO-t hasznalnak benne, es menedzselt kodot (is).

A megfelelo celra a megfelelo eszkozt kell valasztani. Nyilvan nem allsz neki Javaban MPlayert irni. De pl. parhuzamos programozasnal nem rossz dolog az a virtualis gepesdi. Most ne SMP-re gondolj, hanem mondjuk Computational Gridekre, ahol a gridben van mainframe-tol PDA-ig minden. Nem rossz dolog, ha dinamikusan at tud menni egyik node-rol a masikra a taskod...

Udv,

kisg

Ui: OOP != programozasi nyelv... Javaban is lehet strukturaltan programozni, csak minek. C ben is lehet OO programozni, es van akinek sikerul is: GNOME es kornyeke.

Egy teljesen jol teszi, mert ha a programozasi layerek mindegyike ujrafordithato, akkor osszessegeben gyorsabb

futast eredmenyezhet, mint a layerenkent statikus c, c++,

xyz library-k. Ha valaki megis c,c++ kodokat szeretne ilyen

formaban latni, ajanlom figyelmebe az LLVM (Low Level Virtual Machine) http://llvm.cs.uiuc.edu/ oldalat.

handler

és ismét egy szösszenet a fentebb megfogalmazott stílusban...

midíg jókat derülök a hasonlókon :-)