A kód minősége: Linux vs. FreeBSD vs. Windows vs. OpenSolaris

Programozás

Diomidis D. Spinellis, az athéni egyetem docense - aki egyébként már több hasonló témájú könyvet is szerzett - arra volt kíváncsi, hogy vajon a nyílt avagy a zárt forrású operációs rendszerek programozásának minősége a jobb. Diomidis a napokban mutatta be kutatási eredményeit a 30. Nemzetközi Szoftverfejlesztési Konferencián (30th International Conference on Software Engineering). A dokumentum a Linux, a FreeBSD, a Windows (research kernel distribution) és az OpenSolaris kernelek forráskódjának minőségét mutatja be. Az összehasonlítás során a szakember ezen kernelek különböző konfigurációit vizsgálta (több mint 10 millió sornyi kódot), tárolta le négy adatbázisba, majd az adatbázisokon különböző lekérdezéseket futtatott. A kutatás alatt 80 GB-nyi adatot, 160 millió sornyi rekordot kezelt. Az elemzés során a következő területekre tért ki:

  • fileszervezés (file organization)
  • kód struktúra (code structure)
  • programozási stílus (coding style)
  • előfeldolgozás (preprocessing)
  • adatszervezés (data organization)

Meglepetésére arra jutott, hogy nincs egyértelmű, tiszta győztese vagy vesztese a vizsgálatnak, de emellett bizonyos területeken jelentős különbségek vannak az egyes kernelek közt.

Az eredmény megtekinthető itt.

( Hunger | 2008. 05. 17., szo – 14:20 )

Illetvehát arra jutott amit eddig is tudtunk, hogy a nyílt forrású fejlesztés nem eredményez jobb minőséget.

Illetvehát nem jutottunk semmire, de sok pénzt, időt és energiát elköltöttünk.

Valamire végülis jó volt.

Gyakran meglepődöm rajta, hogy amerikai, ill. angol kutatók olykor mennyit dolgoznak és mennyi pénz költenek el olyan témákra, aminek az eredménye triviális. ...és a végén hogy örülnek az "eredményüknek".
Ez már akkor inkább a hasznos kategória!
...elvégre esély azért volt rá, hogy valami más lesz az eredmény. :D

> rosszabbul kommentezett, mint a Solaris vagy a Windows kernel,

A: Amilyen a célcsoport, olyan a komment. "Okos" olvasó, ilyen komment; "buta" olvasó, amolyan komment.

B: Amilyen a kód, olyan a komment. "Célratörő", önmagyarázó kód, ilyen komment; hekkelgetős, workaroundolós kód, amolyan komment.

Egyszerű ez.

Nem, ő azt hozta ki, hogy "To my surprise there was no clear winner or loser, but there were interesting differences in specific areas".

Te meg kiragadtál egy részletet, ami látszólag alátámasztja a elméletedet, majd a végére biggyesztettél egy felütést ("ész nélkül"), biztos, ami biztos.

--
trey @ gépház

Jaértelek. Nem választottam ki ilyen formán eredményt. A sorok és kommentek száma volt mindjárt az első két sor az összehasonlító táblázatban, így én is azt néztem elsőként. Mivel az egyik előző cikkben lévő hozzászólás szerint a Linux kódja teli van megjegyzésekkel, ezért kiváncsian számoltam ki az egy sorra jutó kommentek számát, hogy összehasonlíthassam a Solariséval. Nem tehetek róla, hogy az eredmény ezt mutatja, de szívesen olvasom a te következtetéseidet az eredmények alapján. :)

Kiragadtál - hibásan - egy részletet.

Lássuk akkor, hogy a cikk írója mire jutott:

"In the table I have marked cells where an operating system excels with a + and corresponding laggards with a -"

"A táblázatban + jellel jelöltem ahol az operációs rendszer kitűnt, hasonlóan - jellel pedig, ahol elmaradt."

- +
FreeBSD 12 3
Linux 13 12
Solaris 8 10
WRK 14 16

"Despite various claims regarding the efficacy of particular open or close-source development methods, we can see from the table that there is no clear winner (or loser). The two systems with a commercial pedigree (Solaris and WRK) have slightly more positive than negative marks. However, WRK also has the largest number of negative marks, while Solaris has the second lowest number of positive marks. Therefore, the most we can read from the overall balance of marks is that open source development approaches do not produce software of markedly higher quality than proprietary software development."

