Miért Gentoo? Miért nem Debian?

Többször faggattak már erről, ezért a Médiabirodalom blogon leírtam a gondolataimat a disztróválasztásommal kapcsolatban.

Hozzászólások

so -- shared object

egyik előny: a rendszergazda felelőssége eldönteni, hogy mit forgat bele -- innentől értelmezhetetlen a QA a Gentoo-ra

új opciót (use flaget) hozzáadni igen egyszerű -- annyira egyszerű, hogy nemhogy a végterméket (a lefordított programot) nem tudják ellenőrizni az összes variációval, hanem magát a fordítás sikerességét sem. (Simán lehet olyan use-flag listát készíteni, kifejezetten pozitív szándékkal, hogy ne álljon fel a rendszer.)

a csomaggyártók mentalitása. Gentoonál csak elvétve találkoztam olyan hozzáállással, amivel máshol sajnos igen gyakran, hogy például egy adott típusú szoftverből két fajtát nem lehet egy gépre telepíteni, az erről szóló hibajegyeket pedig nagyvonalúan bezárja a csomagkészítő, hogy érvénytelen. Tapasztalatom szerint a Gentoos közösség igen nyitott a javító szándékra és lelkesek, ha valaki segíteni akar a munkájukban -- Nekem nem az kell, hogy örüljön a segítő szándékomnak, hanem hogy kiszolgálja az igényeimet. Nem nagy segítség, ha a hibajegy nyitva marad, de az a válasz rá, hogy küldj patch-et.

A stabilitás egyik fő ismérve (és feltétele) a feature-ök és lehetséges konfigurációk határozott korlátozása.

Ellenben elég stabilak a cuccaik... Aki használni akarja az eszközt, az meg pont ezt értékeli, aki meg fejlesztői/teszt oprendszert szeretne, az meg a gentoo-t. Az persze jó kérdés, hogy mi keresnivalója van egy komplett toolchain-nek, forrásoknak, minden fic-facnak egy production gépen?

Mármint azon az egy szál gépen, ami arra lett szánva, hogy az xyz szolgáltatás fusson róla? Persze,a hol van plusz gép, van plusz üzemeltetői erőforrás egy build rendszer kialakítására, ott lehet jó is - de minek, ha nyerni annyit nem lehet vele, mint amennyibe a fenntartása kerül?

so -- shared object

Koszonom, javitva.

innentől értelmezhetetlen a QA a Gentoo-ra

Mivel rolling release disztro, egy kicsit maskepp van megoldva a "testing". Itt a csomagok uj verzioi ki vannak maszkolva, viszont rengetegen vannak, akik valamilyen okbol kifolyolag ezeket unmaskoljak. Ebbol kifolyolag a fobb kapcsolokat hasznalo bugok eleg gyorsan ki is szoktak derulni (meg az altalanos unmaskolas elott). Attol meg nem ved meg semmi, hogy elolvasd a changelogot, mert Debian/stb. eseten is vannak kellemetlen meglepetesek, ha valtozik valami. A Gentoonal legalabb szol erte a portage, hogy van news item, olvasd el legyszi.

Nekem nem az kell, hogy örüljön a segítő szándékomnak, hanem hogy kiszolgálja az igényeimet. Nem nagy segítség, ha a hibajegy nyitva marad, de az a válasz rá, hogy küldj patch-et.

Nekem a Debian nem szolgalta ki az igenyeimet. Amikor megprobaltam nekik patchet kuldeni, hogy a fobb daemonokbol (pl Apache) lehessen tobb instanceot inditani az init script hackelese nelkul, igen csak baratsagtalanul el lettem hajtva, eppen csak a b*meg hianyzott a mondat vegerol. Mas esetekben hasonlokat tapasztaltam. Ezzel szemben a Gentoonal sokkal inkabb orultek es konstruktivan alltak hozza valami bugreporthoz, javaslathoz vagy bekuldott patchhez.

