GNU/Linux disztribúciók idővonal - 201110

Címkék


(nagyítható)

Ha valaki nem ismeri (vagy csak úgy érzi, hogy elveszett a kavalkádban és be akarja tájolni magát), annak érdemes egy pillantást vetnie arra, hogy hogyan alakultak ki napjaink Linux disztribúciói, melyiknek melyik "nagy öreg" Linux disztribúció (Debian, Slackware, Red Hat) az őse. A közelmúltban frissült a "GNU/Linux Distribution Timeline" a 11.10-es verzióra...

Hozzászólások

Nem lehet egyszerű összehozni egy ilyent. Főleg azért, mert vannak olyan disztrók, amik "alapot" váltanak. Pl. a Crunchbang Ubunturól Debianra váltott. Helytelenül még mindig Ubuntu variánsként van kezelve.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

http://deblogian.blogspot.com

Tutira vettem hogy nem lesz rajta az UHU. Tévedtem :)

Kellemes kis kép. Jobban örültem volna forrás SVG-nek. :(

--
GPLv3-as hozzászólás.

Pontosan ezen gondolkoztam, hogy miert is kulonbozne az android barmelyik disztrotol. Ugyanugy van kernele, csomagjai, csomagkezelese stb. Tipikusan egy modern linux disztro. Az, hogy nem X-et hasznal...
Bar akkor lehetne embedded linuxnak is hivni, csak az imho egy mas kategoria.

A distribute szó magyar fordításban eloszt, kioszt,...

Én úgy képzeltem el a dolgot, hogy a disztribúciók tulajdonképpen kiosztják a Linuxos szoftvereket a nép között, hogy használjátok.
Az Androidot ezért gondoltam kivételnek, mert semmi nincs rajta, ami más Linuxon megvan a kernelt leszámítva.

Az Android egy teljesen más rendszer, nincs X, nincs OpenOffice, nincs KDE, nincs GNOME,...

Mialatt a nagy disztribúciók között a csomagválaszték tekintenében az átfedés 90% körül mozog, addig Android ez esetén 0%.
Hiába, hogy a rendszermag közös, de szerintem annyira más család, hogy nem oda való.

Hát akkor? Például Debian: ,,A Debian szabad számítógépes operációs rendszer. Az operációs rendszer alapvető programok összessége, amelyek a számítógép működéséhez szükségesek.

A Debian többet nyújt egy csupasz operációs rendszernél: több mint 29000 csomagot, azaz előre lefordított, tetszetős formátumba csomagolt szoftvert tartalmaz, amelyet könnyen telepíthetsz a gépedre."

Miért ne lenne OS, ha azt mondják magukról, hogy ők OS, és mindenféle kernelekkel működnek?

Miért/hol tér el szignifikáncsan a Debian az Androidtól, hogy külön kategóriában kell őket kezelni? Mert elvileg mindenhol fut az egyik, ahol a másik, és ugyanazt a célt is szolgálják.

Puppy linux felhasználó

az AtheOS/Syllable Linux disztribúció?

Az hagyján. De nem lehetne, egy ami "rendesen működik"? :-)
Tudom flamewar szagú, de csak pár elvetemült példa:
- Ubuntu == Unity és más állatságok
- Debian == openssl "minor" package upgrade

Szóval azt látom, hogy a nagy szabadságban az egész, akárcsak a Linux aprózódik vadul, ahelyett, hogy valamilyen szinten azért a fejlesztői és tesztelői erőforrásokat koncentráltan egy dpkg alapú disztribúcióba rendezve tennénk. Tudom, utópia és értem a fejlesztők kis önérzetét és döntéseik érzelmi hátterét.
De akkor is no. Szipp!

Egyetértünk. Én eleinte a nyitottságban annak a lehetőségét láttam, hogy nyitott fórumokon (nem feltétlen a mostani netes formában, az nagyon nem konklúzív) megvitatott terv szerint folytatja mindenki a fejlesztést, akinek célja van vele. És mindenki használja a másikét, kivéve ha kedvtelésből akar újat fejleszteni, esetleg akkor is egy meglévő lehetséges, kisérleti irány szerint kezd el dolgozni, hátha új, reményteljes irányt hoz létre. Mindezt persze nyitott kommunikációs szabványok mentén.

Ehelyett az az opensource, hogy írja már meg valaki helyettem az ótvar részeket, a manualt, és persze debuggoljon, akinek bug-ja van. Tisztelet, tényleg nagy tisztelet a kivételnek. Hja, és kezdem unni, hogy mindig, mindenki tud egy jobb zenelejátszót írni.

Egy kérdés: ha az ábrán található "adatokat" és kapcsolataikat adatbázisban szeretném évszámra és névre kereshetően tárolni, és teszem azt később szeretnék beszúrni még ide-oda ezt-azt, akkor hogy induljak neki a feladatnak?

Az adatbáziskezeléssel-tervezéssel most ismerkedek, és lila gőzöm sincs, hogy hogy illene elkezdeni ezt a feladatot, de szvsz a relációs megközelítés nem a legcélravezetőbb.

Wow! Meglepett, hogy a Slackware ág ekkora, és ennyire élő.

szepen mutatja, hogyan aprozodik el az egesz. most kepzeljetek el, ha ennyi munka kezben lett volna tartva, es csak a debian, slackware es redhat vonal futna vegig. kicsit mas lenne a jelenlegi helyzet.

