I <3 CentOS

CentOS-t (is) hasznalunk, mert... mert az entersprise. Vagy mi. 6.5, minden frissitve. Bar amugy nem ertem, hogy miert enterprise egy olyan OS, ahol ha veletlenul rossz napon (i.e. uj release utan) adsz ki yum update-et (ami alapesetben ugye frissiti a csomagokat), akkor az update-bol dist-upgrade lesz. Na nem baj, lenduljunk tul ezen.

Probalnek curl-lel levelet kuldeni, korabban Ubuntu-n hasznalt script-bol:

curl: option --ssl-reqd: is unknown

Wat?

curl --version
curl 7.19.7

Hmm, ez me'g csak 4.2 eves csomag, akkor az me'g 5 sincs! Oke, toroljuk a flag-et, mashogy is meg lehet adni.

curl: option --mail-from: is unknown

Anyad. Oke, szedjunk curl csomagot a hivatalos oldalrol. Nagyon jo lesz, hogy az EPEL-en kivul meg mashonnan is csomagolunk, de nem baj, lenyeljuk a bekat.

curl: (2) Failed Initialization

? biztos. Ebbol a rendkivul beszedes uzenetbol vegul is annyi a lenyeg, hogy a libcurl-t is frissiteni kene, amire nagyjabol az OS fele depend-el, de bevallaljuk, kemenyek vagyunk.

Error: Package: libcurl-7.35.0-1.0.cf.rhel6.x86_64 (/libcurl-7.35.0-1.0.cf.rhel6.x86_64)
Requires: libssh2(x86-64) >= 1.4.3
Installed: libssh2-1.4.2-1.el6.x86_64 (@anaconda-CentOS-201303020151.x86_64/6.4)
libssh2(x86-64) = 1.4.2-1.el6

Koszikoszi. A dependency hell tenyleg megoldott problema igy 2014-ben. Meg kocsog szoftvercegek, akik nem szopnak a Linuxra fejlesztessel. Pedig milyen jo moka is az, ahogy az egy ilyen minimal command-line program peldajan keresztul is egyertelmuen latszik.

u.i.: az sj szintu hulyegyerekek megkimelhetik magukat es engem a "heti bviktor nyavogas" lemeztol, vegyetek ugy, hogy megmondtatok, ha ettol boldogabbak vagytok :)

u.i.2.: szinten az sj szintu, fogyatekkal elok kedveert elmeselem, hogy egy munkahely ugy nez ki, hogy nekem van egy elkepzelesem, amit a fonokom vagy elfogad, vagy mond helyette mast, ez a megoldas arra a hatalmas rejtelyre, hogy miert hasznalunk CentOS-t

( kroozo v | 2014. 01. 31., p – 14:13 )

Mármint hogy nem érted, hogy mi az az enterprise, csodálkozol, hogy nem megy a bleeding-edgeish cucc, összabaszol valamit valami ostoba repóbol, és a centos a hibás? :)

Nem. Csak nem érted. A benne levő csomag régi. Te meg az újnak egy featurejét szeretted volna. Ez az, ami bleeding edgeish. Kiemelném az isht, ami épp azért volt ott, hogy jelezze, relatív frisset jelent.

Aztán: "anyad. Oke, szedjunk curl csomagot a hivatalos oldalrol. Nagyon jo lesz, hogy az EPEL-en kivul meg mashonnan is csomagolunk, de nem baj, lenyeljuk a bekat."

Mármint hogy az epelen (ami már eleve csak hivataloska) meg a rendes centos repon kivül valahonnan máshonnan találtál még valamit, ahonnan yum installni lehet, és szerinted hivatalos, akkor tényleg ugorjál.
--
És nem attól lesz enterspájz, az csak az egyik következmény.

De, de, ertem, hogy nagyon szeretned ruzsozni a disznot, de az meg mindig ocsmany, es az is marad. Uj = 4 eves? 1 honapja kiadott release-ben? Ez nalam se nem "bleeding-edge", se nem "bleeding-edgeish", hanem kurvaregi. Ha nalatok 4 eves az uj, akkor mi szamit elavultnak? A 20 eves? Tok jo lehet, hogy soha semmit nem kell frissitenetek :-)

Aruld mar el, hogy honnan az anyambol kene frissitenem egy csomagot, ha nincs benne a taroloban? Es hogy mi akkora rohadt nagy szentsegtores a hivatalos oldal csomagjaban? Vagy erre tenyleg ennyit tudsz mondani, hogy "rabasztal"? Egyaltalan miert fugg az OS-tol egy userspace command-line csomag verzioja? Itt kezdodnek az alapveto problemak a Linux-szal.

honnan az anyambol kene frissitenem egy csomagot, ha nincs benne a taroloban

orizzuk meg ezt a hupmeme szamara :-)

Itt kezdodnek az alapveto problemak a Linux-szal.

kerlek, ne hagyd abba...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

bleeding-edgish:
Még mindig nem a 4 éves csomag a friss, hanem amit te használni akartál. Igen, értem, hogy szerettél volna egy friss csomagot, arra mondtam, hogy bleeding-edgeish. Értem a usecasedet, de továbbra is rossz célpontra fújsz.
---
Hivatalos oldal:
A CentOS diszró hivatalos oldala a mirrors.centos.org valamelyik repóján levő csomagok. Itt azok laknak, amit a CentOS a redhat tárolóiból fordít újra, lehetőség szerint ugyanolyanra, mint ők. Az EPELben olyan dolgok vannak, amiket a RH nem szállít, de hasznosnak vélik (és hasonló elvek mentén próbálják updatelni, mint az RH a saját dolgait). A curl oldalán meg valami van, amit a curl fejlesztője odabaszott, mint upstream. Ha kitett egy rpmet, vagy pláne egy szerinte CentOShoz való repót, ami aztán nem települ, vagy ki akarja cserélni a fél rendszert, az mindenképp kellemetlen, azonban semmi köze ahhoz, hogy a centos milyen. Ahhoz van köze, hogy vagy a curl írója egy béna tök, aki nem tudta rendesen becsomagolni a vackát, és állítja, hogy igen, vagy neked nem sikerült használni, amit adott. De mint mondtam, ez max a curl upstreamet minősíti, nem a centost.
---
Miért függ a csomag az OStől:
Azért függ, mert nem OS, hanem disztró. Tudod, szoftverek gyüjteménye. Ezeket mindenféle permisszákkal állítják össze. A RH (és ezért a CentOS) esetében prioritást élveznek mindenféle más dolgok az egyes csomagok frissessége fölött. Ilyen supportability, stabil interfacek updatek között, amik nem törik keresztbe a működő rendszereidet, jól tesztelt, működő, security updatelt csomagok, és hasonlók. És bár mondjuk egy újabb akármi hiánya a disztó által közvetlenül szállított cuccok között tud fájó lenni, egy csomó esetben nem éri meg, hogy a többit beáldozzuk miatta. Ezért van úgy, hogy régebbivel kell dolgozni. Ilyenkor, mikor a hatos a kiadási ciklus vége fele jár (a 7 már publikus béta) ez bizony tud ilyen látványos lenni.
A csomó eset többnyire enterspájz felhasználást fed le (ott fontosak ezek a célok, ami nem meglepő, tekintve, hogy az a RH célpiaca), és ott ha kell tudunk vele együtt élni. (Ha szükség van rá, akkor miután anyáztam egyet, nagy duzzogva le tudom fordítani és csomagolni a curlt úgy, hogy ne fájjon a rendszer többi komponensének, majd bele tudom lökni a helyileg erre tartott repoba, hogy elérhető legyen. El fog venni némi időt, de azért nem vészes).