"Különböző, a nyílt- vagy zártforrású fejlesztési módszerek hatékonyságával kapcsolatos állítások ellenére láthatjuk a táblázatból, hogy nincs egyértelmű győztes (vagy vesztes). A két, kereskedelmi leszármazással rendelkező (Solaris és WRK) kissé több pozitív mint negatív jellel rendelkezik. Emellett azonban a WRK rendelkezik a legtöbb negatív jellel, míg a Solaris-nak van a második legkevesebb pozitív jele (második a legkevesebb pozitív jellel rendelkezők közt). Ennélfogva, a legtöbb, amit ki tudunk olvasni a jelek teljes mérlegéből, az az, hogy a nyílt forrású fejlesztési megközelítés nem eredményez határozottan jobb minőségű szoftvert, mint a zárt forrású, kereskedelmi szoftverfejlesztés."

Én ezt nem is kérdőjeleztem meg. Elfogadtam. Nem jöttem mindenféle kiragadott részlettel (kommentek száma) és nem tettem becsmérlő kijelentéseket ("ész nélkül") egyik fejlesztési modellre sem.

--
trey @ gépház

Kiragadtál - hibásan - egy részletet.

Miért hibásan? Engem az érdekelt egy korábbi hozzászólás kapcsán, hogy mennyivel tartalmaz több megjegyzést a Linux kódja, mint a Solarisé. Tudsz jobb módszert ennek eldöntésére?

Én ezt nem is kérdőjeleztem meg. Elfogadtam.

Én is.

Nem jöttem mindenféle kiragadott részlettel (kommentek száma)

A részletek nem számítanak, nincs jelentőségük, vagy mire akarsz ezzel kilyukadni?

nem tettem becsmérlő kijelentéseket ("ész nélkül") egyik fejlesztési modellre sem.

Erre írtam, hogy az meg tapasztalat és nem csak az enyém. Sajnos nem tudok más véleménnyel lenni, amikor a minap is ilyen Linus fájába beengedett commit került a szemem elé.

Érdekes, mert éppen most mutatott rá ez a felmérés - amit állítólag te is elfogadtál -, hogy a nyílt forrású fejlesztési modellnek - beleértve a Linux-ét is - nincs mit szégyenkeznie ha összehasonlítjuk a proprietary-val (Windows, Solaris). Ebből kijött neked az "ész nélkül".

Az én véleményem pedig továbbra is az, hogy - szokás szerint - megtaláltad magadnak a Linux-ot.

--
trey @ gépház

Itt a magyarázat:
Although all four systems I examine are available in source code form, their development methodologies are markedly different. OpenSolaris and WRK have been developed as proprietary systems. (OpenSolaris has a very short life as an open-source project, and therefore only minimal code could have been contributed by developers outside Sun in the snapshot I examined.) Furthermore, Solaris has been developed with emphasis on a formal process [6], while the development of Windows NT employed more lightweight methods [5,pp. 223, 263, 273-274]. FreeBSD and Linux are both developed using open source development methods [8], but their development processes are also dissimilar. FreeBSD is mainly developed by a non-hierarchical group of about 220 committers who have access to a shared CVS-based software repository. In contrast, Linux's developers are organized in a four tier pyramid. At the bottom two levels thousands of developers contribute patches to about 560 subsystem maintainers. At the top of the pyramid Linus Torvalds, assisted by a group of trusted lieutenants, is the sole person responsible for adding the patches to the Linux tree [28].
It doesn't matter if you like my song as long as you can hear me sing

Érdekes, mert éppen most mutatott rá ez a felmérés - amit állítólag te is elfogadtál -,

"hogy a nyílt forrású fejlesztési megközelítés nem eredményez határozottan jobb minőségű szoftvert, mint a zárt forrású, kereskedelmi szoftverfejlesztés."

Ebből kijött neked az "ész nélkül".

Nem ebből jött ki, hanem a saját tapasztalatomból, amelyre még példát is mutattam.

Az én véleményem pedig továbbra is az, hogy - szokás szerint - megtaláltad magadnak a Linux-ot.

Én a tanulmányban szereplő eredményekről alkotott következtetéseidre lettem volna kiváncsi, nem a rólam alkotott szubjektív véleményedre.