Pont a napokban próbálgattam a Pemtoo-t. Teljesen elvesztem benne, de alapvetően tetszik. Pont amiatt nézegetek kifelé debiantól amit te is írtál, vannak olyan helyzetek amikor régebbi csomag kellene valamiből, emiatt nem merek frissíteni. Viszont ugyanúgy kell pár dologhoz újabb. Mostanában kényszermegoldásként belehányom valahova forrásból, de ez nem túl jó megoldás. Viszont semmit nem tudok Gentoo csomagkezeléséről, most ezen akadtem el. Azért adtál egy lökést :)
--
AGA@
Fork portal és az egyik logóm :)

(Majd ha nagy leszek, hozzászólok érdemben is, most csak megjegyzem magamnak :-) Bocs.)

Gentoo-t akkor erdemes valasztani, ha:
- Keves geped van, vagy
- Sok hozzaerto rendszergazdad van

Minden mas esetben kerulendo. Legalabb havi szinten frissen kell tartani, kernelre, GLSA-ra folyamatosan oda kell figyelni, stb...

Es meg akkor is meg kell fontolni. Egy appliance-szeru gepet nem erdemes Gentoo-val telepiteni (appliance-szeru: egy, max ket (web)alkalmazast futtat, kizarolag a frissites miatt kell ra bejelentkezni konzolbol). Oda egy SuSE vagy akar egy Ubuntu teljesen jo valasztas.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Es szalegyedul voltal rendszergazda az egesz cegben? Akkor grat.

En is uzemeltettem ~20 gepen Gentoo-t, es tudom ,hogy ha az embernek meg kismillio mas dolga is van, akkor nem fer bele a Gentoo torodesi ideje. Jo, nalam ez nehezitve volt annyival, hogy elegge... ehhhm... erdekesen voltak a gepek feltelepitve, raadasul nem tul gyakran voltak frissitve, de... szoval, necces volt.

Az biztos, hogy en olyna 4-5 gepig vallalom, akar sok melo mellett is, hogy uzemeltetek rajta Gentoot-t, ha hasonlo konfigu/architekturaju gepek, es van ertelmes binhost, akkor ez felmehet 8-10-ig is, de onnantol mar nehez a felelosseget vallalni - vagy a tobbi munka rovasara fog menni.

Nem is feltetlen az a baj a Gentoo-val, hogy rossz, mert nem rossz az, egyszeruen egy teljes nagysagrenddel tobb torodest igenyel, mint akarmelyik random disztro.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ha egy gép van, akkor nincs keresnivalója a toolcahin-nek/buildnek rajta: vagy bináris tárolóból "trükkösen(?)" telepíteni, vagy felejtős. Ha néhány, nem nagyon kihasznált gép van, akkor lehet jó is, ha viszont több, akkor fölösleges öntökönbökés az összes gépen forrásból buildelni mindent - goto bináris tároló: egy gép ezt csinálja, a többi innen szedi a frissítést.

A törődésigénye valóban egy nagyságrenddel nagyobb, ha kettes számrendszerben vagyunk :-)

Szerintem...

ParserException. Miert csak a Debian jon elo a Gentoo mellett? Pl. az OpenSUSE-nak nagyon jo hardened kepessegei vannak, SELinux, AppArmor es GrSecurity is elerheto hozza. A Mandriva minden nyugje ellenere elkezdte tamogatni az RSBAC-ot.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Hát, nem tudom. Az Adamantix projekt vége után elgondolkoztam a hardened gépek hardened gentoo-vá alakításán, de konkrétan feltelepíteni sem sikerült teljesen, összeakadtak a csomagok. És amikor megkérdeztem, hogy ezt így hogyan, akkor az volt a válasz, hogy ja, hát a hardened dolgot azt nem figyelik annyira, várjak, hátha megjavul.
Lehet, hogy azóta sokat fejlődött, végül is eltelt kb. 8 év.

Az automatizalas mindaddig mukodik, amig nem jon egy olyan, mint amit megjatszottak a PHP 5.3 kijovetelekor. Osszevissza voltak a SLOT-ok, elboktek az egeszet, es nehany gepnel nagyon bonyolult scenariok adodtak a frissitesre. Volt gep, amivel egy napot el kellett kinlodnom.