Ha neked kell az, hogy rendszeresen tudj friss dolgokat feltenni, akkor egy ilyen szemlélettel csomagolt disztró nem jó választás. Lehet miatta szidni, hogy nem segít téged olyasmiben, amiben kimondottan nem célja neki, csak nem állít ki rólad valami jó bizonyítványt.

Tessék lőni valami olyasmire, aminek célja, hogy csomagolva viszonylag friss dolgokat adjon neked (ubuntu fél éves releasek, debian testing, fedora, zsuzsi), némiképp a többi izé kárára, esetleg egy oyat, ami nagyon frisset ad neked (arch, gentoo), erősen a többi izé kárára. Aztán majd ott meg sírj, hogy ez mekkora fos, mert nyomtam egy updatet, azt a fele daemon elmúlt működni a másikfelének meg elkúrta a konfigját.

Mármint hogy az epelen (ami már eleve csak hivataloska) meg a rendes centos repon kivül valahonnan máshonnan találtál még valamit, ahonnan yum installni lehet, és szerinted hivatalos, akkor tényleg ugorjál.

szerinted felfogja valaha meg ebben az eletben?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Es vajon te megerted az alapproblemat is, vagy csak szajkozod, hogy ez igy mukodik, hujeajuzer?

Csak, mert nekem ugy tunik, hogy itt az alapvető probléma az, amibe mar én is sokszor belefutottam, hogy a csuda csomagkezelok valahogy megsem az "IT Silver bullet"-je, es vannak vele megoldatlan problémák. Pl. hogy teljesen a disztrok csomagoloinak kenyere-kedvére vagy utalva. Es ha neked egy picit is nem jo az, akkor meg lehet, hogy nem csak a felhasználónak van a hiba.

---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Egyrészt ez nem teljesen igaz*, másrészt pedig:
-cserébe amit becsomagolnak, azt viszont nagyon egyszerű
-van olyan, aki kb csak a döglött macskát nem csomagolja be neked (az más kérdés, hogy némi minőségi hiányosságra ott lehet számítani a nem agyonhasznált csomagok között)
-a disztrók elárulják, hogy mi a policy, szóval azért tudod, mit fogsz kapni. Valahol a te dolgod ezt figyelembe venni, sajnos minden együtt nem megy. Esetedben pl a főnököd valószínű azért mondta, hogy de centos kell, hogy ne legyen az, hogy amikor te email küldéshez curlt akarsz használni, mert valamiért nem jó az erre ottlévő francsetudja mennyi lehetőség, akkor egy jól irányzott yum install curl-al lehetőleg ne tegyél keresztbe mondjuk a vason futó ssles websiteoknak mert jön az új libssl-el valami bugi, vagy átállít valami security policyt. Cserébe te bizony valamennyit szívsz, ha frissebb curl kell. Jelzem, ha tényleg értenél hozzá, akkor azért általában nem olyan nagy szívás, bár tény, hogy rá lehet szaladni csúnya szopásokra is (pl ezesetben a glibc depek kissé ijesztőnek tűnnek elsőre). Szóval nem silver bullet, de azért egy csomó dolgot megold.

*pl az emlegetett epel már pont egy ilyen, ahol az RH által nem szállított cuccokból kaphatsz még egy adag cuccot úgy, hogy figyelnek az upstream kompatibilitásra. Most, hogy az RH összeborult a CentOSal, várható több ilyen frissebb cuccokat szállító repo (ill az epel bővülése). De van még pár hely, aki tart karban ezt azt, illetve maga az rpm környéki toolok egy csomó mindent aládadnak, hogy megcsinálhasd magad, ha kell. Persze, munka van vele, meg kell hozzá tanulni, cserébe meg lehet vele bírkózni.

Legrosszabb esetben meg még mindig mindent lefordíthatsz magad statikusan linkelve, aztán akkor lesz egy bazi önjáró binárisod.

" Pl. hogy teljesen a disztrok csomagoloinak kenyere-kedvére vagy utalva."

1) ez nem a csomagkezelok hibaja. Ok - meglepo modon - mindenfele eloitelet es ellenerzes nelkul kezelik barki ember csomagjait, ha es amennyiben azok feltelepithetoek a rendszerre. Igen, sokkal-sokkal egyszerubb az elet a tar.gz -kkel, amit csak kicsomagolok "oszt' jovan", csak eppen az ilyesfajta nagy hozzaertok kezeben, mint a topicnyito, tobb kart tud csinalni, mint hasznot.

2) Barmily meglepo, vannak olyan alapveto shared libek, amiknek nem illik bantani a verziojat, mert bajok vannak belole. Es ez meg csak nem is Linux-specifikus. Windowson ugyanekkora baj szarmazhat abbol, ha onkenyesen kicsereled a shell32.dll -t valami altalad vadaszott/ganyolt verziora. Jo esetben a SFP a kezedre vag, es visszarakja a jo verziot, rossz esetben nem, es lesz egy instabil rendszered.

Kovezzetek meg, de en tamogatom, hogy ne lehessen mindent felelotlenul kicserelni egy rendszerben, foleg hozzaertes tokeletes hianya mellett. Ha ez azzal jar, hogy 4 eves csomagokat kell hasznalnom, akkor en bevallalom, mert en vagyok olyan rugalmas, hogy sokfele modon is meg tudjam oldani a problemamat, es ne ragaszkodjak semmilyen szoftver semmilyen verziojahoz sem.
-- 

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

"mindenfele eloitelet es ellenerzes nelkul kezelik barki ember csomagjait"

Ameddig emberekről van szó? Hahahahahahaha....

"Windowson ugyanekkora baj szarmazhat abbol, ha onkenyesen kicsereled a shell32.dll -t valami altalad vadaszott/ganyolt verziora"

Talán esetleg meg kellene nézni, hogy Windowson miért az van, ami, mielőtt azzal jössz, hogy kicseréli valaki a shell32.dll-t. Miért is cserélné ki és miért nem az alkalmazása mellé csomagolja, ha neki az kell?

"hogy ne lehessen mindent felelotlenul kicserelni egy rendszerben"

Na akkor még egyszer: az egész koncepció szerintem ott van elbaszva, hogy abból a téves feltételezésből indul ki, hogy _egyetlen egy_ verzió mindenkinek jó lesz. Aztán itt a példa, hogy mi az eredmény: vagy frissíteni nem lehet vagy nem lehet olyan programot használni, aminek mégse az kell. Vagy megy a barkácsszakkör.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