"hogy a nyílt forrású fejlesztési megközelítés nem eredményez határozottan jobb minőségű szoftvert, mint a zárt forrású, kereskedelmi szoftverfejlesztés."

A számokból pedig láttuk, hogy a Linux esetében rosszabbat sem.

"Én a tanulmányban szereplő eredményekről alkotott következtetéseidre lettem volna kiváncsi, nem a rólam alkotott szubjektív véleményedre."

Feljebb az én következtetésem. "A számokból pedig láttuk, hogy a Linux esetében rosszabbat sem."

De hiszen ezzel kezdtem.

--
trey @ gépház

Oké, azt hiszem rájöttem, hogy mi vezet félre téged...

A tanulmány nem közvetlenül a kód effektív minőségéről szól, hanem a fejlesztéséről (development methods and processes). Hogyan szervezték a fileokat (file organization), az adatokat (data organization), a kód struktúrákat (code structure), milyen a programozási stílus (coding style), stb.

Ezek a területek nem a kódok _helyességéről_ szólnak, hanem a fejlesztés _tisztaságáról_. Ahogy a bevezetőben is írta az úriember, gyakran látni olyan anekdotákat, amelyek azt "bizonyítják", hogy a nyílt forráskód jobb minőséget eredményez. Ezt cáfolja a publikáció.

Ezért nem lesz feltétlenül igaz az, amit írsz, hogy a Linux kódja nem rosszabb, mert a kódjába bele kell érteni a programozási hibákat és a design problémákat is, amelyeket viszont nem vizsgált a tanulmány.

> nekem cáfolatnak tűnik

Nézzünk egy egyszerűbb példát, hogy mindenki érthesse:

Állítás: a szőke nők lényegesen szebbek, mint a barnák.

Megnéztem egy szőke nőt és egy barnát

A: nem találtam lényeges eltérést közöttük.
B: a barna szebb volt.
C: a barna lényegesen szebb volt.

A, B és C közül melyik az, amelyik cáfolja az állítást?

Uram-atyám! Fejlesztői fába commit-oltak egy kódot, aminek volt egy problémás része

Idézek az általad írt HUPWiki szócikkből:

"Andrew ezeket a patcheket _kipróbálásra_ beteszi a saját kernelfájába (ezt nevezzük -mm fának). Ott bárki tesztelheti ezeket a patcheket azelőtt, mielőtt az _éles_ fába (Linus fa) bekerülnének."

A fejlesztői fa a -mm kellene hogy legyen, de a hibás commit nem oda ment, hanem a Linus fájába.

Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds

igen :P
amig nem kerül át a stable-teamhez, ott meg van egy olyan b*szott szabály, hogy csak olyan fixeket commitelnek vissza stablebe, ami már benne van a következő mainlineba ...
plként: 2.6.25-höz csak olyan fixeket commitelnek, ami már benne van 2.6.26-rcX-ben ... agyrém

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

"Erre írtam, hogy az meg tapasztalat és nem csak az enyém. Sajnos nem tudok más véleménnyel lenni, amikor a minap is ilyen Linus fájába beengedett commit került a szemem elé."

ezt a hozzaszolast egyszeruen nem tudom ertelmezni. szerinted a windows-ban meg nem volt hibas commit, vagy mi? Csak tudod ott nem lehet ilyeneknek konnyen utananezni az atlag halandonak, mert zart az egesz fejlesztes.

- Use the Source Luke ! -

Elég rosszul tippeltél. Csupán a Google-ba kellett volna beírni, hogy Windows Research Kernel.

Windows forráskódja se teljesen zárt, egyes komolyabb partnerek megkaphatják, valamint egyetemek a WRK-t oktatási célokra. Csak ugye erre kevesen olvasnak Windows Internalst. :)

Szerk: Egyébként a cikkben is van egy szép kis diagram, miből származik a WRK ;)

a nyílt forrású fejlesztés nem eredményez jobb minőséget.
Hazugsag! 