Pontosan ezt kérdeztem én is, és a válasz az volt, hogy "honnan tudjam?"
Ha másképp tennéd föl a kérdést, akkor te sem tudnád a választ. Amíg valaki meg nem mutatja a gyakorlatban, addig egyáltalán nem lehetünk biztosak benne, hogy a bazár típusú fejlesztés vezethet-e egyáltalán más eredményre.

Az is érdekes, hogy ha van több, egymással többé-kevésbé ekvivalens project, és az egyik lefejleszt valamit, ami valóban jó, akkor a többi project is lefejleszti ezt a feature-t. Így születik ugyanarra a problémára n megoldás. Csak egy minimális összefogás kellene ahhoz, hogy elég legyen csak az egyik projecthez lefejleszteni a feature-t, a többi pedig a már meglévő forráskódot jóval kevesebb munkával portolhatná. Van ilyen, BSD-kben sok kódot vesznek át egymástól (persze legalább ennyit meg nem).

--
Don't be an Ubuntard!

Ugye a zárójeles megjegyzéseket is el szoktad olvasni? Nyilván itt a minimális összefogás alatt nem arra gondoltam, hogy eldobják az összes bds forkot, és csak az egyiket tolják tovább, mert pont azért születtek forkok, mert mindenkinek mások az elképzelései. De ahol lehet, ott átemelnek kódokat egymástól, pl. a drivereket ha nem muszáj nem írják újra nulláról, hanem portolják.

--
Don't be an Ubuntard!

FYI: a linux világban egy kernelt használnak, a drivereket nem írják a disztribúciók újra a nulláról, rettentő sok ugyanazt a csomagkezelőt/csomagváltozatot (vagy deb, rpm a fő csapásvonal) használja, sokan használják a pulseaudiot, az upstart-ot, vannak olyan disztrók, amik más disztrók csomagjait átveszik (Debian -> Ubuntu), sőt van olyan Linux disztró, aminek a csomagjait még Solaris alapú projektek is átveszik (Nexenta).

Most már kíváncsi vagyok, hogy a BSD világban mi az a példaértékű - konkrét példát kérek - ami megérdemelte, hogy felhozzad.

Dillon a DragonFly BSD-ben gyakorlatilag újraírja az egész kernelt, új, senkivel sem kompatibilis fájlrendszert fejleszt (HAMMER). Tényleg nem húznak másfelé. Gyakorlatilag a DragonFly BSD létrejötte egy jó példája annak, hogy mennyire aprózódnak ott is az erőforrások.

Nekem egyébként ezzel semmi bajom. Mindenki azzal foglalkozik, amivel akar.

"hanem portolják."

Hát ez az. Ha a te hülyeségedet hajtogatnám, akkor azt mondanám most, hogy "de hát ne portolják, hanem fejlesszenek egyet! akkor nem kell portolgatni!"

--
trey @ gépház

Nem állítottam, hogy a disztribúciók bármilyen drivert is fejlesztenének, csak azt akartam kifejezni, hogy 2 bsd között nagyobb a különbség, mint 2 linux disztribúció között, és ehhez képest mégis tudnak együtt dolgozni.

Amikről te beszélsz, mint pl. csomagkezelő, pulseaudio, upstart, ezek szoftverek. Mivel a disztribúciók ugyan arra a rendszerre építenek (kernel, libc, alsa, stb.) ezért nyilván semmi akadálya nincs annak, hogy ezeket egyik disztribúció átvegye egy másiktól. A csomagok átvétele már érdekesebb kérdés, forráscsomagok átemelése azért nem túl bonyolult (én is csináltam már úgy csomagot, hogy egy debian csomagból szedtem ki az ahhoz szükséges információkat), bináris csomagoknál viszont kizártnak tartom, hogy a két környezet egymáshoz képest jelentős eltéréssel rendelkezhet, mint pl. az egyik disztribúcióban másik libc verziót használnak mint a másikban.

Példának nézd mondjuk ezen az oldalon a "Development" oszlopot: http://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers
Mint látható, mindegyik BSD-nél van olyan driver, amit másik BSD-től vettek át, persze van amelyiknél több, van amelyiknél kevesebb. Nyilván ezt valahol az tette lehetővé, hogy mind ugyanazon rendszer fogkjai, de mivel mindet külön utakon fejlesztik, ezért ez még így is jelentős eredmény.

Látom a zárójeles megjegyzést még mindig nem olvastad. Attól, hogy sok ponton többé-kevésbé kompatibilisek egymással, attól még vannak olyan területek, ahol jelentős eltérések mutatkoznak. Pont azért, mert ezek azok a területek, amik miatt valaki (pl. Dillon) úgy döntött, hogy csinál egy forkot.

Az engem se zavar önmagában, hogy van több alternatíva egy feladatra. De ott, ahol nincs különbség ezen projectek között, ott felhasználhatnák egymás kódját (ha már opensource). Ehhez viszont az kell, hogy megállapodjanak közös interface-ekben, amikre lehet építeni, ez pedig pár kivételtől eltekintve nem létezik.

--
Don't be an Ubuntard!

De könyörgöm, itt széthúzásról és a felaprózódásról volt szó. A BSD-k pontosan a legjobb példái ennek a szétaprózódásnak. Egy közös helyről jöttek, összevesztek, mások lettek a célok. Külön kernelük van, külön csomagkezelő rendszerük van (pkgsrc (netbsd, dragonfly), ports (freebsd), ports (openbsd)).

Alig vannak, de tök mást csinálnak. Az meg, hogy átvesznek kódokat sokkal inkább annak köszönhető, hogy kevesen vannak, nem annak, hogy "húh, gyerekek működjünk közre mert az milyen jó". Egyszerű erőforráshiány betapasztása.

--
trey @ gépház