mintha egy kicsit forditva ulned meg a lovat. Eleve olyan OS-t es disztribuciot valaszt az ember, ami megfelelo verziot szallit abbol a cuccbol, ami kell. Azt meg csak halkan mondom, hogy az almoskonyvek szerint jo az, hogy ha homogen infrastrukturad van, mert akkor nem fordul elo hasonlo baleset, mint hosunkkel, hogy van egy scriptje ubuntu alatt, ami a curl x.y verziojara epit, majd ugyanazt centos alatt akarta hasznalni, amirol koztudott, hogy nem a legfrissebb verziokat szallitja. Majd ezek utan bociszemekkel amult, hogy a centos curl verziojaban nincs meg az a feature, ami a scriptnek kell.

Miért is cserélné ki és miért nem az alkalmazása mellé csomagolja, ha neki az kell?

bocsanat, de ez barmelyik Linuxon megvalosithato. Ki tiltotta meg bviktornak, hogy a scriptje melle tegyen egy masik verzioju curl-t? Ja, hogy senki, csak o inkabb atvaltott destroy mode-ba?

Aztán itt a példa, hogy mi az eredmény: vagy frissíteni nem lehet [...]

komolyan erdekelne, hogy miert nem jo az OS szallitotta verzio? Csak azert, mert egy adott feladatot tobbfelekeppen is meg lehet oldani, pl. a levelkuldest is. Ezt konkretan from scratch megirtam volna annyi ido alatt, amig bviktor elpicsogta, hogy megint atverte a kLOLaautomata...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

"komolyan erdekelne, hogy miert nem jo az OS szallitotta verzio? "

Pl. mert mondjuk picsa regi es jonnek elo a feature igenyek. Mi esetunkben pl. egyre surubben elofordulo szitu: szerver, debian oldstable, 8.3 (oké, oldstableban 8.4 van, de azzal se vagyunk sokkal elorebb), 2.0-as Slony-I, PgAgent akarhanyas. (Attol most tekintsunk el, hogy az utolso kettohoz meg init scriptet sem mellekeltek). Ha azt mondom, hogy nekem 9.1-es PgSQL kellene (ami szinten nem mai gyerek, 9.3-nal tart, de mar beernem azzal is), akkor ugye a kulturalt megoldas az lenne, hogy atallnek debian stablera. Naja, csak akkor meg buktam a slonyt, mert az jelenleg nincs a stableban es meg ki tudja hany dolog torne el.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

csak ezzel ugye visszatertel a topikindito nyugjehez, hogy egy nem annyira hivatalos repo-bol akar valamit feltenni, ami aztan nem illeszkedik a rendszer dependeciajahoz. Persze, ha a pgsql-re ez nem all, akkor az mas. Mondjuk bizonyos cuccok ezt ugy oldjak meg, hogy az x.y.z verziobol kulon csomagok vannak az adott Linux disztribucio kulonfele verzioihoz. Csak hat ez ugye ....

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Debian-ról nem tudok nyilatkozni de COS-os repo-ban szerintem van.
gondolom erre gondolsz:

yum info slony1-92.x86_64
Available Packages
Name : slony1-92
Arch : x86_64
Version : 2.1.4
Release : 2.rhel6
Size : 220 k
Repo : pgdg92
Summary : A "master to multiple slaves" replication system with cascading and failover
URL : http://main.slony.info/
License : BSD
Description : Slony-I is a "master to multiple slaves" replication
: system for PostgreSQL with cascading and failover.
:
: The big picture for the development of Slony-I is to build
: a master-slave system that includes all features and
: capabilities needed to replicate large databases to a
: reasonably limited number of slave systems.
:
: Slony-I is a system for data centers and backup
: sites, where the normal mode of operation is that all nodes
: are available

Azért azt ugye látjuk, hogy ha az operations oldala a dolognak azt mondja, hogy ő ilyenre lő, a development meg laszarja a permisszákat, akkor ezért nem feltétlen a disztrót kell hibáztatni.

(Bár nem ismerem a slonyt, első bliccre azért azt mondanám, hogy ha oldstableban van, stableban meg nincs, akkor vagy gyak senki nem használja, vagy abadoned, vagy ilyesmi, és a kódnak kellene kezelni, hogy valami ezer éves szarrra dependel, és megintcsak furi ilyen esetben a disztróra mutogatni).

Nem leszarja, hanem eppen, hogy szop emiatt, mikozben pl. Windowson, ahol ha kell, ezeket lehet az OS-tol fuggetlenul kezelni. (Persze, akkor meg a frissitessel szopsz kulon.)

Slony-I egy replikacios megoldas PostgreSQL-hez, es azert nem nemigazan "senki altal nem hasznalt" dolog. Egyebkent azzal az indokkal nem kerult bele, hogy frozen allapotban volt a stable, es nem lehetett 2.1-re frissiteni emiatt a Slonyt, viszont a 2.0-asnak volt egy bugja a 9.1-es PostgreSQL-lel.

De amugy ugy, hogy azt se tudod mirol van szo, koszi, hogy leirtad, hogy biztos, hogy nem a debilkevel van gond...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

1) De, pontosan ez a kb leszarás. Hogy neki kell az új feature az opeations meg majd csináljon amit akar, szar az egész, neik nem lehetnek indokaik ;)
1.1) Itt is lehet külön kezelni. Ha specifikus igényed, hogy legyen olyan, fogd meg, fordítsd le, és csomagold be, ahogy neked tetszik. Akár úgy, hogy újracsomagolod a depeket is, akár úgy, "mellécsomagolod" az összes olyat, amire szüksége van. Aztán mehet a /opt-be, ahol senkit nem fog zavarni. Nem gondolom, hogy fejlesztőként (vagy akár a fejlesztő keze alá dolgozó operationsként, btw) annyira megerőltető megérteni, hogy hogyan kell használni az apt/dpkg (vagy a yum/rpm) köré épülő toolchaint. Kb csak kényelmi makrók a szokásos autoconf/automake és egyebek köré. Ja, egyszer kell vele szívni egy kört, utána már mehet.

2) Attól még, hogy a specifikus appot nem ismerem, generál megengeded, hogy legyen véleményem arról, hogy hogyan zajlik a csomagolás? Itt konkrétan ezek szerint az történt, hogy az aktuális upstream slony nem működött ezek szerint jól az aktuális Postgressel, és a disztró nem akart szállítani nem működő izét? (lásd még, hát felteszem azt szar, amit ad, hát milyen szar egy diszrtó ez). Ilyenkor kb a következőket tehette volna a debian:
-Leszarja a saját release processét, és vár, míg a két upstream meg nem oldja (valakinek frissebb bugfixes verzió, nyilván egy rakás friss teszt utána, mert ugye upstreamek nem szeretnek bugfixet régebbi verzióra kiadni). Az a viszonylag jelentős réteg, aki emiatt nem kap friss verziót _semmiből_ nyilván örül ennek. Pl. viktor aki szeretné már a frissebb curlt. (Illetve lásd még, miért van ilyen ritkán release)
-Ha van régebbi postgre, amivel jó volt, akkor inkább azzal szállít, nagy örömet szerezve azoknak, akiknek kellene a frissebb postgre, pláne mondjuk a releseben 2 év múlva, lásd még "miért ilyen régiek a csomagok?"
-Kidobja a slonyt a francba, mivel önmagában nem jó semmire, az aktuális postgressel meg nem megy. Nyilván azoknak nagy örömére, akik használnák szegényt.