if (mode1 == VOIDmode
            || REG_P (op0) || GET_CODE (op0) == SUBREG
            || (mode1 != BLKmode && ! direct_load[(int) mode1]
                && GET_MODE_CLASS (mode) != MODE_COMPLEX_INT
                && GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT
                && modifier != EXPAND_CONST_ADDRESS
                && modifier != EXPAND_INITIALIZER)
            /* If the field isn't aligned enough to fetch as a memref,
               fetch it as a bit field.  */
            || (mode1 != BLKmode
                && (((TYPE_ALIGN (TREE_TYPE (tem)) < GET_MODE_ALIGNMENT (mode)
                      || (bitpos % GET_MODE_ALIGNMENT (mode) != 0)
                      || (MEM_P (op0)
                          && (MEM_ALIGN (op0) < GET_MODE_ALIGNMENT (mode1)
                              || (bitpos % GET_MODE_ALIGNMENT (mode1) != 0))))
                     && ((modifier == EXPAND_CONST_ADDRESS
                          || modifier == EXPAND_INITIALIZER)
                         ? STRICT_ALIGNMENT
                         : SLOW_UNALIGNED_ACCESS (mode1, MEM_ALIGN (op0))))
                    || (bitpos % BITS_PER_UNIT != 0)))
            /* If the type and the field are a constant size and the
               size of the type isn't the same size as the bitfield,
               we must use bitfield operations.  */
            || (bitsize >= 0
                && TYPE_SIZE (TREE_TYPE (exp))
                && TREE_CODE (TYPE_SIZE (TREE_TYPE (exp))) == INTEGER_CST
                && 0 != compare_tree_int (TYPE_SIZE (TREE_TYPE (exp)),
                                          bitsize)))
          {

Hát én gyerekeknek mutattam ezt a programot (nem igazán gyerekek már de mindegy 17-3x ig dominálóan a fiatalabbak, de egy 150-200 fős tanulógárda elég jó mintamennyiség, szóval szoktam órákat tartani egy esti iskolában fizikából, attól hogy MS termék nem feltétlenül rossz én így vagyok vele) . Olyan 15-percet elvoltak vele, de nem sok maradandó maradt meg belőle, láttak bolygókat csillagokat, és ennyi senki sem érzet olyan késztetést hogy megint ezen keresztül nézzen égképeket. Azokat akiket egyébként érdekelt a csillagászat mondta hogy szép szép de ez nem csillagászat, és megmutatta a kedvenc oldalát pl. Szóval jó dolog meg minden de nem egy egetrengető durranás nem kell túllihegni. Tudományos célokra meg tök alkalmatlan, nem arra van kitalálva.

( emberk | 2008. 05. 17., szo – 16:03 )

Na még egy tök értelmetlen felmérés. Minden rendszer alá vannak kiváló, és csapnivaló munkák kódok bármik. És lőn ez is jött ki. A nagy számok törvénye.

Ez a kutatás várható volt. Amikor valami nyilt forrású "baki" napvilágot lát, akkor egyből előkerül valami észkombány és hoz egy "megalapozott" tanulmányt a szabad szoftverek lehúzására (vagy legalábbis valami erre utalót).
Valahogy mindig elfelejtik megemlíteni, hogy Opensource-t elhivatottságból (netán hobbiból) szoktak írni, míg a fizetős szféra igyekszik felvásárolni a jó agyakat, hogy 1,) az ővé legyen 2,)legalább ne írjon szabadszoftvert, még ha nem is csinál értelmeset.

"It took six days for the god creating this world and see how many bugs it contains! "

"Valahogy mindig elfelejtik megemlíteni, hogy Opensource-t elhivatottságból (netán hobbiból) szoktak írni, míg a fizetős szféra igyekszik felvásárolni a jó agyakat, hogy 1,) az ővé legyen 2,)legalább ne írjon szabadszoftvert, még ha nem is csinál értelmeset."

Valószínűleg a Novell is elhivatottságból fejleszti a Linuxot, mikor talán 10 évvel ezelőtt azt hajtogatták, hogy Linux? Soha! :)

( Hijaszu | 2008. 05. 17., szo – 21:51 )

Ilyen kutatást jó végezni. Sok pénzt kapsz arra, hogy megvond a vállad: Nem tudjuk a megoldást (merthát ugye a kódminőséget nem lehet objektíven értékelni ilyen könnyedén:) (függetlenül attól, hogy jobb-e egyáltalán valamelyik és ha igen melyik)

( 2Geza | 2008. 05. 18., v – 07:40 )

Engem elkepesztett, hogy a WRK kodja kb 1 nagysagrenddel kisebb a linux kernel kodjanal... Azt gondoltam, hogy van kulonbseg, de ekkora ??

