HOVD 2015 - Kedvenc szerver Linux disztró

HUP

arch
4% (41 szavazat)
centos, scientific linux
14% (125 szavazat)
debian
41% (379 szavazat)
gentoo
4% (34 szavazat)
mandriva, mageia
1% (6 szavazat)
oracle linux
0% (3 szavazat)
rhel
4% (40 szavazat)
slackware
1% (10 szavazat)
sles
3% (27 szavazat)
ubuntu
28% (260 szavazat)
Összes szavazat: 925

( vavhab v | 2015. 12. 14., h – 16:34 )

RHEL es OEL miert van kulon? Vagy egyaltalan ezek miert vannak kulon a Centos-tol es a scientifictol? Mi a logika mogotte?

Mert ezek tok mas disztrok (mas support, mas csomagkeszlet), es mert ha osszevonnank oket, nem lenne eleg _szerver_ disztro, hogy meglegyen a 10 jelolt es ertelmes mennyisegu szavazat jojjon rajuk (hibahatar alattiak azok, akik desktop rendszert hasznalnak szerverkent).

Kicsit olyan kerdes ez, mintha azt kerdezned, miert nem vonjuk ossze a Debiant meg az Ubuntut.
--
Blog | @hron84
Üzemeltető macik

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)

Ilyen alapon a kérdés is értelmetlen, annyinak kellett volna lennie, hogy "Kedvenc szerver Linux disztró"? "rpm"/"deb"/"egyéb", mert lényegében csak a verziószámokban és egy-két apróságban térnek el, többnyire mind ugyanazokat a szoftvereket szállítja. Vagy nem?

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

Ebben egyetertunk.
Amikor tolem azt kerdezik hogy mi a kedvenc disztrom akkor azt gondolom a kerdezo arra kivancsi hogy melyiket szeretem leginkabb hasznalni. Ami nyilvan attol fugg mennyit hasznaltam azelott/mennyire ismeros szamomra a kornyezet, nalam a kedvenc egyertelmuen a RHEL/OEL/Centos 5.x-6.x mert azokat gyakrabban hasznalom mint a 7.x-et. A 7.x egyelore nem a kedvencem mert egyelore tul sok az ismeretlen faktor benne. Ilyen szempontbol szamomra teljesen mind1 hogy RHEL/OEL/Centos ha nem nezem meg release-note-t azt sem tudom mire loginoltam be.

Hiába smileyzol, ez az egyik legfontosabb kérdés disztó kapcsán. Milyen gyakran van új, meddig támogatott a régi, updatenál új verziók jönnek, vagy hajlandók patchelgetni a régebbit, beleszarnak-e abba, hogy update után kézimunkázni kell valamin, vagy nem.

És nem szerver vonalon, nézd meg itt a random topicokat. Az arch meg gentoos srácok azt szeretik, hogy mindig ott a bleeding edge verzió a foobar csomagból (cserébe updatelnek is folyamatosan, mert ha fél évig nem, akkor hosszas csiszolgatás fog jönni), de ubuntuból is nem véletlen van, aki a normál verziókat hajtja félévente, mások inkább az LTSt. Meg mennek a komoly hitviták :)
És akkor itt arról beszélünk általában, hogy ki mit használ a desktopján magának. Szerinted mikor valamiből sokat kell üzemeltetni, kiszámíthatóan, nem szopva állandóan extra körökkel, akkor ez nem még fontosabb kérdés? És nem lehet, hogy aki sok ilyet csinál, annak fontos szempont a kedvencségben, hogy hányszor (nem) szopatja le ilyenek miatt egy disztró?

Szerintem az hogy kinek mi a legfontosabb az erosen szubjektiv. A legfontosabb erosen egyen es felhasznalasfuggo.
Na mind1, reszemrol lezarom ezt a topikot, valoszinuleg nekem mast jelent a kerdes mint a tobbsegnek. ;)
Jovore inditvanyozni fogom a szofisztikaltabb kerdes feltevest. pl:
Kedvenc szerver linux disztro support tekinteteben?
Kedvenc szerver linux disztro Life Cycle tekinteteben?
stb. :)

