A GNU / Linux ingyenes szoftverek és disztribúciók gyökeres változást hoztak az operációs rendszerek fejlesztési módjában azáltal, hogy fejlesztő közösséget építettek fel az Internet körül.
Ennek az internetes közösségfejlesztésnek a következő jellemzői vannak, amelyeket a cikk további részében részletezünk:
Ez a gyors ciklus nem alkalmas ipari vagy személyes használatra. Ezután jönnek a GNU / Linux disztribúciók, amelyek fő feladata a stabilitás biztosítása azáltal, hogy a Linux kernel verzióit lassabban biztosítják, és ezeket a verziókat több éven keresztül fenntartják.
Greg Kroah-Hartman elmagyarázta a Linux kernel fejlesztési folyamatát a Groklaw számára . Greg Kroah-Hartman már írásban Linux vezetők, mivel 1999 , és jelenleg a fenntartó valamilyen kernel alrendszer (USB, illesztõprogrammag, sysfs linux-hotplug, udev, stb.)
A folyamat működésének megértéséhez először meg kell értenie, hogy milyen javítás (vagy patch francia). A kernelben elfogadott változtatások megszerzéséhez a fejlesztőknek elő kell állítaniuk egy javítást, és el kell küldeniük a módosítani kívánt kód karbantartójának. Ezt úgy teszik, hogy megváltoztatják a kernel forráskódját, majd a diff eszközt használják . Ez az eszköz létrehoz egy szöveges formátumú fájlt (a javítófájlt), amely felsorolja a módosított sorokat állapotukban a módosítás előtt és után, az alábbi példában látható módon:
--- a/drivers/usb/image/microtek.c +++ b/drivers/usb/image/microtek.c @@ -335,7 +335,7 @@ static int mts_scsi_abort (Scsi_Cmnd *sr mts_urb_abort(desc); - return FAILURE; + return FAILED; } static int mts_scsi_host_reset (Scsi_Cmnd *srb)A példa azt mutatja, hogy a 'drivers / usb / image / microtek.c' fájlnak van egy sora, amely a változás előtt volt:
return FAILURE;és most változás után jár:
return FAILED;Ezt a szöveges fájlt el lehet küldeni másoknak, akik azonnal láthatják a megváltozott kódsorokat, és visszajelzést adhatnak a változásról. A javítás alkalmazásához mindössze annyit kell tennie, hogy futtat egy másik patch nevű programot , paraméterként átadva neki a patch fájlt.
A Linux kernel minden fejlesztése a javítások e-mailben történő nyilvános küldésével történik. Megtekintve a fő kernelfejlesztési levelezőlistát (például a http://marc.theaimsgroup.com/?l=linux-kernel címen ), láthatjuk, hogy ezek a javítások százai kerülnek elküldésre, megvitatásra, kritikára.
A kernel-fejlesztő csapat olyan emberek csoportja, akik ál-piramisba szervezték magukat. A piramis tövében több száz fejlesztő található, akik 1 és néhány ezer folt között írnak. Ezek a fejlesztők elküldik javításaikat az általuk módosított fájl vagy fájlcsoport karbantartójának. A karbantartók listáját a MAINTAINERS fájlban őrzik, amely a kernel fő fejlesztési ágának forrásaiban található. Jelenleg körülbelül 300 különböző fenntartó van.
Ha a karbantartó a változást indokoltnak tartja és jóváhagyja, elküldi az érintett kernelrendszer karbantartójának. Szinte az összes rendszermag alrendszernek van fenntartója (hálózat, USB illesztőprogramok, virtuális fájlrendszer, modulmag, illesztőprogrammag, Firewire illesztőprogramok, hálózati illesztőprogramok stb.). Ezek az emberek szerepelnek a MAINTAINERS fájlban és mindegyikükben. a fájlok vagy az illesztőprogramok tudják, kinek küldjék el a változtatásokat.
Az alrendszer fenntartói ezután beküldik a javításokat jóváhagyásra Linus Torvalds vagy Andrew Morton számára, és ekkor kerül be a javítás a kernel fő fejlesztési ágába.
Ne feledje, hogy minden olyan személy, aki megérinti a javítást ezen átviteli lánc mentén, hozzáad egy "Signed-off-by:" sort a kódhoz, amely pontosan megmutatja, hogy ki hajtotta végre a módosítást és ki hagyta jóvá. Hiba esetén a hibás emberek azonnal azonosíthatók.
Minden fejlesztés e-mailben történik. A fejlesztők e-mailben küldik el a javításokat a különböző levelezőlistákon szereplő más fejlesztőknek. Van egy fő Linux-kernel lista . Ez a lista naponta körülbelül 200-300 üzenetet kap, és a kernel szinte minden aspektusát ott tárgyalják. A nagy forgalom miatt a mag összes alrésze létrehozta saját levelezőlistáját, hogy együtt működjenek egy adott területen.
Az e levelezőlistákon közzétett üzeneteket speciális webhelyeken archiválják, például a „ http://marc.theaimsgroup.com/ ” ( Archívum • Wikiwix • Archive.is • Google • Mi a teendő? ) És http: // www .gmane .org , amelyek lehetővé teszik a múltban terjesztett üzenetek konzultációját és kutatását.
Tehát egy patch felkerül a levelezőlistára. Más fejlesztők átnézik, javaslatokat kínálnak a listán található másolattal, hogy mindenki tudassa velük. Végül konszenzust találunk, és a karbantartó elfogadja a javítást, hogy továbbítsa a láncban.
Ennek működésének szemléltetéséhez vegyünk példát Arjan Van de Venre, a Linux kernel fejlesztőjére és Fastboot projektjére, amely csökkenti a GNU / Linux rendszer indítási idejét.
Arjan, miután mindent átgondolt, ami lelassulhat, amikor a kernel elindul, Arjan megoldást talált egy 3 foltos készlet formájában. Ezek a javítások itt láthatók:
patch 0/3: fastboot patches series 1 patch 1/3: fastboot: Create a "asynchronous" initlevel patch 2/3: fastboot: turn the USB hostcontroller initcalls into async initcalls patch 3/3: fastboot: convert a few non-critical ACPI drivers to async initcallsSzámos fejlesztő lépett be, a szál itt követhető:
http://thread.gmane.org/gmane.linux.kernel/709026/focus=709139És akkor Linus Torvalds közbelépett, és úgy érezte, hogy a megoldás nem kielégítő, mert nem a megfelelő részletességi szinten:
http://article.gmane.org/gmane.linux.kernel/743021/Az eredeti szerző figyelembe vette Linus észrevételeit, és új javaslatot tett a következő foltok sorozatával:
http://article.gmane.org/gmane.linux.acpi.devel/36513amelyeket ismét kommentáltak, és a fejlesztés folytatódott.
Amint a fenti példa mutatja, a kernel minden fejlesztése nyilvános, mindenki számára látható, mindenki számára újra nyilvánosan archiválva. A Linux kernel kódjának több szempár által végzett nyilvános felülvizsgálata elengedhetetlen, mert segít a minőség fejlesztésében.
A korai közzététel, a közzététel gyakran a szabad szoftverfejlesztés alapvető szabálya.
A Linux kernel fejlesztésének kezdetén ( 1991 körül ) nem volt ritka, hogy Linus Torvalds naponta többször is kiadta a Linux kern új verzióját. Ezzel a fejlesztési modellel a Linus nagyon hatékony módon vonta be felhasználóit a fejlesztési folyamatba. És ez a módszer a közös fejlesztők közösségének ápolására és az Internet használatára olyan együttműködési eszközként, amilyet még senki más nem tett, kulcsfontosságú tényező volt a Linux kernel sikerében.
A kezdetektől fogva ez a fejlesztési ciklus kissé lelassult, azonban a Linux kernel továbbra is nagyon gyors ütemben fejlődik a zárt forráskódú szoftverekhez képest (Windows XP 2001-ben , Windows Vista 2007-ben ): 2.6 verzió 12 hétig, az alábbi táblázat szerint:
Kernel verzió | 2.6.0 | 2.6.1 | 2.6.2 | 2.6.3 | 2.6.4 | 2.6.5 |
---|---|---|---|---|---|---|
Kiadási dátum | 2003. december 18 | 2004. január 9 | 2004. február 4 | 2004. február 18 | 2004. március 11 | 2004. április 4 |
Kernel verzió | 2.6.6 | 2.6.7 | 2.6.8 | 2.6.9 | 2.6.10 | 2.6.11 |
Kiadási dátum | 2004. május 10 | 2004. június 16 | 2004. augusztus 14 | 2004. október 18 | 2004. december 24 | 2005. március 2 |
Kernel verzió | 2.6.12 | 2.6.13 | 2.6.14 | 2.6.15 | 2.6.16 | 2.6.17 |
Kiadási dátum | 2005. június 17 | 2005. augusztus 29 | 2005. október 28 | 2006. január 3 | 2006. március 20 | 2006. június 18 |
Kernel verzió | 2.6.18 | 2.6.19 | 2.6.20 | 2.6.21 | 2.6.22 | 2.6.23 |
Kiadási dátum | 2006. szeptember 20 | 2006. november 29 | 2007. február 4 | 2007. április 25 | 2007. július 8 | 2007. október 9 |
Kernel verzió | 2.6.24 | 2.6.25 | 2.6.26 | 2.6.27 | 2.6.28 | 2.6.29 |
Kiadási dátum | 2008. január 24 | 2008. április 17 | 2008. július 13 | 2008. október 9 | 2008. december 24 | 2009. március 23 |
Kernel verzió | 2.6.30 | 2.6.31 | 2.6.32 | 2.6.33 | 2.6.34 | 2.6.35 |
Kiadási dátum | 2009. június 9 | 2009. szeptember 9 | 2009. december 3 | 2010. február 24 | 2010. május 16 | 2010. augusztus 3 |
Ma a Linux kernel fejlesztését több ágban végzik :
Egészen április 2005 , a kernel fejlesztő csapat használt kereskedelmi BitKeeper szoftver kernel forrás release menedzsment. A 2005. április 5, a BitMover vállalat bejelentette, hogy kizárólag kereskedelmi BitKeeper kínálatára összpontosít, és visszavonja az ingyenes (de nem ingyenes) klienst, amelyet számos ingyenes fejlesztő használ.
Ez az esemény arra késztette a Linux kernel fejlesztőit, hogy feltalálják a saját Git nevű verziókezelő eszközüket .
A GNU / Linux disztribúciók szerepének megértéséhez fontos, hogy néhány fogalom szerepeljen a Linux kernelének kerületén és annak modularitásán.
A Linux kernel hatókörét gyakran félreértik, mert ugyanazt a Linux kifejezést használják a Linux kernelre ( magára a kernelre ), a kernelfa ágra és a GNU / Linux disztribúciókra, amelyek mindegyikének egy további hatóköre van. ábra. A GNU / Linux disztribúció több ezer szoftvercsomag és a kernelág együttese, amely magában foglalja a kernelt, az illesztőprogramokat, a hálózati összetevőket és a fájlrendszereket.
Ha a Linux kernel filozófiáját is alátámasztó Unix filozófiát egy szóval összegeznénk, akkor ez a szó valószínűleg modularitás lenne. A Unix-ot eredetileg azzal a céllal fejlesztették ki, hogy rendkívül moduláris legyen, rugalmasabb és felhasználóbarátabb, mint a nap monolit és összetett operációs rendszere. Ez a modularitás kitartott, és a Unix-szerű operációs rendszerek mintegy 35 éve alatt folyamatosan átalakult; jelentős tényező volt figyelemreméltó élettartamukban és életkoruk ellenére állandó népszerűségükben (ami az informatikai szabványok szerint fontos).
A GNU / Linux egy nagyon moduláris operációs rendszer. A felhasználó csak a neki megfelelő alkatrészeket telepítheti. A legtöbb esetben a telepítési menükben kínált alapértelmezett telepítéseket választja, de nem muszáj. Például, ha szervert telepít, akkor deaktiválhatja a grafikus felületet a memória és a processzor felszabadítása érdekében más feladatokhoz.
A modularitás a kernellel kezdődik. Még akkor is, ha a felhasználók nem a saját kernelüket állítják össze, a rendszerindító program jelenléte (amely maga GRUB vagy LILO is lehet ) emlékeztet arra, hogy nem korlátozódnak egyetlen telepített kernelre. Amikor a felhasználók lefordítják saját kernelüket, megtudják, hogy a tartalma konfigurálható, és hogy sok illesztőprogramot szükség esetén modulként tölthet be a rendszer, ahelyett, hogy a kernelbe fordítanák.
Ugyanez a modularitás található meg az alrendszerek szintjén is. A kern több mint 30 különböző fájlkezelő rendszerrel működik. A szoftvercsomag-kezelésnek két fő formátuma van, az RPM és a Debian, valamint számos újabb formátum, például a Gentoo terjesztés portolása. Más alternatív rendszerek még fejlesztés alatt állnak.
Az alrendszerek tovább fejlődnek. Vegyük az eredeti nyomtatási rendszer, az lpd példáját a Berkeley-i Unix-tól. Az évek során az LPRng kiterjesztette, majd felváltotta a CUPS (Common UNIX Printing System). Hasonlóképpen, amikor néhány évvel ezelőtt az XFree86 elfogadhatatlanná vált a licenc megváltoztatása miatt, amely miatt nem lett szabad, az X.org az XFree86 egy korábbi verziójának villája váltotta fel. Az utóbbi időben az ALSA számos disztribúcióban felváltotta az OSS-t (Open Sound System).
Az előzmények megismétlődnek a felhasználói felületen. Az alapértelmezett shell a legtöbb disztribúcióban a GNU bash , amely az évek során fejlődött. Ugyanakkor több mint fél tucat lehetséges helyettesítő van, köztük tcsh, csh, pdksh, zsh és BusyBox.
Ugyanez a változatosság mutatkozik az irodai környezetben is . A KDE és a GNOME a legelterjedtebb környezetek, de néhány felhasználó, aki a teljesítményt prioritásként kezeli a könnyű használat helyett, például az IceWM-et használja a KDE vagy a GNOME helyett. Ami az ablakkezelőt illeti, a KDE a KWM-et, míg a GNOME a Metacity-t választotta, de ezeket az alapértelmezett menedzsereket több tucat alternatívával lehet helyettesíteni.
Ez a modularitás lehetővé teszi a rendszer egyes részeinek frissítését anélkül, hogy a rendszer többi részét érintené. Például a GNOME vagy a KDE legújabb verziója telepíthető a kernel verziójának megváltoztatása nélkül.
Ez a választási szabadság nem feltétlenül alkalmas minden felhasználó számára. Itt jönnek be a GNU / Linux disztribúciók.
Mint Ian Murdock, a Debian disztribúció alapítója egy 1993-as kiáltványban megjegyezte :
A disztribúciók elengedhetetlenek a Linux jövője szempontjából. Megszüntetik annak szükségességét, hogy a felhasználó megkeresje, letöltse, összeállítsa és telepítse, valamint számos alapvető eszközt tartalmaz egy működő Linux rendszer felépítéséhez. A rendszer kiépítésének terhe a disztribúció készítőjének vállára hárul, és munkáját több ezer más felhasználóval meg lehet osztani. Szinte az összes Linux-felhasználó elkezdi a disztribúciót, és többségük a kényelem kedvéért továbbra is használja a disztrót, miután megismerkedett a rendszerrel .A GNU / Linux disztribúciók valóban fontos szerepet játszanak a Linux kernel köré épített ökoszisztémában.
Összegyűjtik a legjobb szoftvercsomagokat (például a Debian disztribúció több mint 10 000 szoftvercsomagot tartalmaz) egy integrált ajánlatban, amely a felhasználók vagy az ügyfelek számára készült.
Ezenkívül kevés ember és még kevesebb vállalat engedheti meg magának a gyors, 8-12 hetes kernelkiadási ciklust. Az eloszlások az igényeiknek jobban megfelelő ciklust biztosítanak. Az új verziók kiadásának gyakorisága az egyes disztribúciók saját belátása szerint van megadva, és hat hónapig terjedhet a fejlettebbek, mint a Fedora vagy az Ubuntu esetében , és 12 és 18 hónap között a nagyobb kereskedelmi terjesztéseknél, mint például a Red Hat , a SuSE és újabb. év a Debian számára .
A Red Hat disztribúció fejlesztési ciklusa
A Debian disztribúció fejlesztési ciklusa