Ezt en ertem, de mi ertelme van NEM szetszedni kisebb, jobban karbantarthatobb egysegekre? Ekkora meret kulonbsegnel egyszeruen nem latom szakmailag vedhetonek a kod ilyen kevesse strukturalasat. Meg ha mondjuk ketszerese-haromszorosa lenne, de 10-20-szorosa a WRK meretenek. A WRK relative kicsi merete azt bizonyitja, hogy teljeserteku kernelt lehet irni ekkora meretben is.

Ezek utan a linux kernelere a "boszme" eleg talalo jelzo szvsz.

Nyilvan a mikorkernelesitesre gondolok... de tudom, hogy vegtelen sok szakmai vita zajlott mar ebben a temaban, nalam joval hozzaaertobbek kozott is.

Viszont kiemelnem, hogy a linux teljesen veletlenul, esetlegesen lett egyeduralkodo a sajat teruleten (ahogy ez az open source berkekben tipikus), es nem vagyok biztos abban, hogy nem lenne-e mindenkinek jobb egy mikrokernel architektura. Talan egy folytonos vitatemaval kevesebb lenne.

szerintem a monolitikus kernelstruktúra a jobb, bár valamelyest kényelmetlenebb, a használata. Mikrokernel struktúra esetén, nincs lehetőség a kernelmodulok közötti optimalizációra, ergo lassabb, méghozzá sokkal. Habár az is igaz, hogy ekkora monolit esetén ember legyen a a talpán aki profin meg tudja irni a modulok közötti optimalizációt. Ennek ellenére én továbbra ia a monolitikus kernelt preferálom. Egy mikrokernel struktúra esetén 10*annyit kellene izzadni ha kernelmodult szeretnék készíteni, mint most, és egy fikarcnyival sem lenne jobb, csak lassabb, és ha szerncsénk van akkor kénylemesebb.

azért nincs értelme szétszedni, mivel a forrás legnagyobb része driverek, és csak a architektúrális eltérések vannak az aarch könyvtárban.
windows esetén nem kapsz ennyi drivert, hanem ott neked kell egyesével pótolni.
de ha megnézed más free os-ek forrását, akkor azok sem a legkisebbek pl freebsd

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

"windows esetén nem kapsz ennyi drivert, hanem ott neked kell egyesével pótolni."

na épp ezért nem tekintem oprendszernek a win-t.
linux/bsd alatt alátolom a hardvert és működik. Valahogy itt kezdődik az operációs rendszer. Hogy nem nyavalyog, mikor cserélgetem a vasat alatta.
Meg nem nyavalyog driver-ért.

/mazursk

A WRK relative kicsi merete azt bizonyitja, hogy teljeserteku kernelt lehet irni ekkora meretben is.

Mmm, ok, itt most meg kell védenem a Linuxot...

A méretkülönbség kicsit becsapós lehet, több okból is és emiatt azt gondolom, hogy nem is túlságosan fer a tanulmányban lévő ilyen irányú összehasonlítás.

A WRK az NTOS kernel magját (igen, a magnak a magját :) tartalmazza csak és a hozzá szükséges kiegészítőket. Nincsenek benne a driverek, sőt még a TCP/IP stack sem, csak a memóriakezelés, az alap I/O alrendszer, a jogosultságkezelés, a kernel-szintű teljesítmény naplózáshoz szükséges keretrendszer és hasonlók. Nagyjából (de csak nagyjából :) mintha Linuxnál nem szerepelne benne semmi olyan, amelyet kernel modulként is lehet fordítani.

Linux/FreeBSD/Solaris-nál minden bizonnyal a teljes kernel forrásfát emelték be az adatbázisba és a driverektől kezdve mindenre vonatkoztak a lekérések, ezért messzemenő következtetéseket nem érdemes a Windows kernelhez képest levonni, én is inkább csak a Linux vs. Solaris kernel összehasonlítását nézegettem.

A százalékos összehasonlításnál talán kevésbé jön elő ez a probléma, valószínűleg ezért is tartalmaz jóval több ilyet a felmérés, de kizárólag csak a sorok számát vagy a kommentek számát önmagában vizsgálni nincs értelme, mert nyilván teljesen fals eredményt kapunk. Ezért is számoltam én mindegyikre inkább az egy sorra jutó megjegyzések számát, mert úgy már jobban összehasonlíthatók egymással az eredmények.