Az se tett jot, hogy a Ruby tamogatas is borzaszto lassan normalizalodott, most hogy flameeyes erdemben foglalkozik a temaval, most kezd olyan lenni a Gentoo, amire mar azt merem mondani, hogy igen, tamogatja tobb Ruby egymas melle tetelet. Mert nagyon sokszor keves az, hogy fel tudok rakni ket, masutt utkozo csomagot. Kell moge egy normalis tamogatas is.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Az 5.3-as PHP kijövetelekor konkrétan egyeztettem a PHP maintainerekkel. Sajnos azt a megoldást nem akarták támogatni, hogy a régi verziójú PHP is megmaradjon, mert az a felfogás, hogy a legfrissebb verzió legyen fent. Én azt szerettem volna elérni, hogy a PHP 5.2-es vonal maskolva maradjon támogatott, amibe nem mentek bele, így saját csomagot kellett neki készíteni.

Ami a Rubyt illeti... nos, azt inkább hagyjuk, még önmagukkal sem kompatibilisek, nem tudom zokon venni, ha a disztró maintainerek nem tudnak mit kezdeni a dependeny hellel.

Nem a dependency hellel volt a gond a rubynal, hanem a tobbi implementacio tamogatasaval (MRI, JRuby, REE).

Ami a PHP-t illeti, kezdjuk ott, hogy mar az elejen 5.0, 5.1 SLOT-okat kellett volna csinalni, _mar akkor_ amikor kiderult, hogy az 5.0 es az 5.1 nem felcserelheto egymassal (vannak inkompatibilitasok koztuk). Ezt aztan az 5.2-nel se sikerult meglepni, az 5.3-nal meg kialakult egy olyan kaosz, amit automata konfig menedzsmenttel egyszeruen nem lehetett ertelmesen lekezelni, csak ganyolva. Volt olyan 5.2-es PHP verzio, ami mas SLOT-ban volt, mint a kozvetlen (5.2 agi) frissitese... A php.ini mappajara meg konkretan szartak megoldani, legalabb agyonsymlinkelhettek volna, hogy frissites utan valami mukodo konfig alljon elo. De nem, amikor frissitett a rendszer, azt lehetett tudni, mert egybol leallt a webszolgaltatas a gepen. Ezt konkretan - egy klasszikust idezve - _elk*rtak_.
Az atallas ideje alatt zajlo osszevissza PECL modul tamogatasrol mar meg se kivanok emlekezni.

En ott vesztettem el a bizalmamat a Gentoos QA-ban. Inkabb ne legyen minden poccre hardened, de nem kivanok 1 nap/gep szopaspartikat rendezni csak azert, mert valami agyament fejleszto nem kepes _ertelmes_ tamogatast nyujtani a PHP-hoz. Foleg ugy, hogy emlekszem, az 5.2-nel bugreportban meg is nyammogtak, hogy miert nem lesz kulon 5.2 SLOT. Mar akkor! Es nem tiz gep tort el igy, sokkal-sokkal tobb. Volt ugyfel, aki konkretan szerzodest bontott emiatt.
Azt mar csak halkan jegyzem meg, hogy az egesz orulet alatt egy darab hir ki nem jott a portage faban (eselect news), hogy akkor most mi a pots van, es mit szeretnenek valojaban, hogy az ember esetleg, netalan-talan, fel tudna keszulni _elore_. Ez nem csak fejlesztesi, kommunikacios csod is volt.

Es ha ezt egy progival jatszak el a sci-* kategoriabol, mindenki boven letojta volna. De ez a PHP volt, amit _sokan_ hasznalnak, es _rendszeresen_ frissitik.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Errol sztem lehetne targyalni a PHP maintainerekkel, ki kellene talalni, hogy lesz jo.

Ami a QA-t illeti, pontosan ugyanaz van, mint barmelyik non-enterprise disztronal. A maintainer gondol valamit, megcsinalja es ugy lesz. Probalj meg egy Debianra a meglevo PureFTPd melle foltenni egy ProFTPd-t (mert mondjuk le akarod cserelni, de nem csapod folul csak ugy).