Mondom egyik legfontosabb :)

(És éppen ezért van többek között értelme szétszedni brandek szerint. Pl lehet, hogy valakinek azért mégis a centos, mert az nem fizetős, más az RHEL-t imádja, mert az RH jócég(tm), az oraclet meg utálja, mert azok köcsögök, lopnak az RHtól, nem értik az opensource-t, és a sunt is szétbaszták, vagy egyéb más nem szigorúan technikai szempont)

Reszben igen, elbagatellizaltad a kerdes komplexitasat, reszben pedig meg ket CentOS alapu dSzerisztronak se ugyanaz a csomagkeszlete, es azert baromira nem mindegy, hogy ha kell egy foobar csomag, akkor azt kulso tarolokbol kell elobanyaszgatni, kerdeses minosegben, vagy a disztro maga hozza. Es akkor meg csak a csomagkeszletrol beszeltunk, nem pedig a meglevo csomagok stabilitasarol, jol teszteltsegerol, frissessegerol, feature-teljessegerol.

Szerintem a preferenciak tekinteteben nem a csomagformatum es nem a default csomagkezelo dont a tobbsegnel, hanem az ilyen reszletek, amik miatt kulonboznek az egyes disztrok egymastol. Lehet, hogy szamodra nincs kulonbseg egy CentOS meeg egy Fedora kozott, de ez jo esellyel azert van igy, mert nem uzemeltettel meg huzamosabb ideig kulonbozo rendszereket, van 1-2-3 eltero geped az alapvetoen homogen halozatba, es a kulonbozokhoz eleve nem kell nagyon hozzanyulni.
--
Blog | @hron84
Üzemeltető macik

Ha figyelmesen elolvasod amit irtam feltunhet hogy a Fedorat egyszer sem emlitettem. Azt sem emlitettem hogy a csomagkezelo miat preferalok valamit, lehet mas forumot olvasunk? Mit ertunk az alatt hogy huzamosabb ideig uzemeltet valaki valamit? Jo 15 eve a szakmaban vagyok, az mar huzamosabb ido? ;)
A jelenlegi munkaltatomnal valoban meglehetosen homogen a halozat, van "1-2-3 eltero gep"(~2500 OEL, ~300 RHEL), pont ezert nem ertem mi a kulonbseg a RHEL es a OEL kozott uzemeltetes szempontjabol. Supportot most ne vegyuk bele mert az eg es fold.

Uzemeletetes szempontjabol talan az RHEL es az OEL kozott nincs kulonbseg (bar egeszen biztos vagyok benne, hogy vannak olyan csomagok, amik csak az egyikre erhetoek el, vagy az Oracle RDBMS-t kevesebb szopas uzemeltetni az egyiken mint a masikon), azonban az (RH|O)EL es a CentOS kozott igenis van kulonbseg, arban, funkcionalitasban, stb.

Es csak hogy keep in your mind, mirol beszelunk, ez volt a kiindulasi alap:

Tok mas distrok? Ez nekem uj. Azon kivul hogy mas a support mogottuk miben masak? Az /etc/(redhat|oracle|centos)-release fajlon kivul? Meg az uek kernelen kivul. ;)

En erre - tobbek kozott - az eltero csomagkeszletet mondtam, amit sikerult csendben ignoralni. Elegge el nem itelheto modon ugyanis a harom emlitett disztro sem verzioszamban nem ugyanazokat a csomagokat hozza, sem pedig a bennuk megtalalhato lista nem ugyanaz, sot, meg a licenceles altal engedett dolgok sem egyeznek (a CentOS-ben nincs pl. up2date, az RHEL-re a licenc nem engedi meg a kulso csomagtarolok felvetelet, stb-stb)

Szoval igen, van kulonbseg koztuk, az, hogy neked mindegyik RH alapu disztro, az kb. olyan, minthogyha az lenne a kerdes, hogy miert szavazunk kulon Linux disztrokra, hat mindegyikben Linux van, nem? Nem. Meg a CentOS es az RHEL kozott is zongorazhato a kulonbseg, egy CentOS meg egy ClearOS kozott pedig nagyon sok difi van.

