43
  • whitehawk
    #43
    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. :(
  • BlackRose
    #42
    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.
  • Hierogli
    #41
    Elirtam, "nem irjak C++ -ban"
  • Hierogli
    #40
    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.
  • CAD
    #39
    Egyetertek.

    "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.
  • BlackRose
    #38
    "milyen Brian?"
    bocs, elgépeltem... Bjarne

    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...
  • CAD
    #37
    "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.
  • BlackRose
    #36
    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.
  • irkab1rka
    #35
    A C sokkal gyorsabb mint a C++, bár az utóbbiban gyorsabb és átláthatóbb a fejlesztés.
  • Hierogli
    #34
    Es persze a drivereket is.
  • Hierogli
    #33
    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.
  • BlackRose
    #32
    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...
  • h4x0r
    #31
    "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)

    Kb. ez a ketto jut eszembe.
  • whitehawk
    #30
    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é.
  • CAD
    #29
    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.
  • Orgi-CRPD
    #28
    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-
  • Yeti
    #27
    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.
  • BlackRose
    #26
    http://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html

    egy érdekes link...

    itt most nem akarok a C++ ellen beszélni, hisz sok mindenhez jobb a C-nél, de szerintem is a Kernelt C-ben a legjobb irni...
  • Cat #25
    fikázás helyett csak a cikkben lévő legelső linkre kellett volna kattintanod:

    "BitMover announces accelerated commercial development strategy and migration plan for Open Source users"
  • whitehawk
    #24
    Ahogy én olvastam a hírt másutt. A freeware változat szűnik meg, és az opensource kliens marad. Szerintem már megint kevertek az SGsek.....
  • h4x0r
    #23
    "a képen is c van. ugye, ugye, nem mindenre jó a c++, meg a java."

    A UN*Xok nyelve a C. A Java, C++, stb. pedig nem igazan fernenek bele a kernel "modelljebe" :-)
  • CAD
    #22
    Ezt most miert irtad? :D Remelem erzed, hogy hulyeseg amit irtal...
  • BlackRose
    #21
    Az én igényeimnek túlságossan gyenge, inkább egy duál G5-öt de nem MacOSX-el hanem Linuxal...
  • Equ
    #20
    "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 :)
  • asysoft
    #19
    Mac mini sztem egész elfogadható áron kapható.
  • BlackRose
    #18
    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...
  • yy
    #17
    a képen is c van. ugye, ugye, nem mindenre jó a c++, meg a java.
  • strogg
    #16
    :))
    Tényleg nem találkoztam még wines ibm szerverrel.
    valszeg a szerver értékesítésben nincs olyan nagy hányada a winnek.
  • Equ
    #15
    ez az azért jó erős önbizalomra vall... :)

  • strogg
    #14
    Equ:

    Lehet tévedtem valóban.
    Mindössze sosem futottam még össze wint futtató ibm szerverrel, innen vettem az infot.
  • strogg
    #13
    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:)
  • Equ
    #12
    "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
  • Laci73
    #11
    Ez a hír, ha igaznak bizonyul, katasztrófális.
  • BlackRose
    #10
    Linus már döntött...

    http://marc.theaimsgroup.com/?l=linux-kernel&m=111280216717070&w=2
  • pemga
    #9
    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.
  • pemga
    #8
    Ez igaz, de a BitKeeper nem GPL-es. Volt is ebből morgolódás, amikor elkezdték használni. Most úgy tűnik, hogy szívnak is ezzel a döntéssel most...
  • strogg
    #7
    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.)
  • [HUN]PAStheLoD
    #6
    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ó ..
  • smv
    #5
    Hm. De ha fizetőssé válik, akkor a régi verziókat sem használhatják freenek?
  • Equ
    #4
    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 :))