Szerintem ebből a háromból a legkisebb rossz még a slony kidobása. Csúsztatni csak nem, postgrest meg mégiscsak többen használnának, mint postgrest+slonyt.

Ill. azt is vegyük észre, hogy ezek szerint a hibát nem a disztribútor hozta, hanem a slony (vagy a postgres, mint mondtam, nem ismerem az adott szitut) fejlesztői, mikor inkompatibilis izét szállítottak. A disztribútor próbálta megoldani. Meg azt is, hogy nem sokban különbözik ez attól, mint ahogy egy fejlesztői projekt kezeli a problémákat mindenféle feautureök beolvasztásának környékén. Nem értem, itt miért olyan nagy gonoszság.

Azt kellene látni, hogy itt -- mint mindenhol -- tradeoffok vannak. Az ilyen disztrók oda valók, ahol sokfélére hsználják őket, van egy nagy közös üzemeltetés, aki komplex izéket szolgáltat, nem csak egy fejlesztésből kieső egy darab szolgáltatást. Ilyenkor sajnos a stabil baseline fontos, és a fejlesztők kell ehhez valamennyire igazodjanak (cserébe, amit nem tudnak bevállalni, mert kell a feature, ott meg az op-nak lesz módszere, meg segítő keze arra, hogy hogyan lehet mégis odatenni abból a frissebbet).

Kisebb porjekteknél ez szívás, mert a külön maintaneléshez nincs meg feltétlen a know-how meg az infrastruktúra. Ilyen esetekben szerintem érdemesebb egy gyakrabban frissülő disztrót használni, szépen beírni, hogy mittomén félévente dedikálunk embert arra, hogy a friss disztró által szállított izére megcsinálja, hogy az ő egy kis valamije rendesen menjen a változásokkal, amit a friss disztró hozott. Ilyenkor ált kevesebb dolgot kell kézzel csinálni, mert régi/nem jó, a scope meg amit tesztelni kell sokkal kisebb, mint a disztibútornak.

"1) De, pontosan ez a kb leszarás. Hogy neki kell az új feature az opeations meg majd csináljon amit akar, szar az egész, neik nem lehetnek indokaik ;)"

Akkor még egyszer és utoljára: NEM tudjuk használni az új featuret, mert az egyik opciónál régi, a másik opciónál meg a featurek fele hiányozna. Ha leszarnánk, azt mondtuk volna, hogy legyen PgSQL 9.3 Slony 2.2-vel és oldják meg, ahogy akarják.

"-Leszarja a saját release processét, és vár"

Vagy inkább a kedves csomagolónak dolgoznia kellett volna. Slony-I 2.1.1 2012 február, Weezly Freeze 2012 június.

De akkor még egyszer: az egész probléma onnan ered, hogy a kedves distrogyártók megpróbálnak megoldani egy olyan problémát, ami nem létezne, ha lenne normális, jól bejáratott szoftver-disztribúciós platform, ahol ki lenne hagyva az egész csomagolósdi és közvetlen az upstream csomagolna. Distrok meg maximum konfigolnának, testreszabnának, és a meglévő alapdolgokból állítanának össze terjesztéseket, nem pedig megpróbálnák megoldani nulláról mindig mindent.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

egy olyan problémát, ami nem létezne, ha lenne normális, jól bejáratott szoftver-disztribúciós platform, ahol ki lenne hagyva az egész csomagolósdi és közvetlen az upstream csomagolna

És az miért lenne jó? Jah, hogy vindózosítaná az összes többi szoftvert is (egy-egy lib legváltozatosabb verziói lennének telepítve), vagy maradna ugyanez, csak a fejlesztőknek plusz egy feladatot adva [meghatározni a dependelt libek használhatói (nem leforduló, használható!) verzióit], csak legalább a disztrók kevesebb eszközt kapnának.

BlackY

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

" csak a fejlesztőknek plusz egy feladatot adva [meghatározni a dependelt libek használhatói (nem leforduló, használható!) verzióit]"

Fejlesztőnek így is meg kell jelenleg határoznia, hogy milyen libekre van szüksége a programnak.

"egy-egy lib legváltozatosabb verziói lennének telepítve"

Mert az aztán most kurvajó, hogy egy ezer éves libet senki nem mer frissíteni, mert a fél rendszer dependel rá.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Fejlesztőnek így is meg kell jelenleg határoznia, hogy milyen libekre van szüksége a programnak.

Alsó verziót, ami felett - amíg platformtól függően API/ABI kompatibilitás megvan - ELVILEG mennie kell. Ha viszont egy frissebb verzióban van egy regresszió, akkor az megtöri az appot: vagyis a mostani állapothoz képest a fejlesztők feladatai nőnéken, mivel MINDEN verzióval tesztelniük kéne - vagy mindig a bleeding edge-re dependelnek, ami azt jelenti, hogy - bár elfutna rajta - a régebbi szoftverek használó rendszereken buknák azt a programot (még ha a valóságban nem is).

Mert az aztán most kurvajó, hogy egy ezer éves libet senki nem mer frissíteni, mert a fél rendszer dependel rá.

Mert a Windowsban az aztán kurvajó, hogy minden projekt hozza a saját libjeit, és van 8 Qt, 5 Gtk, 19 openssl, ... lib verzió, mert ezeket a programokat használod. (hasonlóan pl. a .NET, amiből a 2.0 vagy kompatibilis az 1.1-el, vagy nem, a 3.0 a 2.0-val, ..., az Appok telepítői meg vagy jól vannak megírva és minimum verziót néznek, vagy nem [MS-nél is van olyan telepítő, ami kéri a legalább 2.0-ás .NET-et, de a 3.0, 3.5 és a 4.0, ami a rendszeren van nem elég neki]... és kb. 5 verziót kell telepítened és karban tartanod (1.1, 2.0, 3.0, 3.5, 4.5), hogy garantáltan minden .NET-es cucc működjön.

BlackY

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

Na, ha ez ilyen egyszerűen működne. Ahány szoftver, annyi fejlesztési modell. OpenSource körökben meg valahogy nem feltétlen jellemző a hosszú karbantartási idő és az, hogy minden szoftvernél jól el vannak választva a karbantartási és a fejlesztési ágak, valamint hogy a kőkorszakig visszamenőleg támogatva legyen minden.

Persze, egy distro házilag megcsinálhatja, csak kérdés, hogy mi értelme.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Akkor mégegyszer és utoljára: és mert valaki csinált egy bugot, ami miatt szar volt a program! amit használni akartok. A debian köcsög önkéntes maintanere meg ugrott... Hát, az arrafele előfordul. Meg az is, hogy volt még más okai is a slony 2.1.1 kihagyásának, amiről te nem tudsz :)

A második mégegyszerre: próbálj már meg elvonatkoztatni attól, hogy valakinek az egy darab izéjében ez megoldható. Ha szerinted az egész csomagolósdi csak hülyeség, és nincs rá szükség, hát hajrá, emeld be az általad használt összes 3rd party kódot a sajátodba, tats egy saját fát, kövesd az upstream változásait magad. A build processzed heggeszd meg, hogy ellegyen a bináris végtermék magában, add át azt az üzemeltetésnek. És akkor nincsenek kompromisszumok, pont az van, amit akarsz. Lehet, hogy kicsit sokat kell vele dolgozni, dehát ugye azt már az előbb megbeszéltük, hogy a csomagolósdinak nincs értelme.

