Ez a hír még mindig nem igaz, akármilyen jó is a C. Szánalmas, hogy egyesek úgy fordítanak, hogy közük sincs a nyelvhez. Nekem ilyen tanáraim vannak..... és azt merik állítani, hogy tudnak angolul. :(
OK, most nem értem mi a gond? Mert én is kb. ugyanezt mondtam, kivéve, hogy a C teljesítményelõnye nem nyelvi, hanem programozási szokásokból ered, de tény, hogy C-ben álltalában gyorsabb kódot írnak.
Hanyszor mondjam meg, hogy DE, ELVI PERFORMANCE okok miatt nem irjak a lowlevel eszkozkeloket, drivereket, kernel modulokat C-ben. Ez teljesen egyseges unix es win alatt. Nem is varhato a jovoben, es magam is szakmailag hibas dontesnek tartanek magasabb szintu eszkozokkel operalo nyelvben kernelszintu kodok irasat.
"szerintem a Linux és a többi UNIX-ok (AIX, Solaris...) és a Windows annyira uralják és uralni fogják a közeljövõben is az OS piacot, hogy nem igen hiszem, hogy hamarossan látni fogunk valami komolyabb kernelt ami nem C-ben van. Persze sokszor már gondolkodtam rajta, hogy nem lenne rossz ha valaki leülne és a mai tudást alkalmazva alapossan átvizsgálná a meglévõ OS-eket és ezek alapján egy új modern de magassan kompatibilis kernelt írna... de hát ez csupán egy ostoba utópia..." - igen sajna ez utopia, egyszeruen vagy bele sem kezdenenek, vagy ki sem derulne, azaz nem tudna teret nyerni maganak a sok nagy mellett.
továbbá, azt hiszem, hogy egyetértünk abban, hogy nem a C++-ban van a hiba, hanem abban, hogy általában a forítóban és abban, hogy a programozók C++-ban hajlandóbbak a fordítóra támaszkodni, míg C-ben inkább maguk optimizálnak...
szerintem a Linux és a többi UNIX-ok (AIX, Solaris...) és a Windows annyira uralják és uralni fogják a közeljövõben is az OS piacot, hogy nem igen hiszem, hogy hamarossan látni fogunk valami komolyabb kernelt ami nem C-ben van. Persze sokszor már gondolkodtam rajta, hogy nem lenne rossz ha valaki leülne és a mai tudást alkalmazva alapossan átvizsgálná a meglévõ OS-eket és ezek alapján egy új modern de magassan kompatibilis kernelt írna... de hát ez csupán egy ostoba utópia...
"de akkor kérlek magyarázd el nekem, hogy miért van a UNIX történelmi kernelén "
Nos ebbe nem latok bele, nem sok ember fejleszt kernelt ugy hiszem - szoval ezt amolyan koltoi kerdesnek ertekelem. Mindenesetre ket okot konnyeden tudnek mondani: 98 ig a C++ nem rendelkezett ISO szabvannyal es szamos dolog modosult az eltelt ido alatt – ergo kozel sem volt stabil, tovabba a forditok is csak igen nagy kesessel tudtak kovetni a valtozasokat. Masik pedig az, hogy gyakorlatilag minden eddigi kod C-ben volt irva, igy elkepzelheto, hogy nem lett volna tul koltseghatekony atalni C++-ra…
"hogy egy kernelnek nincs szüksége az OO dolgokra"
Azt hiszem ezen nem veszunk ossze, de mint leirtam a C++ csak egy resze az oo tamogatas... kicsit tobb ettol az a stuff.
"nem Brian az aki az elhangzottakat elmondta" - milyen Brian?
"nagyon sok igazságot is lehet benne találni... ha nem hiszed el, akkor vagy nem dolgoztál C-ben, vagy nem dolgoztál C++-ban " - elnezest, de nem emlexem hogy a tartalmaval kapcsolatba mondtam volna valamit... igy teljesen felesleges ilyen nagy arcal lenni.
“sokszor nem implementálják tökéletessen a C++-“ legjobb tudomasom szerint egyedul a Commo fordito olyan, amely magat szabvanyosnak mondja.
“Termeszetesen hatkonysagi, optimalizacios okokbol irnak ma minden kernel modult win es lin alatt egyarant C-ben. Es ez igy is fog maradni meg legalabb ot evig.” – en erre nem vennek merget, C++ is lehet olyan hatekonyan kezelni mint egy C-t… altalanossagba nem hinnem, hogy igaz lenne.
Ha viszont a hatekonysag a minden, akkor irjunk Fortranba mert az meg a C-nel is hatekonyabb kodot general talan, vagy ASM… vagy gepi kod :). Szoval mas szempontok is vannak, es elkepzelheto, hogy az aranykozep utnak jo ideig a C szamitott… de nem hiszem, hogy ez egy betonstabil torveny lenne.
Nem! A C-ben álltalában gyorsabb kódot irnak, mert a programozók kicsit gépközelebbrõl figyelik a dolgokat, C++-ban viszont már objekt orientált szemmel figyelik a dolgokat és ezért lasabb kódot írnak (persze ez nem mindég van így), viszont a C++ fordítók álltalában sokkal kevésbé optimizálnak és sokszor nem implementálják tökéletessen a C++-t. Ez valószínûleg maga a C++ összetettsége miatt van (a C-hez képest), de azért nem mondható a C-re, hogy gyorsabb, csak az mondható, hogy C-ben a programozótól függ, míg C++-ban sokszor a fordítótól.
Termeszetesen hatkonysagi, optimalizacios okokbol irnak ma minden kernel modult win es lin alatt egyarant C-ben. Es ez igy is fog maradni meg legalabb ot evig.
OK, legyen úgy, de akkor kérlek magyarázd el nekem, hogy miért van a UNIX történelmi kernelén kívül pl. a Linux (amikor Linus elkezdte irni, akkor én már régen nyomtam a Borland C++-t, tehát volt, de volt g++ is...), de ez szintén elmondható a Windows NT kernelre is, meg a még késõbb született WindowsCE-re, de szintén C-ben van a HURD is, meg pl. a Plan9 microkernele... és sorolhatnám, de most semmiképpen sem jut eszembe egy OS kernel sem amely esetleg C++-ban lenne... Na nem kell mérgelõdni, mert a C++ szerintem és sok más fejlesztõ szerint is szuper nyelv, hatékony és stb. de itt azok a dolgok mellett érvelek (a szerintem jelzõvel), hogy egy kernelnek nincs szüksége az OO dolgokra, inkább maximálissan gépközeli kell, hogy legyen, a C az megfelel, de jobban szeretném ha a kernel sima gépi nyelven lenne irva, csak sajnos akkor dög nehéz lenne a portolás, ezért jött be a C, amelyet sokan portabilis gépi nyelvnek is hívnak, nem véletlenül... Ja a kamu interview-et, meg már évek óta ismerem, csak most érdekesnek tartottam, hogy ide hozzam (hátha valaki nem ismeri), és azon kívül, hogy kamu, vagyis, hogy nem Brian az aki az elhangzottakat elmondta, nagyon sok igazságot is lehet benne találni... ha nem hiszed el, akkor vagy nem dolgoztál C-ben, vagy nem dolgoztál C++-ban (vagy nagyon keveset).
----------------------------------------
During the recent discussion, when it was suggested that perhaps the kernel is written in C simply because "we've always done it that way...", Linux creator Linus Torvalds joined in to explain:
"In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
"The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."
és én nem hiszem, hogy Linus-nak problémája lehetnek... nem hiszem, hogy egy olyan ember mint õ FUD lenne.
Persze sok mindenhez jobb a C++, de sok komoly kernelfejlesztõ szerint a kernelhez nem... amint már sokszor mondtam a ONE SIZE FIT ALL filozófia egyrészt sohasem igaz, ha pedig erõszakolják akkor káros...
"Egyébként mivel tud többet ez a BitKeeper, mint ha CVS-t használnának?"
A CVS sokak szerint a bugware iskolapeldaja. Van egy valagnyi hianyossaga es sebezhetosege. Az SVN egy kicsit jobb, de van az OS verziokezeloknek nehany hianyossaguk, ami (Linus szerint) elengedhetetlen a Linux fejleszteseben, pl.: - A bekuldott patch-eket tetszes szerint kombinalhassuk. Ez CVS/SVN-ben bonyolult. - Elosztott repriosityk (tehat a projekteket elosztva tarolja)
Ha tudnál angolul akkor nem ugatnál le. Ez úgy volt, hogy a BitMover a BitKeepert Open Source projectek részére ingyen adta. És ez szûnt meg. És egy nyílt forrású klienst adtak helyette.
"As part of this focus, BitMover has replaced the free version of BitKeeper with the recently released open source BitKeeper client."
Ez a mondat az általad megemlített linkben van. Nem szoktam fikázni a levegõbe, csak rámutatok arra, amikor a cikk írójnak gõze nincs, hogy mi van angolul leírva. (És ez rengeteg esetben elõfordul itt.) A nyílt forrású kliens új dolog, nemrég jelentették be, szóval az nem szûnhet meg. Másrészt a nyílt forráskódot nem lehet megszüntetni, hisen mindenkié.
Ahogy yeti is irta, ez mar egy nagyon regi szakallas kamu...
"Szerintem" pedig az ilyen "szerintem erdemesebb kernelt C-ben irni" beszolasokat nem erdemes nagyon nagy dobra verni, mert ott kicsit tobb erv szol egyik es masik mellett mint a "szerintem"...
Amugy "szerintem" a legfontosabb ok tortenelmi, es nem feltetlenul hatekonysagra vezetheto vissza...
Yeti: a C++ nem OOP nyelv, a C++ multiparadigmas nyelv, melyben vannak eszkozok strukturalt, oo, generikus/generativ/aspektus orinetalt... sot a templateknek koszonhetoen meg funkcionalis nyelvi eszkozszerusegeket hasznalatara.
Tovabba fontos megjegyezni, hogy a Cpp reszhalmaza a C nyelv, igy pl gcc legjobb tudomasom szerint a g++ egy specialisan paramterezett valtozata... remelem vilagos, hogy mire akartam celozni.
Utalom az olyan hireket ill. cikkeket amik cime felteteles modban van vagy kerdojel van a vegen. "Lehet h minden windows felhasznalo meleg?" "Csokkenhet az sg olvasottsaga." "Hulyithetok az emberek buta hirek cimeivel?" "Az oralis szex jo a fogszuvasodasra?"
Heh... "Lassulhat a Linux kernel fejlesztése" Miert? Mert egy verzio kezelo, szoftverfejlesztest segito program fizetos lesz? Nevetseges. Van egy tonna alternativa. A regi verziot meg nem lehet fizetosse tenni, ha eddig jo volt, akkor hasznalhatjak tovabbra is. Version Control (479 projects) Version Control (304 projects) Persze atfedes lehet, de egybol azzal jonni h 'Lassulhat a Linux kernel fejlesztése'.... Ez kicsit FUD szvsz. -Orgi-
Haha, ez az interview már nagyon régóta kering az interneten, elég érdekes is, csak annyi a baj vele, hogy kamu. De mindegy. Egyébként tényleg igaz, kernelt jobb nem objektum orientált nyelven írni, mivel gyorsabb egy C ben írt kód. Viszont sokkal nehezebb és lassabb is C ben programozni. Meg egyébként is Unixoknál tényleg C-ben írnak szinte mindent.
Egyébként mivel tud többet ez a BitKeeper, mint ha CVS-t használnának? CVS-hez meg létezik baromisok kliens... Vagy ha az nemjó, nem hiszem, hogy néhány hét alatt nem tudnának összedobni maguknak valami BitKeeper szerûséget GPLesen. Nahmindegy, csak nemértem, hogy hol van itt az a hatalmas katasztrófa.
"valszeg a szerver értékesítésben nincs olyan nagy hányada a winnek."
Blackrose megelõzött konkrét adatokkal, én csak annyit tudtam, hogy winbõl többet adnak el, mint az összes többibõl összesen, tehát nagyon nem reprezentativ, hogy te milyen ibm szerverekkel találkoztál :)
Az IBM szerverértékesítése a 2004 harmadik negyedévében a következõ:
UNIX = 1.05 billion Linux = 219 million Windows = 2.13 billion
mint láthatod a Windows jól tartsa magát az IBM-nél, mert a kis és középvállalkozások piacán a blade x86 szerverek nagyon keresettek és álltalában Windows-al veszik õket (ezért is virágzik a MS szerver részlege).
A Linuxnak nagy a betörése (pl. az említett idõszakban 42.6%-al lett nagyobb, míg a Windowsnál ez 13.3% plusz, a UNIX-ok meg sajnos az IBM-nél 2% plusz, de ha az egéssz piacot nézzük akkor 2.3% minusz volt az elözõ idõszakhoz képest)
Ott ahol a Linux viszont verhetetlen az a custom szerver piacon, kis szerverek 1 CPU-val és nem is szerver CPU-val, itt nagy elõnye éppen azért mert free. A fenti NAGY szerverpiacon ugyanis a Red Hat Enterprise az urlkodó kb. 60% piaci részesedéssel, aztán jön a SUSE Enterprise a többiekre meg nem igen jut semmi. A custom szerverek piacán viszont van minden fajta Linuxból jocskán.
Persze nem tudom most ennek mi köze a Linux Kernelhez, de ami az IBM-et illeti így áll a bál.
Az IBM gõzerõvel dolgozik a POWER elterjesztésén, és remélem sikeressek lesznek ebben, mert amióta volt alkalmam POWER-rel is dolgozni mondhatom, hogy nagyon szuper, mindegy, hogy Linux vagy AIX fut rajta (az AIX jelenleg fényévekkel jobb OS, de a Linux napról napra fejlõdik...)
Nem tudom, hogy sikerül e ez nekik, de mindenesetre én azon töröm a fejem, hogy az asztalomra dobjak egy Power alapú gépet... csak ne lenne olyan drága...
Lehet tévedtem valóban. Mindössze sosem futottam még össze wint futtató ibm szerverrel, innen vettem az infot.
neeeem. Nem katasztrófális. A linux ennél nagyobb kihívásokakl is szembenézett már,és legyûrte. Én pl nagyon féltettem, amikor az SCO elkezdett pampogni. Mert egy fejlesztõi program hiányát lehet pótolni. De amikor a nyílt forrást helyezik törvényen kívül a linux által, (talán nem kell mondanom, hogy a linux halála a nyílt forrás halála lenne) az végzetes csapás, kikerülhetelen probléma.Olyan mint kés a nyakba. De túlélte. (Gondolom redmondban most ismét külön kamion járat szállítja a fejfájás csillapítót) Szóval én nem aggódom.
A másik véleményem pedig az, hogy linus inkább ülljön a kérdésen még vagy 2 hetet, és a kernel team által közösen alaposan megtárgyalt megoldást publikáljon. Nem mondom, hogy rosszul döntött, de én még ültem volna rajta kicsit:)
"Ha figyelmesen olvastad a hírdetést észreveszed, hogy ez a kliens gépekre él."
Tényleg? Én meg már azt hittem az XP-t a szerverekre rakják. Te jó ég...
"Az IBM nem szállít szervert winnel. (tudtommal.)"
Hát rosszul tudod... Az entry level serverektõl (microsoft small business serverrel) egészen a datacenter server-ig az összes microsoft server termékkel árulja a szervereit az ibm...
Csak egy apró példa: http://www-1.ibm.com/servers/eserver/xseries/windows/index.html
Nem, még csak nem is opensource. Voltak tervek, hogy megírják GPL-esen nulláról: KitBeeper :), de végülis nem tudom mi lett vele. Lehet, hogy most újra elõkerül ez a kérdés.
Másrészt nem _visszavenni_ akarják a progit, hanem a free felhasználásra szánt részét nem feljesztik tovább.
Csatlakozom az elöttem szólóshoz:) Alap dolgokat felejtettek el beleírnia cikkbe. 1. ami egyszer nyílt forrású volt, és GPL alatt aadták ki, azt nem lehet visszavonni. A valami 1.0 licensze az is marad. Majd a valami 2.0 lehet az új licensz alatt. (az SCO per egyik legnagyobb melléfogása, hogy ehhez nem így álltak hozzá) 2. linus nem azért vonult vissza a kérdéstõl, mert kattognak a fogai a félelemtõl, hogy jajj mi lesz, hanem megvizsgálja a kérdést. Kiváltható-e, van-e értelme a "régit" használni, az új lincenszû verzióra kb: meddig halogatható az átállás. Equ. Ha figyelmesen olvastad a hírdetést észreveszed, hogy ez a kliens gépekre él. Az IBM nem szállít szervert winnel. (tudtommal.)
Amit egyszer Free-ként leszedtek , azt nem lehet visszakérni :]
Ráadásul úgyis nyílt forrású a program , nem ? De. Akkor meg majd keresnek pár lelkes fejlesztõt hozzá és meg van oldva... tehát vagy valami fontos info hiányzik a cikkbõl, ami meggátolja az általam felvázolt alternatíva keresztülvihetõségét, vagy csupán egy semmitmondó hírrõl van szó ..
Hm. De ha fizetõssé válik, akkor a régi verziókat sem használhatják freenek?
szépen meglovagolták a linux hype-ot, elõnyre tettek szert vele, és mostmár arra koncentrálnak amibõl meg is lehet élni... De nem kell meglepõdni ugyanezt csinálja az ibm, novell, sun és a többi nagy "linux támogató" is, kihasználja a sok szemellenzõst aki elhiszi, hogy ezek a cégek a linuxnak jót akarnak... Közben meg megy a hvg-ben minden számban a 2 oldalas ibm hirdetés, amiben az "ibm vállalati környezetbe a windows xp-t ajánlja" LOL :))
"A végsõ döntést azonban Linux Torvalds hozza majd meg"
Nem inkabb Linus Torvalds?
A régi free verzióval még simán fejleszthetnek egy darabig és más eszközre való áttérésig így nyerhetnek egy-két évet.
Informatika és tudomány