Nem tudom, hol kellene meghuzni a hatart, amig ket disztrot ugyanolyannak tekintunk, en ott huzom meg, hogy ha mas a neve es/vagy mas csomagok vannak benne (tobb v kevesebb, regebbi v ujabb, ez most lenyegtelen) akkor masik disztro. Es azt gondolom, hogy az oldalon levok tobbsege igy van vele.

Szavazni pedig mindenki a kedvenc disztrojara fog, es nem a kedvenc disztrocsaladjara, jelentsen ez barmit is.
--
Blog | @hron84
Üzemeltető macik

baromira nem mindegy, hogy ha kell egy foobar csomag, akkor azt kulso tarolokbol kell elobanyaszgatni, kerdeses minosegben, vagy a disztro maga hozza.

Egyébként tud valaki bizonyítékot arra vonatkozóan, hogy a debian/ubuntu disztró által szállított de centos/rhel által nem szállított ugyanakkor epel/repoforge-ban (külső kétes minőségű tároló) megtalálható csomagok döntő többségénél a debian/ubuntu csomagjai jobb minőségűek?

repoforgeot pont nem használtam, de azért arra rá lehet futni, hogy random külső repó részben akad a base-el, vagy az epellel, vagy egymással, vagy ilyesmi. Ebből a szempontból imho azért jobb a deb/ubuntu nagy közös kupac cucca, dependency hell legalább repok között nincs :)

még a csomagéra sem feltétlen, volt bőven szar a deb csomagjaiban is.
Bár az igaz, hogy legalább az megvan, hogy kb ugyanaz a QA minimum megvan minden csomagra, mí egy random tárolónál passz (Bár a normálisabbak azért általában normális QAval szoktak menni, random és random között is van különbség...)

"Bár az igaz, hogy legalább az megvan, hogy kb ugyanaz a QA minimum megvan minden csomagra"

Pontosan ezt ertettem alatta. En mar szivtam random tarolonal azzal, hogy olyan runtime fuggosege volt a cuccnak, ami sosem letezett (vagy azert, mert az SRCRPM-ben el volt irva a nev, vagy mert volt valami unreleased csomagja a keszitonek, es a cucc arra fuggott).
--
Blog | @hron84
Üzemeltető macik

( uid_20470 | 2015. 12. 16., sze – 09:31 )

debian, de csak mert abba kerultem bele melohelyen, igy sajat szerverekre is azzal fozok amit ismerek :)

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

Apt-gettel is lehet telepíteni a zentyalos komponenseket, de attól még az Ubuntuból nem lesz Zentyal. A Zentyalnak saját csapata van, a Canonical helyett másik cég áll mögötte, lehet rá külön supportot venni, és mintha a csomagtárolók is sajátok lennének. Persze, nincs szabványos követelményrendszer arra, hogy mi számít külön disztrónak, de imho erre mondhatjuk, hogy nem egy stock Ubuntu.

Igen, ezért kezdtem a kommentet úgy, hogy "Apt-gettel is lehet telepíteni a zentyalos komponenseket, de..." ;)

Mit érteszt zentyal csinálás alatt? Ha megveszed a supportot a Zentyal S.L.-től, de nem az ő image-üket telepíted, hanem egy random Ubuntut okosítasz fel, mi történik?

( uid_4263 v | 2015. 12. 16., sze – 17:24 )

Azert a gentoo eleg eros szerver distronak. Aminek minden nap valtozik a leszallitott ficsorsetje, az nem szerver distro szerintem. Epiteni legalabbis nem lehet ra evekre. Maximum a pinceben vagy a virtualis CS szerveren. Ujrahuzod, ha kell, es max par napig nem lesz szervered vagy NAS-od.

--
arch,debian,openelec,android

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.

Szóval jól lehet a gentoot élesben használni, ha házon belül megcsinálod kb azokat a dolgokat, amiket egy bináris disztrónál megcsinál a disztribútor :D