Félre ne értsd, igen, vannak az egésszel bajok. Én is szoktam sűrűn anyázni mindenféle miatt. Aztán kihúzom a fejem a homokból, belegondolok, hogy mennyi baszódás megy abba, hogy az ember karbantartsa értelmesen a lokális updatejeit, aztán meg abba, hogy a debian üszkve 50k csomaggal csinálja ugyanezt.

Hagyjad, ezek a distrogyartok nem lattak meg olyat, hogy Maven. Minden ertelmes Open Source Javas szoftver a Maven centralban szerepel.
Amelyik nem, az kizarolag a fejlesztok felelossege (tkp. aki nincs a Maven centralban, az nem letezik).

Erdekes modon, mukodik is a dolog.

Persze a sok linuxhuszarnak eszebe nem jutna ilyen dolog. Mindenbol kell haromezerfele implementacio.

Még nincs olyan régen, hogy a javas embert hallottam erről a működikről hosszasan anyázni. Pedig ő még az op igényeit figyelembe se vette. Meg egyébként is tök releváns egy well defined targetre library csomagoló izét mindenfélre random vackok szállításával hasonlítani. Egyébként meg FYI nem csak javahoz van ilyen, ott a CPAN, ott van a cabal, vagy mi a fene a haskelleseknek, a pythonhoz a pip, a rubyhoz az az izé, ami a gemeket vagy miket szedegeti, meg még ami nem jut eszembe. Aztán ha valamiért ezekhez kell nyúlni, mert nem jó, ami a disztróban van, akkor szokott lenni szopás ezerrel. :)

Nem tudom, én az összes ilyen izével szoktam lukra futni, mikor telepíteni kell. De a mondandó lényege az volt, hogy érdekes, hogy van egy rakás maven [szerű valami], aztán valahogy mégse az a szent grál, és mondja akár csak egy disztró is, amennyire én tudom, hogy tedd fel onnan az összes perl/java/python/ruby/whatevert, mert az tuti, és megoldja.

ezt egyebkent ugy is meg lehet (altalanossagban beszelek) oldani, hogy ha ezt a szoftvert nem csomagbol teszed fel, foleg ha eleve ilyen szintu sakkozast igenyel a dolog. Akkor sokkal ertelmesebb forrasbol feltenni. Igen, ebben az esetben fel kell iratkozni az adott cucc announcement listajara, es kisse tobb kezimunkat igenyel a porta rendben tartasa. Persze egy adatbazis kezelo eleg melyen be tud agyazodni a rendszerbe, szoval ebben az esetben a "kisse tobb" elkepzelheto, hogy egy kicsit eufemisztikus a te esetedben, de siman jarhato ut.

Vagy ha az adatbazis szervert kulon gepre teszed, es nem egy karacsonyfat csinalsz (dev vs. ops), akkor meg az is lehet, hogy az egesz problemakor egy huszarvagassal meg lenne oldva, felteve, hogy 8.x-es pgsql kliens tud beszelni a 9.x szerverrel.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Na, megint jossz a karacsonyfaddal. Egy adatbazisreplikacios megoldast hova a retekbe rakjak mar kulon? :)

Es nem, nem kompatibilis a 2.0 a 9.1-es PgSQL-lel. Amugy tesztkornyezetben az lett a megoldas, hogy felhuztuk a testingben levo Slonyt, mukodik egyebkent szepen.

Bar szerintem az egesszel tized ennyi problema lenne, ha nem minden egyes linux distro hazilag probalna meg megoldani a problemakat, hanem lenne egy kozponti tarolo, ahova a fejlesztok tolnak be a csomagokat, megadva, hogy mihez milyen verzio szukseges.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Bar szerintem az egesszel tized ennyi problema lenne, ha nem minden egyes linux distro hazilag probalna meg megoldani a problemakat, hanem lenne egy kozponti tarolo, ahova a fejlesztok tolnak be a csomagokat, megadva, hogy mihez milyen verzio szukseges."

És ennek a releaselése konkrétan hogyan történne, és mennyivel lenne egyszerűbb így, mint hogy a disztók külön csinálják?

(Hint: pont ezt csinálják a disztrók, csak nem tolják a fejlesztők, hanem húzzák a disztibútorok. Pl azért, mert a fejlesztők kiscsillió nyelven, build environmenttel, és hasonlókkal dolgoznak, és nem tudnának megegyezni egy közösben a te nagy meta tárolódban.)

szerk: ja, és az összes upstream meg tök jól elmondja, hogy itta a csomag, mi kell hozzá? Menj el a honlapjára, és töltsd le. Az úgy miért nem jó?

"szerk: ja, és az összes upstream meg tök jól elmondja, hogy itta a csomag, mi kell hozzá? Menj el a honlapjára, és töltsd le. Az úgy miért nem jó?"

Mert az aztán még jobb, hogy ha a mostani n disztribútor helyett most n*m user végzi el ugyanazt a feladatot ahelyett, hogy 1 fejlesztő csinálná.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ok, csinálja egy fejlesztő. Maradva a pgsql-nél: melyik init rendszerhez írjon az az egy fejlesztő init scriptet (ugyebár közvetlenül ő csinálja a csomagot)? Mindegyikhez? Még ha pl. életében nem hallott a BSD-kről? Vagy nincs elfekvőben egy Solarisa a megfelelő vassal, akkor is? Megugorva ezt a szintet: használjon /etc/default-beli cuccokat vagy ne? ...

Egyszerűen van egy csomó olyan dolog, ami messze nem a fejlesztő feladat- és hatásköre, ennyi.

BlackY

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

Muhaha, mintha a Debilke maintainerek minden csomagukhoz csinálnának init scriptet.

És mégis melyikhez? Egyikhez se, gondolom túl egyszerű lenne ezt is szabványosítani és nem scriptekkel bohóckodni.

Kár, hogy néha ennyire a kőkorszakban élnek a Linux devek és abból indulnak ki, hogy mi volt 30-40 éve, nem abból, hogy mi lehetne.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Láttad mostanában a Debian-nál az összes legyen-e systemd/upstart vitát? A binugz devek egy (nagy?) része átállna a standardra, de akkor jönnek a kFreeBSD, Hurd, ... devek, hogy nono.

