lehet, hogy rossz helyen keresed: http://hup.hu/szavazasok/20151213/hovd_2015_kedvenc_desktop_linux_disztro

Build rendszer, release process, mögöttes szervezeti hierachia (CentOS-nél pl. szerintem az összes SIG is játszik, amik nem feltétlenül vannak meg a RHEL-nél, AFAIK CentOS-ék már a Fedorával is egyre szorosabban együtt működnek a Fedora NEXT [leginkább server] miatt) stb.

Van értelme, egy disztró nem csak egy raklap binárisból áll...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Sosem használtam (telepítettem) még Zentyalt, lassan so:rt kell rá keríteni.
Viszont aki már foglalkozott ilyennel, azt mondta, hogy ugyanaz előállítható úgy is, hogy egy "sima" ubuntun apt-get install zentyal.
Nem tudom, így van-e tényleg; hiszek neki.

Azt viszont tudom, hogy debian alatt nincs apt-get install ubuntu... :D

Tehát, akkor a tuti Gentoo üzemeltetés, ahogy én látom:

1. Saját portage tree snapshot kell. Ha rsync a frissítés technológiája (én most ezt használom), akkor saját (napi) rsync frissítés valami környezetbe (nálam egy chrootban lakik), amiről aztán lehet csinálni snapshotokat, és azokról megy minden gép és minden fordítás. Ennek hiányában nem tudsz pl. kettő gépet csomagszinten azonos állapotban tartani. Elvileg a git használatával nem is kellenének snapshotok, hiszen azzal előre-hátra lehet menni az időben, de nálam most ez van összelőve.

2. Az a felállás, hogy egy éles gépen, az éles környezetben fordítgatja az ember azokat csomagokat, amiket rögtön oda fel is rak, az alapvetően nem működőképes. Nem lehet reprodukálni az eredményt, ha elbökődik valami, akkor lehet elővenni a mentést, meg hasonlók. Emiatt külön fordítási környezet kell, vagy chrootban (én ezt használom, mert kényelmesebb), vagy virtuális gépben, ahol bináris formában előállnak a csomagok, amit aztán lehet a célkörnyezetekbe felrakni. Innentől adódik, hogy a frissítés úgy néz ki, hogy a napi frissítésű portage tree-ből csinál az ember egy snapshotot, a fordítási környezetből csinál egy másolatot, abban frissít a portage tree snapshotra, majd frissíti a szimpatikus csomagokat. Ha elbaszódik valami, akkor lehet javítani vagy újrapróbálkozni, a problémák döntő többsége még fordításkor kijön.

3. Optimális esetben van valami tesztkörnyezete az embernek, ha más nem, hát egy virtuális gép megfelelhet erre, de egy kevésbé kritikus gép is jó lehet. Először ide rakja fel az ember a frissített csomagokat (az ugye már a fordítási környezetben kiderült, hogy egyáltan lefordul minden), és nyilván valami alapszintű tesztelést azért gyorsan le lehet nyomni.

4. Frissítési taktika: nálam az vált be, hogy időnként (jellemzően valami alapvető package - pl. glibc/gcc - változása után, ~fél évente) nyomok nulláról egy full újrafordítást, közötte meg snapshot + frissítgetek, ahogy nekem szimpatikus. Mivel a frissítés után nem nulla energiát igényel a deployment, hiszen az adott komponenst használó dolgokat minimum ki is kell próbálni, így nyilván a rászánható időtől függ, hogy mikor mit frissítek. Jellemzően aminek tud security vonzata lenni, vagy ismerten van is neki, az frissül, egyébként meg nem nagyon. Nálam nincs GLSA-alapú automatizálás, már csak azért sem, mert minden frissítéshez snapshot tartozik. Van viszont script, ami napi jelleggel kiszedegeti az általam megjelölt fontosabb csomagok állapotát a használt architektúrákban, és az utolsó frissítésemhez képest tud mondani diffet.
Amivel szopás van:
gcc-csere: újabb gcc-vel fordított C++ programhoz kell az újabb gcc C++ libje, ergó nem tudsz binárisban felrakni új dolgot, ha nincs elég friss gcc a gépeden, itt legalább annyira nem szar a helyzet, mert lehet fent több gcc verzió, és lehet a régi a default
glibc-csere: ez a nettó, tömény szopás; két glibc verzió nem tud fönt lenni, az újabb glibc-hez linkelt programok by default nem mennek a régebbivel, emiatt a downgrade is elég necces tud lenni
Ha eltérő feature set-ek kellenek (pl. egymásnak ellentmondó USE-flagek, egymást kizáró csomagok, más CFLAGS, stb), akkor annyi példányban kell fordítási környezetet fenntartani, ez azért egy ponton túl már sok macera tud lenni; én most egyetlen halmaznyi csomagot, USE-flageket, és egy CFLAGS beállítást használok csak. Az is macera, hogy az eltérő architektúrákra nem pont ugyanazok a csomagok és nem egyforma státusszal állnak rendelkezésre.

Nem alkalmas mindenre, minden esetben. Ezzel együtt fenntartom, hogy igenis lehetséges ésszel kialakítani és üzemeltetni, még biztonságosan is, ha ismered és fektetsz bele energiát - ez utóbbi elkerülhetetlen. Garanciát nyilván akkor sem fogsz kapni, de foglalkoznak cégek a támogatásával egyébként, ha nem is sokan. Nem állítom, hogy kész nagyvállalati felhasználásra, én sem ott használom. Az időigényét illetően: nem feltétlenül szerencsés választás oda, ahol azonnal kell csomagokat telepíteni és használatba venni - ahhoz nagyon komoly hardware és biztos tudás kell. Nálam az a megközelítés nyert, hogy fél évente frissítek @world-öt, ami napokig tart ilyen alkalmakkor a csomagonkénti USE flag-ek használatából adódóan - ilyenkor cserélem le az aktuális legfrissebbre először a csomagkezelőt, utána a fordító toolchain-t, majd minden mást, végül a kernelt is. Ezen frissítések között viszont csak GLSA-kkal foglalkozom, azokkal viszont automatizáltan és minden nap. (A rendszerről inkrementális napi mentéssel rendelkezem, továbbá az üzemképessége szempontjából kritikus csomagokról a kézi frissítésük előtt a működő állapotúból külön bináris helyi másolatot teszek félre, így technikailag minden változtatásom rollback-elhető valamilyen módon.)
------------------------
{0} ok boto
boto ?

Ez azért van, mert az APT egy DPKG frontend. Az RPM-et a DPKG-val, az APT-t a Yummal kell összehasonlítani.
Mindkét esetben más az, hogy mi a frontend, és mi a mögöttes package kezelő. Az interaktivitást az APT teszi lehetővé, nem a dpkg, IMHO.

Ami miatt lehet külön szívni a letiltásával, ha automatizáltan akarsz valamit csinálni :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)