(Elvéve a dolog élét, igen, el tudom képzelni, hogy ennek így vannak előnyei, ahol akár ezt a befektetett melót is megéri, és egyszerűbb megcsinálni mint ha egy alapvetően bin terjesztésre hegyezett disztóból akarná az ember ugyanezt kifaragni...)

Oke, leforditom mindezt emberi nyelvre: a tuti Gentoo uzemeltetes ugy nez ki, hogy te magadnak megcsinalod azt a Q/A munkat, amit a normalis disztrok tobbsegenel megcsinalnak neked. Ez baromira nem megeros, nagyon megnoveli az egesz cuccnak a management idejet es a TCO-jat, es a Gentoo-t egy altalanos oprendszerbol specialis celplatformma degradalja. Ez eleg sok szempontbol rossz, raadasul ez az egesz egy bizonyos gepszam folott nem mukodokepes, egy bizonyos gepszam alatt pedig nem eri meg a teszt rendszert uzemeltetni.

Raadasul ez a rendszer (a 4-es pont alatti okok miatt) csak teljesen homogen rendszereket, vagy csak adott szintu inhomogenitast tud elviselni, tobb kulonbozo kornyezethez megint csak tul magas a TCO. Persze, ez joreszt az USE flagesdi hatulutoje, legtobbszor ezert szoktak minden lehetseges flaget beallitani az adott csomaghoz, igy lehet, hogy nagyobb lesz, tobb fuggoseggel, de legalabb biztosan szol tobb kornyezetben is.

Raadasul az a folyamat, amit itt leirtal, az kb. megegyezik azzal, ahogy a binaris disztrok mukodnek - mindenfele szopasfaktor nelkul. Na nekem ezert bukott el a Gentoo, mert ennyi szopkodasra nekem nem biztositottak eleg idot. C'est la vie.
--
Blog | @hron84
Üzemeltető macik

HŰűűű. A gondolataim:
- értesz a gentoo -hoz és rengeteg munkával lehet vele eredményt elérni, de ha téged lecserélnek, a következő ember csak pislogni fog mint 60W-os Neon a Vektorban
- egy része azért holisztika: "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," Mi az hogy időnként?? :)

--
arch,debian,openelec,android

Hadd szoljak mar en is bele. Uzemeltettem Gentoo alapu szervereket, testkozeli az elmeny: gyakorlatilag az onszivatas es a garancianelkuliseg az a ket szo, ami elsore eszembe jut errol az idoszakrol. Nem is feltetlen azzal van a bajom, hogy mozgo celpont, valtozik a feature-set, hanem hogy nincs egy teszt resze a dolognak, majndem minden az eles portage fan zajlik. Ez alapvetoen akkor nem gond, ha lenyegi, strukturalis reszei nem valtoznak, viszont ha igen, akkor minden szervert kepesek belengetni. Ilyen volt a PHP 5.0-5.1-es fiasko, amikor lehoztak sima update-ben az 5.1-et az eles fan fuggetlenul attol, hogy egyebkent API szinten inkompatibilis volt a ketto. De volt ilyen kismillio hasonlo esetben is, a GNOME/KDE kornyezetek is nem egyszer tortek a problemas relase-k miatt, eleg gyakoriak az utolagos kimaszkolasok is. A QA sokat fejlodott az utobbi idokben, igy legalabb mar eltoro build folyamatok nincsneek igazan, de messze meg egy Ubuntu-szintu stabilitas es megbizhatosag. A ~arch alapu modell sajnos eleg buko egy olyan disztro eseteben, amit eleve marginalis mennyisegu ember hasznal, nincsenek igazan kitesztelve a csomagok, es mivel nincs mogotte ceg, penz sincs arra, hogy foallasu teszterek tesztelgessek tobb gepen, tobbfele kombinacioban a csomagokat.