Viszont ok, tfh. átáll mindenki systemd-re, meg van a hőnáhított Nagy Egyetemes Rendszeredet (továbbiakban: NER ;) ). Mit értél el vele? App dev pusholja a Nagy Build Rendszerbe a legújabb feature-t, az probléma nélkül lefordítja és mindenki azonnal frissíti. Hát nem, az a cég, akit ebben a rendszerben már csak a support-szerződésért fizetsz ugyanúgy ráküld egy QA-t, megnézi, mi változott, értékeli, hogy az új feature ér-e annyit, hogy kockáztassa miatta a support szerződésekben vállaltakat és marad a 4 évvel azelőtti verziónál. Cserébe legalább esélye sincs backportolni mondjuk 1-1 biztonsági frissítést, mert ugyebár mindenki csak a Nagy Build Rendszerből dolgozhat az ötleted szerint. De jó, találjuk fel a csomag verziózást és a csomagok közti függőségeket verzió-intervallumokkal (ami ugye még mindig több munka a dev számára, mert mondjuk ha 10 csomagra dependel, mindegyiknek van 6 stable-nek nyilvánított supported verziója, akkor 6^10 konfigurációban kellene tesztelnie, hogy a support-szerződéssel nem rendelkezők [ugyebár Debian-t kinyírtad, mert NER van] se szívjanak). Arról nem is beszélve, hogy ez 6^10 különböző konfigurációban való fordítást jelentene. Amihez nem kevés vas kell, egész pontosan az elképzelésed szerint ki hostolná a NBR-t?

Megannyi kérdés, amire választ nem adsz, csak egy teljes iparágat hülyézel le már X-edik hozzászólásban, hogy de mennyivel jobb lenne ha...

Szerk.: Decsakmivel tudom, hogy ez lenne a következő: de, igen, egyre több cross-disztró standard van (LSB, freedesktop.org (<- itt pl. a systemd, pulseaudio), networkmanager stb.), viszont az adaptáció szintje - különösen a hosszú élettartamú disztróknál - nagyon változó. És ott van még a változatos elérési utak problémája, amivel foglalkozik ugyan az LSB, de ott van a - még nem mindenhol átvett - UsrMerge stb. És te a develt szopatnád, hogy ezeket oldja meg - vagy más oldalról, amolyan igazi autokrata módra KÖTELEZŐVÉ tennéd ezeket: ezzel megölve a későbbi változtatás lehetőségét.

BlackY

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

a hőnáhított Nagy Egyetemes Rendszeredet (továbbiakban: NER ;))

jaj...

Btw. a problema talan konnyebben megoldhato olyan disztribucioval, amiben csomagkezelo ugyan van, de dependency(-hell) nincs. Ilyenkor szoktak az aprobetus reszbe beirni, hogy "ha tudod mit csinalsz..."

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

a hőnáhított Nagy Egyetemes Rendszeredet (továbbiakban: NER ;))

jaj...

Nem ok nélkül választottam ezt a backronymot :) Valami hasonló, demokratikusnak látszó autokrata rendszerről álmodozik saxus.

BlackY

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

"és mindenki azonnal frissíti."

Miert kellene mindenkinek automatica frissitenie?

"Cserébe legalább esélye sincs backportolni mondjuk 1-1 biztonsági frissítést, mert ugyebár mindenki csak a Nagy Build Rendszerből dolgozhat "

Mondtam en, hogy meg lenne tiltva, hogy sajat csomagot tegyel fel valamibol (vallalva az esetleges szopas kockazatat?)

"ami ugye még mindig több munka a dev számára"

Devnek igy is ugy is meg kell ezt hataroznia, kulonben mar lefejleszteni se tudna a programjat.

"Amihez nem kevés vas kell, egész pontosan az elképzelésed szerint ki hostolná a NBR-t"

Na alljunk meg egy szora. A fejlesztonek szuksege van vasra, hogy leforditsa a programjat. Ha masnak nem is, sajat maganak. Ez eddig egy vas. Ezen kivul minden distro elvegzi ugyanezt a forditast (eddig 1+n vas), aztan minden distro fenntart mindenbol sajat repot (1+N...1+2N vas), ahhoz, hogy ugyanazt a csomagot szallitsa. Es miert is kellene "nagy build rendszer"? Fejleszto kuldje be a "NER" (:))-el kompatibilis csomagjat, leforditva.

"És te a develt szopatnád, hogy ezeket oldja meg"

Juj szegeny dev, igazodnia kellene nehany szabvanyhoz. Legalabb nehany dev megtanulna, hogy mas is van a vilagon, nem csak az o szuk vilaga. Erdekes modon mas platformokon (pl. OSX) nem megy a hiszti, hogy alkalmazkodni kell dolgokhoz.

"ezzel megölve a későbbi változtatás lehetőségét."

Mar miert is?

De amugy latom, nem igazan sikerult megerteni a koncepciom lenyeget: egyik oldalon van a Linux fele csomagkezelosdi, ahol ezercsillio fuggoseg van. Masik oldalon van a Windows fele "csomagolj mindent az app melle", ami mukodik ugyan, de nincs mogotte kozponti tarolo es fuggosegkezelest is viszonylag huszarosan oldja meg. A kozeppont fele tendal valamelyest az OSX az AppStore-al, mert van kozponti tarolo, de fuggosegkezelest hasonloan egyszeruen oldja meg, mint a Windows (tehat kb. sehogy).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Masik oldalon van a Windows fele "csomagolj mindent az app melle",

mi tiltja meg neked, hogy kedvenc pgsql-ed ily modon tedd fel?

Btw. mar irtak masok is, hogy ez a gyakorlat egy picit veszelyes mondjuk egy sec. bug eseten, foleg ha 15 developer is csomagolja a problemas libet az alkalmazasa melle egyenkent.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Miert kellene mindenkinek automatica frissitenie?

Mert különben a dev teamnek kéne supportolnia az idők végezetéig minden verziót.

Szerk, ezt kihagytam:

Fejleszto kuldje be a "NER" (:))-el kompatibilis csomagjat, leforditva.

Ez meg súlyos gondokat vet fel a megbízhatósággal. Az sem garantál semmit, hogy a RedHat, Novell, Debian (Canonical végképp :D) csomagol valamit, de bináris blobokat noname projektektől válogatás nélkül nem szívesen telepítgetnék. A másik meg: melyik architektúrákra? Tudom, van, amit lehet emulálni, de azért minden arch-ra minden projektnél fenntartatni build gépeket... problémás.

Mondtam en, hogy meg lenne tiltva, hogy sajat csomagot tegyel fel valamibol (vallalva az esetleges szopas kockazatat?)

Ez most is megvan.

Devnek igy is ugy is meg kell ezt hataroznia, kulonben mar lefejleszteni se tudna a programjat.

A dev azt mondja meg (és most élő példa, openSUSE 12.3-ból), hogy a libgnutls-ből neki legalább 3.2.2 (hasraütés, nem néztem meg) kell, mert annak az API-ját használja. A libgnutls mondjuk 3.2.8-ig kompatibilis API-t ad, de speciel a 3.2.4-ben van egy regresszió, így az Evolution bugzik kellően nagy postafiókkal. Ezeket összehangolni/megtalálni most a disztribútor feladata - te ezt átlöknéd a dev-re.

Erdekes modon mas platformokon (pl. OSX) nem megy a hiszti, hogy alkalmazkodni kell dolgokhoz.

Más platformokon a kezdektől kezdve az "azt kapod, amit mi mondunk" elv megy, vagy ahol nem bár eszerint működnek, de a kurva nagy nyíltságot kommunikálják, ott is megy ugyanez a hiszti (android, ugyebár)

Masik oldalon van a Windows fele "csomagolj mindent az app melle", ami mukodik ugyan, de nincs mogotte kozponti tarolo es fuggosegkezelest is viszonylag huszarosan oldja meg.