ROTFL
Ugy latom fogalmad sincs mi van egy arch reszben.
Es nem nagyon lattal mast vanilla es distro kerneleken kivul.

Elmondom, hogy a legtobb architekturanka kulon git faja van, amibol az arch kerdesekben vanilla kernel taplalkozik es forditva egyeb kerdesekben.

Az architekturakon belul kolon al arhitekturak vannak, es kulon boardok kozel sem mind olyan egyseges, mint az x86.
Tetelezuk fel, hogy van egy at91rm9200 magu eb9200-as fejleszto panlod.
Azt lathatod, hogy az ARM arhitektura kb. 7618k kodot tartalmaz.
Ebbol 3583k+494k mach*+plat* konyvtar ~3606k nem kell ujrairnod, min. 20-szor, mert kozos es ,mert enyiben egyeznek. (es meg egy arhon belul vagyonk, kepzeld el mekkora melo lenne, ha mindenki kulon utakon jarna, hanyszor kene feltalalni a meleg vizet)

at91 konyvtar 333k , de ebbol 50k kozos es egy adott eszkozhoz kell ~25k board miatt, kell ~25k a cpu alalfaj miatt.
Ha most te csinalsz egy egeszen mas panelt, lesz egy 25k fileod amit atirkaszhatsz a sajat panelodra, ha az at91-nek jelenik meg uj alfaja 50k kell atirnod.

Most azert akarsz ~200 teljesen kulon utakon jaro fat, mert maskep nez ki egy syscall, vagy masutt van megszakitas tabla ? LOL

Ez kicsit olyan, mint az adatbazis absztrakcios retgekeg egy resze. Tehat a Linux egyseges feluletet biztosit minden arhitekturan a felhasznalo fele, ahogy DB absztrakcios retgek mondjuk minden RDMS felett, az DB abstraction layer konyen kigeszitheto uj driverekkel (mint ahogy kernel archokkal, valahol 2 mernok honapot olvastam binutils+gcc atirasa (teljesen) mas archra cimszoval, kb. kernel is ennyi lehet, 4 jo mernokkel a 1 honap mulva bevetheted az uj arhitekturadat ugy, hogy kvazi minden megy rajta, nem veletlen, hogy legtobb uj elvetemult rendszerhez Linux vagy ucLinux tamogatas elsokent jelenik meg)

Fogadhetnek, hogy amikor bedugtam az USB CD olvasot,pendrivot egy arm szutyba szinte, semmit nem kellett csinalniuk a fejlesztoknek miutan az USB hostot belotek, hogy a CD olvaso is menjen vele.

Szerinted 3+ BSD fork jol jart azzal, hogy kulon utakon jarnak ? Van ami mindharomba egyszere kerul bele, vanak olyan teruletek amikben egyik-masik evekkel elorebb jar a tobbi BSD-hez kepest.

Microkernelezest meg abba lehet hagyni, legkevesebb globalis bizbaszok aranya a Linux kernelben.
Tudni lehet, hogy egy arch-nak miket kell biztositani a kernel szamara, jol el van szeparalva.

Tudom, hogy microkernel nem errol szol. DE megis mindig azt hozzak fel a hasonlo hozzaszolok , hogy "milyen szepen elkulonulnek a dolgok, es nem gabajodnak egymasba a szigoruan meghatrozott szabalyok szerint komunikalo reszek" , kevesebb globalis szutty elorvetiti, hogy keves lehetoseg is van ossze-vissza hivatkozni/hivni mindenfelet.

A talicskat nem jo hasonlitani a zabkasaval, most már rájöttem :)

Arra gondoltam, hogy egy server sereg kell, hogy megvalósíts egy most kernelnek nevezett valamit. Ezek közötti kommunikáció viszonylag szűk, meg van határozva pár általános célú IPC funkció amivel ezt-azt áttolhatsz és kb. ennyi.

Monolitikus kernelben a részek közötti "kommunikáció" meg egy sima függvényhívás és kész. (bár itt is előfordulnak kernel daemonok)
Nincs semmi korlátozás arra vonatkozólag, hogy egy globális függvényt mely kernel rész hívhat, nincs éles határvonal a részek között (a kódban persze van), nem ellenőrzik, hogy ami hívta az valóban hívhatja -e... stb. Azért elég hülyének kell lenni ahhoz, hogy valaki amiatt lője magát lábon, mert egy egészen máshoz tartozó függvényt hív.
Két rész közötti interface-t lehetőségek szerint olyanra alakítják ki, amilyen az adott feladatnak leginkább megfelelő.