Pont nemregiben (feleve? egy?) probalkoztam a Gentoo-val desktopra es szerverre is, hogy felelevenitsem az emlekeimet, es mindaddig nagyon szepen ment, amig egy nagyobb update alkalmaval elkezdett nem elindulni a LightDM, mindenfele hibauzenet nelkul. Sajnos nekem meg kozben elkezdett nem lenni idom arra, hogy ilyen alapszintu renszerkomponenseket hibakeressek egy alapvetoen munkara szant gepen, igy ment vissza egy binaris disztro, ahol ugyanaz a LightDM verzio uzemkepesnek bizonyult. Es a Gentoo-rol tudom, hogy ezt kepesek Apache-csal, MySQL-lel vagy barmi egyebbel is eljatszani, nem kell ehhez X.
--
Blog | @hron84
Üzemeltető macik

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 ?

"azonnal kell csomagokat telepíteni és használatba venni"

Nekem ez foleg olyankor borul, amikor valamiert uj USE flaget pakolnak a glibc csomagra, ami onmagaban, ccache-csel kepes negyed orat elmolyolni (-DuNa world, ugye). Meg egy Apache forditast csak-csak vegigulok, de egy glibc-re nem fogsz ravenni.

"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."

Na ennek kellene az alapertelmezett mukodesnek lennie, vagy valamilyen snapshot-rendszernek, hogy vissza lehessen vonni a felresikerult modositasokat, csak ehhez a Gentoo-nak elobb el kellene ismernie, hogy ok is emberbol vannak, es kepesek elbokni a frissitest. Amig ez nem tortenik meg, nem igazan lesz megbizhato a rendszer, csak rengeteg munkaval.
--
Blog | @hron84
Üzemeltető macik

Ezt mondom: vannak esetek, amikor nem megengedhető az, hogy várni kelljen egy-egy csomagra. (Egyébként binhost használata megoldja ezt is, ha adott egy homogén környezet. Nem _kell_ helyben fordítani mindent/semmit, még Gentooval sem - OOTB tudja a bináris csomagkezelést _is_.) Egyébként azt hiszem, hogy egészen egyszerűen felszólítható a portage arra, hogy _minden_ esetben elkészítse és letárolja a bináris csomagokat. Ezzel a lehetőséggel én nem szoktam élni. (Nyilván nem a binhost-ról beszélek.)
------------------------
{0} ok boto
boto ?

( BlackCode | 2015. 12. 18., p – 10:57 )

Arch, mint produktív szerver - LOL :D

( nagyorgy v | 2016. 01. 07., cs – 20:01 )

BlackPantherOS, UHU linux miért maradt le a listáról?

( RGeri | 2016. 01. 08., p – 10:18 )

Hogy megkavarjam az állóvizet, Fedora Server.

--
RGeri77
Fedora Ambassador, játékmester ;-)

Ezer éve nem csináltam ilyet, de a mindenféle selectes cuccok imho bizony a dpkg részei (dpkg-reconfigure van pl, nem apt-reconfigure), és egyébként logikusan oda is tartozik, mert az interaktivitásnak nyilván a csomag basztatásakor jelenteni kell valamit.

De egyébként kb mindegy, több okból is. Egyrészt a yum se tud ilyet (meg ha jól emlékszem a suse mittomén mije -- zypper talán -- seÖ, másrészt szerintem ma már túl sok teteje általában nincs elválasztani ezeket egymástól, átlagban esetben annyira össze van nőve a működésük (fene se rpmezik / dpkgzik kézzel manapság átl). Persze, van amikor érdekes.

igazából maga a debconf létezése a lényeg, meg hogy befolyásolni lehet a csomag telepítését viszonylag szabványosan (nem az van, hogy maximum patkolsz magadnak valami pre vagy post scriptet, mert az rpmnél kb eddig van) imho tényleg eléggé részletkérdés, hogy most pontosan mi csinálja.

Nyilván izlések és pofonok, én azért amondó vagyok, hogy jobb az, ha azzal kell szívni, hogy lekapcsoljak valamit (főleg, hogy azért a deb is tudja, hogy egy valid usecase, hogy automatán települjön valami, kb egy kapcsoló beállítása a szívás), mint azzal, hogy kénytelen legyek implementálni valamit, ami nincs :) Ez spec nekem nagyon furcsa volt mikor a debes háttér után elkezdtem rpm alapú cuccokat nyomkodni többet.