De pont ez az, hogy nem működik. Mert így mondjuk egy standard otthoni használatú Windows-on lesz egy qt lib-ed a VLC mellett, egy Steam mellett, ... mellett, egy openssl-ed X,Y,Z programok mellett, .... Ha BÁRMELYIK verzióban van egy sebezhetőség, amit - mivel ugye a szállított program készítőjének a feladata a frissítés - ha nem frissítik a progit, amihez mellékelik, szépen ott marad a gépeden.

BlackY

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

"Ha BÁRMELYIK verzióban van egy sebezhetőség"

Spec. egy sebezhetőség javítása nem igényel API módosítást az esetek 99,99999999%-ában.

Persze, gondolom már az is megerőltető lenne fejlesztőnek, ha rá kellene szoknia arra, hogy nem releasel mindent agyba-főbe, hanem a bugfixeket az x.y.z+1-ben adja ki, ami kompatibilis marad az x.y.z-vel.

Többire most nincs időm válaszolni, majd később.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem, még csak újra sem kell fordítania a cuccot, csak lekapni a javított so-t/dll-t a lib oldaláról és valahogy a saját userei közt terjesztenie. Amivel két probléma van: nincs standard eszköz a terjesztésre (megoldható lenne, de hány "jujj van frissebb verzió" popup jön fel egy standard Windows-on minden indításkor?) és az alkalmazás írójának a feladatává teszi (jó esetben, a valóságot hagyjuk, nem megoldható) az upstream projektek biztonsági hibáinak a követését.

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

"terjesztenie. Amivel két probléma van: nincs standard eszköz a terjesztésre (megoldható lenne, de hány "jujj van frissebb verzió" popup jön fel egy standard Windows-on minden indításkor?) "

Ne a mostból indulj ki és a meglévő megoldások elbaszott dolgaiból. Meg lehetne ezt oldani kulturáltan is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Pontosan.

És ne felejtsük el, hogy attól még az igények nem fognak változni, tehát továbbra is kell:
- stable rendszer, ami akár 10 évig is támogatott (RH, Novell) és stabil alapnak minősül, tehát az nem ér, hogy dehát támogatott, ha a legújabb verzió van fenn minden libből (lásd bviktor elvárásait)
- bleeding edge rendszer, rövid támogatottsággal (Fedora, openSUSE, Ubuntu nem-LTS)
- a kettő közötti mondjuk 3 éves támogatottsággal (Ubuntu LTS, Debian, ...)

Továbbá:
- biztonságos és fenntarthatóan biztonságos, tehát ha van egy ismert biztonsági hiba, akkor az azonnal javítható legyen függetlenül attól, hogy hány és miféle program van fenn
- csomagokkal a mindennapi használathoz megfelelően ellátott (nem ér az, hogy csinálsz egy disztrót, ami áll egy LTS kernelből és hozzá libc-ből) és - ahol értelme van - adjon választási lehetőséget (nem ér a Microsoft-féle ez itt a shell, ez itt kernel, ez itt a paint program ...)

BlackY

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

szerintem nem kell ennyire merevnek lenni, nem ezek az elvárások. Pusztán csak:
-Legyen megoldva a security patchelés
-Egy program telepítése ne törjön el stabilnak definiált interfacet a tudtom nélkül.
-Ha mégis, akkor hozza magával az össze olyanból a firsebbet, amit eltör.
-Meg legyenek oldva az ilyen keresztbe szívások, hogy ebből ez, abból meg amaz kell.
-Mellőzzük az olyan részeket, ahol a világ összes fejlesztőjét kötelezzük arra, hogy olyan dolgokkal foglalkozzanak, amit leszarnak maguktól.
-Legyen megoldva, hogy mi van konfliktusoknál (mittomén postfix/exim, apache/ngnx, upstart/systemd, meg ilyenek)
-Ill a legutolsónál ugye az a fenti mondás, hogy ő bizony gyak mindent tud ebben az izében szállítani.

Azt hiszem hirtelen ennyit ha megoldunk, akkor már fasza lesz. Aztán jöhetnek a corner case-k,

Melyik volt a corner case?

Ha a hosszú támogatás: pont most zártam be az ablakot, de az 5-ös CentOS-ben (így valszeg EL-ben is) van olyan PHP verzió, amit az PHP project már nem támogat*. (CentOS 5: PHP 5.1.6 (ezen csomaglista alapján, 7 év és öt hónapja jött az ágban az utolsó release), EL-éktől maintenance update-ket elvileg 2017-ig fog kapni, az ötösben és a hatosban is bennlevő 5.3-as ágnak is tippre max egy éve van - az EL mégis utóbbiban 2020-ig támogatni fogja)

Lehet kitalálni kurvajó rendszereket, hogy jajj a devel azonnal releaseljen az end usernek mert az mennyivel egyszerűbb, csak ezzel vagy a devel fog szívni (mert neki kell 5-10 évig támogatnia ezeket a rendszereket, nem a disztribútornak) vagy az end user, aki állandóan rendszertfrissít.

BlackY

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

Én is (mármint túlzásnak tartom), 3+3-al már ki lennék békülve (3 év mainstream, 3 év biztonsági), meg az ötösnél is ott van az 5.3-as ág is a tárolóban, tippre a support azzal kezdené a feltörték a PHP 5.1-emet, hogy "Ja, ígyjárás, tetszett volna migrálni", de maga a csomag ott van :) [bár tavaly decemberben még hozzányúltak valamit a Directory index alapján]

Szerk, disclaimer.: A tetszett volna migrálni dolgot nem tapasztalatok alapján írtam, hanem tényleg tippre a más (hw,sw) gyártóktól tapasztalat support-szint alapján, nem állítom, hogy az RH ezt csinálná, azt sem, hogy nem.

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

Dehát már most is megcsinálja az az egy fejlesztő. Ott van, mindenki kiteszi a saját kódját. Tekintve, hogy szerinted az egész csomagolósdi, meg disztrósdi hülyeség, szerinted ebből kell dolgozni. Mi tart vissza attól, hogy onnan szedd le, és használd, ha neked az jobban tetszik? Fogj egy akármi minimal installt, ha azzal nem akarsz szívni, az összes izéded meg kezeld magad? Ez miért nem felel meg a te világképednek?

"debian oldstable"

Egy elavult, unsupported rendszerrol beszelgetunk. Eleg invalidnak erzem innentol a komment tobbi reszet. Tessek tamogatott verziokat hasznalni, ha arra van panasz, akkor folytathatjuk a beszelgetest.

FYI: a topikindito egy supported, up-to-date rendszerbol indult ki.
-- 

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

"Egy elavult, unsupported rendszerrol beszelgetunk. "

Azt sikerült felfogni, hogy nem tudunk frissíteni, maximum úgy, hogy összepancsoljuk a testinget a stableval?

Egyébként meg, Wikipedia szerint "TBA (expected 2014-05)".

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Talán esetleg meg kellene nézni, hogy Windowson miért az van, ami, mielőtt azzal jössz, hogy kicseréli valaki a shell32.dll-t. Miért is cserélné ki és miért nem az alkalmazása mellé csomagolja, ha neki az kell?