Mellesleg RMS(HURD) is nyilatkozott már olyat, hogy micro kernelesdivel könnyen össze lehet zavarodni az üzenetek követése közben, ezért is nem haladt a HURD.
Jelentős többlet munkát igényel a részek összekapcsolása is.
Aztán rá kellett jönniük, hogy bizony-bizony lassú is.

( Lacyc3 v | 2008. 05. 18., v – 10:22 )

Azért mókás a figura, főleg azért mert elkérni az M$-től a forrást és meg is kapta :)

( rtlin | 2008. 05. 18., v – 14:38 )

Az összehasonlítás során a szakember ezen kernelek különböző konfigurációit vizsgálta (több mint 10 millió sornyi kódot), tárolta le négy adatbázisba, majd az adatbázisokon különböző lekérdezéseket futtatott.

LOL "Al Bundy" az IT sektorba igazol, és kellően megalapozottlan áltudományos módszereket honosít meg! Csak remélni tudom sok jelentőséget senki nem tulajdonít ennek a felmérésnek! :)

Még kicsit szoktatom magam ahoz ahogy ez az görög a kód minőségét is ilyen objektíven értékeli: sorok-, változók- és elágazások száma stb. Mit is kezdjünk akkor most az OOP nyelvekkel?

( turul16 v | 2008. 05. 18., v – 14:59 )

Ami erdekes, hogy troljaink gyakran jonnek azzal, hogy monolitikus kernelben minden globalis es teljesen atlathatatlan dolgot eredmenyez. Ezzel szemben kiderul, hogy globalis nevteret a Linux szenyezi a legkevesbe.

Hatranynak nevezi cikk, a cimkeket vagy file lathatosagu elemeket, ami szerintem egy kernelnel foleg badarsag. (Mellesleg win all ilyen szempontbol a legroszabbul)

Kodolasi stilus kovetezettesege winnel latvanyosan rossz, bar typedefeknel megis a legjobb.

non-#include LOL, konfiguralhato kerneleket hasonlitani ilyen szempontbol, azt hinne az ember, hogy Linuxban van az ilyenbol a legtobb, de megsem. (Szerintem a legtobb minden bene allithato)

Van egy ket meglepo eredmeny es furcsa szempont pl. "Characters per line".

En utalom globalis nevter teli szemeteleset, de gondolom mindenki ugy solyozza ezeket az ertkeket ahogy akkarja. Tenyleg legtisztessegesebb, ha azt mondjuk nincs egyertelmu gyoztes/vesztes.

Fuggveny szeru makrok szama is meglepo eredmenyu.

és azt ne felejtsük el, hogy itt a linux 2.6.18-as volt, szóval már lehet javában elavult a felmérés, a függvényszerű makrókat felváltják a linuxban lassan a static inline foo() függvények, typedefecet meg irtják a kernelből, csak ott használják ahol nélkülözhetettlen

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

static inline-okat a header-ekben írják, az feltebb felvázolt probléma miatt.

a typde-et meg a kód jobb olvashatósága miatt írtják, hogy nem legyen n+1 neve ugyan annak a struktúrának 


Please don't use things like "vps_t".

It's a _mistake_ to use typedef for structures and pointers. When you see a

	vps_t a;

in the source, what does it mean?

In contrast, if it says

	struct virtual_container *a;

you can actually tell what "a" is.

Lots of people think that typedefs "help readability". Not so. They are
useful only for:...

CodingStyle és még jópár indokot felsorolnak

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

( kikke | 2008. 05. 18., v – 15:40 )

Miből maradtam ki... Ennyi Kovács ügynököt...
--
the tide is turning

( Botond | 2008. 05. 20., k – 15:26 )

A kommentről jut eszembe: nem létezik, hogy a RK 192K-utasításnyi kódjához 190K komment is jár. Illetve ha mégis, az szerintem csak úgy jöhet ki, hogy minden fájl elején ott van a copyright.
Látta valaki a WRK forrásokat? Tényleg ott a copyright?

(A Linux valóban rosszul kommentezett. De csak annak, aki nem látta még az X forrását.)