(és igen, cserébe vannak az rpm alapoknak is tök jó dolgai, amire meg úgy néztem, hogy ez mi a francér nincs a debes infrán megcsinálva)

Még csak kapcsoló sem kell, elég hozzá egy környezeti változó, de akkor is "imádom", hogy foglalkozni kell vele :) A másik meg, hogy utána úgyis valszeg konfigolni kell még tovább is, és akkor már inkább ne csináljon semmit vagy dobja be az alap (szoftver által szállított) konfigot -- többnyire úgy se lesz jó egyik se.

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

Az "imádom" szálat nem ragoznám tovább, izlések, pofonok, kedvencek :)
--
A másikra viszont nekem erősen azok az emlékeim, miszerint meglepően sokszor bőven elegek voltak, és még ha hozzá is kell nyúlni, kevesebbet.

Illetve ami még az automatizáláshoz hozzá tartozik, hogy imho ott pont hasznos is tud lenni, hogy van egy szabványos paraméterezési felület, amit tudsz használni (akár a saját csomagjaidnál is), nem kell bonyi köröket futni a provisioning toolban.

Egyébként meg arról továbbra sem fogsz tudni meggyőzni, hogy az rpm azért jobb, mert hiányzik belőle valami :) Márpedig az a kanyar kb onnan indult, hogy az rpm azért jó, mert van benne x y z feature, ami másol nincs.

Akkor amit eredetileg egy "Szerk"-be akartam írni, de úgy voltam vele, hogy nincs kedvem :):

Szerintem az ideális csomagkezelő csomagjai SEMMILYEN imperatív dolgot nem szabadna, hogy tartalmazzanak, teljesen leírónak kellene lenniük (és nem annyira overengineerednek, mint amilyen az msi :) ). Innentől kezdve (feltéve persze, hogy minden leírható állapotváltásnak van inverze) megkaptad "ingyen" a tranzakció-támogatást, garantáltan nincs interakció [ahol kevésbé az automatikus konfigolás, mint inkább a félbehagyott futtatás zavar]. Hogy aztán parametrikussá akarod-e tenni a tisztán leírót, hogy a telepítő tudjon az alapján döntést hozni (létre hoz-e konfig fájlt, át ír-e benne dolgokat stb.), az már más kérdés.
Egyébként Red Haték/Poettering is erre akarnak elmenni a tavalyi "állapottalan rendszerek" és új deployment megoldások ötletbörze-blogbejegyzése alapján, pl. olyanokkal, hogy egy demonra bízná a rendszer userek létrehozását, hogy ne kelljen uid-eket fenntartani, ne a telepítőcsomag dolga legyen [az csak leíró jelleggel dobjon be egy file-t egy könyvtárba].

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

Mondjuk múltkor megszívatott a yum tranzakció kezelése, pedig pont azt kellett volna csinálnia, amire tervezték. Megszakadt egy ssh session-ön kiadott update. yum-complete-transaction errort dobott, yum-complete-transaction --cleanup-only ugyan lefutott, de utána nem lehetett undo/redozni az utolsó tranzakciót. Persze miután elolvastam a hibaüzenetet nem volt nehéz javítani (két csomagról azt hitte fenn van az update előtti és utáni verzió is, így szépen összeakadtak a dependencyk), de nem pont ettől kellene megóvnia a tranzakció kezelésnek?

:) Jól hangzik, de az igazság az, hogy azok az imperatív dolgok valahova kellenek. Elég tipikus, hogy a programozó tolja, hogy KISS, csak valamiért a világ nem akar simple lenni, azt lehet toldozni.

Az, hogy hol van az imperatív dolog, az egy másik kérdés, nyilván lehet nagyon szép architektúrát kitalálni rá, ellenben most az van, hogy a debianhoz van valami a csomagban -- ami szerintem az évek tapasztalata alapján nem is rossz -- az rpmben meg ha ilyet akarsz, akkor IJ. Tudom, rosszul fogom :)