Értem én, hogy rengeteg szempontból sokkal egyszerűbb lenne, ha mindenki mindig mellécsomagolna staticra fordítva mindent, meg ez ad egy adag flexibilitást. Cserébe mondjuk én erős lábrázást kapnék, ha nem lehetne mondjuk a libssl security patcheit egy helyen kezelni, mert 5 csillió daemonban egyesével benne lenne valami átemelt szar, és lehetne egyesével nézegetni, hogy az összes upstream
-használja-e egyáltalán
-patchelte-e
-várni, hogy egyesével megtegyék
-ha nem teszik, akkor mit használnak pontosan
-és hogyan lehet ráerőszakolni a patchet
-majd hogyan lehet ez teríteni a vackukhoz

IMHO a túlegyszerűsített "miér nem megy akármi akárhol OOTB, hát szar az egész" szimpla -- és meglehetőst jellemző -- fejlesztői ignorancia a világ működésének egy jelentős részéről.

( Elbandi v | 2014. 01. 31., p – 14:46 )

ubuntuban (lucidhoz) nekem bevalt, hogy csak siman(*) ujra kell porgetni a csomagokat lucid-ban, es akkor a required reszt az aktualis verziohoz keszul.

* multiarch-os csomagokkal van egy kicsit tobb munka, de 15 perc alatt megoldhato

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( sj | 2014. 01. 31., p – 14:53 )

ha veletlenul rossz napon (i.e. uj release utan) adsz ki yum update-et (ami alapesetben ugye frissiti a csomagokat), akkor az update-bol dist-upgrade lesz

mondjuk egy 6.4-rol 6.5 upgrade-nek illene nem fajnia. Dist-upgrade meg sokkal inkabb egy 6.4->7.x valtas lenne.

Btw. aruld mar el, hogy ha a centos ilyen fos, akkor miert szivatod magad vele? Ahelyett, hogy feltenned poliverzum lfs-et, amiben barmibol lehet barmilyen verzio, oszt csokolom. A menetrendszerinti "ez se jo, az se jo, semmi se jo, mert luzer vagyok..." kezdetu szokasos bviktor picsogas lattan csak arra tudok gondolni, hogy neked egyfajta kognitiv kieleguletlenseged van a nap vegen, ha legalabb 2-3 dologgal nem szopattad szenne magad. Nem baj, meg elotted az elet, hiszen csak 25 vagy, ugyhogy ez a temerdek szopas vegul is belefer meg...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Azért szeretem a HUP-ot, mert az itteni emberek túlnyomó részének eszébe sem jut, hogy valakinek az IT a munkája, nem a hobbija.

Ha most írnék egy emailt a főnöknek, hogy figyu főnök, dobjuk ki azt a pár ezer windows-t, tegyünk a helyére linuxot, mert az a menő, akkor hétfőn már nem kéne bejönnöm dolgozni. Sőt, lehet, hogy a ma délutánom is szabad lenne.

Na lehet, hogy ezért használ bviktor CentOS-t.

amennyi bviktor onszopatast olvastam mar, szerintem neki az IT sem a munkaja, sem a hobbija, hanem az ellensege.

Ha most írnék egy emailt a főnöknek, hogy figyu főnök, dobjuk ki azt a pár ezer windows-t, tegyünk a helyére linuxot, mert az a menő

bocsanat, de az alapveto problema nem az, hogy windows vagy linux, meg hogy mi a meno, hanem az, hogy hosunk nem ert hozza, es ebbol kifolyolag valami hulyeseget csinal, majd jol megbloggolja a hup-on, hogy xyz mar megint milyen szar. Az nyilvan meg sem fordul a kisgyerek fejeben, hogy esetleg o a balfasz. De popcornnal teljesen jo, bviktor olyan a hup-on, mint aurelio a vv6-ban. Meg korban is pariban vannak :-)

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

( SzBlackY | 2014. 01. 31., p – 17:59 )

Ellentroll:

Windows XP-re miért nincs legfrissebb .NET (4.5)? És ezt a szart tolja a Microsoft vállalati környezetbe'! (ráadásul ott egy fokkal rosszabb, mert esélyed sincs fordítani magadnak egyet, ugyebár...)

BlackY

Talan, mert a Microsoftnál mar szabadulni akarnak egy 4 verzióval korabbi, 13 eves rendszertől es tekintve az atlag .net adoptalasi sebességet, elobb jar le az XP supportja, minthogy a .NET 4.5 legyen a domináns target.

Egyebkent meg teljesen irreleváns a temat illetoen, ettol nem lesz ujabb curl a rendszerben.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A RedHat-nél meg nem akarják a fél rendszert frissíteni egy curl miatt. DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET és TFTP. Ha frissíteni akarod a curl-t, akkor az ezekhez a protokollokhoz tartozó libeket is legalább arra frissítened kell, amit az új curl kér. Amit a RedHat nem akar bevállalni, mert az az ígéretük a vásárlóik felé, hogy egy stabil és kiszámítható platformot kapnak. Akik viszont továbbra is tudnak maguknak csinálni újabb verziójú curl-t (ott van a curl forrása és minden szükséges lib forrása), nem muszáj az a curl developer által - ezek szerint rosszul - épített csomagokat használni.

BlackY

( tombenko v | 2014. 02. 01., szo – 13:01 )

Sok nyállal könnyebb! :)
--
Fight / For The Freedom / Fighting With Steel

( msandor v | 2014. 02. 01., szo – 13:02 )

"Bar amugy nem ertem, hogy miert enterprise egy olyan OS, ahol ha veletlenul rossz napon (i.e. uj release utan) adsz ki yum update-et (ami alapesetben ugye frissiti a csomagokat), akkor az update-bol dist-upgrade lesz."

ha ezt el akarod kerülni, akkor be kell fagyasztani az OS-t, van rá mód CentOS-nál is

Értem én, hogy ott a vault, de abba meg nincs sec update (se).

Azt kell megérteni, hogy alapvetően centos 6 van, nem centos 6.x, azok leginkább csak kényelmi izék, hogy legyen egy frissített baseline, de maga a hatos egy ág, arra megy minden, és azon belül nem jellemző, hogy random csomagokat felülverjenek új verzióval, meg átalakítsanak, új dolgokat hozzanak be. Szóval egy 6.4->6.5 baromira nem lesz dist upgade.

(tudom, hogy ez nem egészen igaz minden csomagra, meg vannak ilyenkor tech previewk meg ilyenek, de az elv az ez)

( btami v | 2014. 02. 01., szo – 20:13 )

"Anyad. Oke, szedjunk curl csomagot a hivatalos oldalrol. Nagyon jo lesz, hogy az EPEL-en kivul meg mashonnan is csomagolunk, de nem baj, lenyeljuk a bekat.

curl: (2) Failed Initialization

? biztos. Ebbol a rendkivul beszedes uzenetbol vegul is annyi a lenyeg, hogy a libcurl-t is frissiteni kene, amire nagyjabol az OS fele depend-el, de bevallaljuk, kemenyek vagyunk."

Inkább buták.

--
♙♘♗♖♕♔