a CentOS 8 egy év múlva megszűnik

Hozzászólások

Szerkesztve: 2020. 12. 08., k - 18:17

Na, fasza. Eddig volt egy stabil cucc, most meg a CentOS lesz a teszt kiadás, ha stabilnak bizonyul, akkor megy a RHEL-be. Köcsög IBM.

+1 

350 USD / év = csak fizikai vasra telepítheted 

800 - 2600 USD / év = VM -re is teheted , Enterprise csomag

 

Fedora Server != Centos 

vagy majd merge  ? vagy csak simán megszüntetik a Centos-t ? kettőt biztos nem fognak meghagyni...

erről valami info ?

Ha nem kell szupport akkor elvileg ugyanúgy használható az Oracle Linux mint most a Centos? Jól értem ezt? Nincs regisztráció a yum repókhoz, frissül rendesen, követi az RHEL csomagokat stb? Nincs corporate kizáró rendelkezés stb?

https://linux.oracle.com/switch/centos/

Mert akkor tényleg megfontolandó. Csak ott lebeg mindig az ember feje felett ,hogy bármikor mondhatják hogy mostantól fizess a bináris repo használatért.... stb...

"bármikor mondhatják hogy mostantól fizess a bináris repo használatért" - ez igaz, és ez a veszély a CentOS esetében is megvolt, amit -gyakorlatilag- meg is tett a RedHat. Jó megoldás nincs - ami mögé supportot rak egy cég, ott bármikor vége lehet az ingyenességnek, és vagy forkolsz, vagy fizetsz...

Drága mert nem ehhez vagyunk szokva. A pandémia idején mindenki elkezd (jobban) racionalizalni. Mondjuk egy js lib elvesztése miatt nem sirnék, az OS komolyabb lépés.

Nálam pont pár év múlva futnak ki a centos apache+php kombók, az újabb nodejs platformokat már Ubuntu fogom futtatni. Wordpress host pedig megy a konkurrenciahoz. 

Annyiban igaza van azért - ha tartasz engem annyira szakmainak ezek után, mivel én az összes nagy disztribúciót kipróbáltam, erről el is indítottam egy blogsorozatot, de a hozzászólásokat inkább ne nézd meg - igazából a red hat vonalat ilyen minőségben semelyik disztribúció nem követi. Ha csak a biztonságot nézzük. Ott van alapértelmezetten például az SELinux. Az rendben van, hogy ubuntun vagy debianon is elérhető, de mivel azon a suse féle AppArmor az alapértelmetzett, ebből az következik, hogy nincs alaposan kitesztelve az SELinux. Szívás lehet a beüzemelése. Erre felhívja a debian wikije is a figyelmet. A másik probléma az, hogy más disztreibúciókól policyik is hiányozhatnak. Persze számos példa van még. Red Hatéknál a biztonság magas prioritás, ezért az alkalmazások tárháza is kevesebb, és általában, ha egy feladatra több alternatív alkalmazás is rendelkezésre áll, red hat/centos és társaiban a magasabb biztonságú, de butább/egyszerűbbet hagyják bent.

Egyébként SELinux téren csak egyetlen alternatív disztribúciót tudok mondani, de attól itt sok embernek kihullana a haja és jönnének az nem produktív környezetbe való és ehhez hasonló dumával.

Ez a Gentoo. Ebbe kapásból nemhogy nem kevesebb, de sokkal több policy is van.

A másik probléma meg az, azért az nem titok, de ubuntu stabilitás szempontjából azért szerver téren is elmarad egy centoshoz képest, amennyiben a legfrissebb kiadásról beszélünk.

Igen én is sok linuxot kipróbáltam nem úgy mondtam az Ubuntu-ról, hogy nem szerverre való.

Kezdetekben Caldera linux egy mosógép méretű 2x Itanium  csoda masinával vagy Gentoo -t raktam Sun netra T1 -re és a Debian vonal: Progeny. Haverom Slack -es volt, így ha közös projekt volt, akkor azt kellett babusgatni..

Ubival is próbálkoztam, de mindig valami összejött - ha működött teljesítmény és vagy üzembiztonsággal volt a baj. Persze jó pár éve nem próbálkozom - minden CentOS / RHEL - kivéve ARM-os cuccokra oda Debian.

 

És a legfontosabb érv RH vonal miatt - sok esetben:

Production környezetben: van sok száz RHEL szerver/VM megvásárolt Enterprise Linux évente auditálva. A fejlesztői környezetre CentOS volt használva ugyanazzal a konfiggal... -- Ez került most veszélybe

A fejlesztői környezetre CentOS volt használva ugyanazzal a konfiggal... -- Ez került most veszélybe

Ennek pont nem kellene veszélybe kerülnie, jóideje létezik ugyanis a Red Hat Developer Program:

https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-su…

 

Persze biztosan macerásabb mint a egy CentOS, mert ehhez kell regisztráció is...

De - a RedHat szerint - a CentOS eddig sem garantált "binary compatibility"-t, annak ellenére hogy a gyakorlatban ez azért legtöbb esetben probléma nélkül megvolt.

"jóideje létezik ugyanis a Red Hat Developer Program:" - igen, létezik (mint ahogy Oracle-ből is van az OTN-es cucc), csak ezek "development-only subscription"-két működnek, azaz production rendszert licenszelésileg nem rakhatsz rájuk - míg a CentOS-ra lehet full production vagy épp UAT környezetet is pakolni, és csak a prod. alá kell licenszelt retket venni.

"a RedHat szerint - a CentOS eddig sem garantált "binary compatibility"-t" - Persze, ugyanabból a forrásból fordított bináriskok másképpf ognak viselkedni... Oké, valamikor RHEL6/CentOS6 táján egyszer volt olyanhoz szerencsém, hogy selinux policy-ban más volt a kettő, de ennyi - és azért volt szerencsém CentOS-RHEL párosokat üzemeltetni, elég tisztességes számban.

Sokszor megkérdik, hogy miért nem komálom a bubuntut. Ekkor szoktam élni azzal a hülye hasonlatommal, hogy képzeld el, hogy az összes disztró egy kiadós sörözés után a sötét sikátorban a fal mellett áll és hugyozik. Ki a falat, ki a fal tövébe, kinek hogy esik jól. Na, amelyik háttal a falnak, térdig letolt gatyával, guggolva próbálja a bokáját nem lepisálni, na az a bubuntu. Húszból tizenkilenc egyféleképpen csinál már vagy 30 éve valamit, de a bubuntu az újít.

Igen, sokkal jobban lehet úgy, hogy minden frissítéskor kihúzzák a felhasználók lába alól a talajt, valamilyen szempontból, illetve jól bejáratott megoldások helyett újrafeltalált kerekekkel operálnak, amik szerencsétlen esetben csak babzsákfejlesztőék 12. generációs 8 magos, 64 GB RAM-os 2 TB SSD-s csúcserőművein működnek hatékonyan.

10 év a support ciklus az OS esetében, ez alatt _semmit_ nem húznak ki a felhasználók lába alól. Semmit. Főverziókat _sem_, néhány kivételes esettől eltekintve - de azt meg megint csak lehet normálisan kezelni (És a rolling/néhány évente kiadott disztrók az alatt a 10 év alatt hányszor rántanak ki főverziót bármiből is a felhasználók lába alól?). Egy üzleti alkalmazásnál 3-5-8 év szokott lenni a nagyobb refaktoringok és/vagy vitális komponensek cseréje között eltelt idő, így marhára nem releváns, hogy az adott szolgáltatáshoz/komponenshez új OS-t kell telepíteni. (Egyébkétn azok a "jól bejáratott megoldások" azok, amik miatt sokan, sokat szívnak egy-egy eszköz megdöglése, vagy épp egy alkalmazáskomponens támogatottságának lejárata miatt. Nem, ne gyere azzal, hogy minden szoftvert támogassanak 1024 évig meg egy napig, mert annyi fejlesztő meg pénz nincs, amennyiből ezt meg lehetne csinálni, bár a "gazdasági racionalitás" fogalom bnálad ismertelen, vagy legfeljebb szitokszónak alkalmas, tudjuk...)
Bónuszként a hardvert sem tartják meg production-ben garancia/kiterjesztett garancia idején túl, mert az üzleti kockázata nagyobb, mint amennyibe egy új eszköz kerül - ami ráadásul energiafelhasználásban és energiahatékonyságban is messze jobb.
 A RHEL nem elsősorban a home userek 1234 éves őskövület gépeire van szánva, nem arra, hogy homeuserpéhápépistike fel...ta az egyészet egy partícióra mint a windows-t szokta, aztán sír,mint a fürdős...va, hogy 5-10 év után egy újratelepítés kéne.

Igen, az RHEL továbbra is 10 év. A CentOS 8-ról volt szó, ami rolling release lesz. Örülök, hogy sikerült megint (szándékosan?) félreértened, csakhogy kötekedhess egy sort.

Egyébként meg de, igen, kihúzzák a lábad alól a talajt. Például egy CentOS 6 és egy 7 között is vannak olyan breaking change-ek, mint a senki által nem kért, de beerőltetett Poettering-féle systemd. Tudom, a systemd jó™, a systemd szép™, a systemd szükséges™ és ha valakinek baja van vele, az user™ error™, vagy nem™ értette™ meg™ a nála nagyságrendekkel™ okosabb™ és enterprise-abb Red Hat developerek gondolatmenetét, ami kizárólag az ő™ hibája™. Azonban bárkire is mutogatunk, ezek nem triviálisan orvosolható breaking change-ek.

Én azt gondolom, hogy 10 évente belefér (mégiscsak több, mint egytized emberöltő), hogy kihúzzák az ember lába alól a talajt és szánjon rá akár több napot, hogy átálljon az új rendszerre, amennyiben az új rendszer minden szempontból jobb és nem csak annyit tud felmutatni, hogy újabb™, bizonyos szempontból meg rosszabb is.

Az viszont nem fér bele, hogy havonta-félévente legyen bootolhatatlan vagy használhatatlan a rendszer, mert egy magát agilisnek hazudó, de az agilitás eredeti értelmét saját zsírjában égettre sütő babzsákfejlesztő éppen nem gondolt az én használati esetemre, de közelgett a határidő és valamit kellett mutatni menedzseréknek-befektetőéknek.

Nem, ne gyere azzal, hogy minden szoftvert támogassanak 1024 évig meg egy napig, mert annyi fejlesztő meg pénz nincs

Nem akartam ezzel jönni, de ha már felhoztad, akkor de, igen, van rá pénz. Csak abből a pénzből inkább milliárdosékat teszik még milliárdosabbá, ahelyett, hogy értelmes célokra költenék, például azon rendszerek támogatására, amik még széles körben használatban vannak. Erre a Linuxok nem jó példák, de a támogatás lejártakor még 400 millió ember által használt Windows XP és a 900 millió ember által használt Windows 7 igen. A Microsoft is jó példa, mert a megszámlálhatóan végtelen pénzéből bőven telt volna támogatásra, csakhát nem jó, ha az ember saját magával kell versenyezzen úgy, hogy nem tud jobb, hatékonyabb, kompatíbilisebb rendszert csinálni a korábbinál. Mert a Windows 10 minden, csak nem az.

Arról volt szó, hogy szerinted a rolling release a faja, mert az x éves frissítési ciklus meg a dist-upgrade miatt kihúzzák a talajt a felhasználók alól.

Nem, nem húzzák ki, mert ahol a RHEL/CentOS célszerűen hazsnálatban volt, ott az a 10 év bőven több volt, mint a rajta futó rendszerek életciklusa, azaz egyébként is újragondolva, "újratervezve" célszerű új OS-verzióra átállni.

Az, hogy mit hozott a RHEL7 a 6-hoz képest, az szép hosszú lista - igen, ugyanis van a komponensek főverziói között x évnyi különbség, és a világ, a sw-es világ, ha neked ez fáj meg nem tetszik, haladt előre. És az új dolgok mellett valóban, egy csomó ócskaságot kidobáltak. De erre való a két verzió támogatása közötti átfedés, hogy a réginek a production-ból való ki-, au újnak meg a prod-ba való bevezetése, az új eszközökkel, környezettel való tervezés és implementáció jól működjön. És műlködik is. persze el kell olvasni és meg kell érteni a release notes-t, a változások listáján át kell rágni magát annak, aki a migrációt megtervezi és végrehajtja - de ez egy ilyen szakma: a tudás egy jelentős része néhány évente lecserélendő.
Írod, hogy az új "bizonyos szempontból meg rosszabb is" - nagyon kevés ilyet látok, a támogatás, illetve a biztonsági és egyéb fejleszutések mellett ezek bőven kezelhető szinten maradnak, sőt, a legtöbb esetben "csak" meg kell ismerni az újat, és elengedni a régit - amiben te tudvalévő, hogy baromira nem remekelsz. Sőt. Ettől még a világ többi részének meg bőven megfelel az, hogy tudja, 10 évig stabilan számíthat azokra az elemekre, amit az OS nyújt.

"de, igen, van rá pénz. Csak abből a pénzből inkább milliárdosékat teszik még milliárdosabbá, ahelyett, hogy értelmes célokra költenék" - Mondd már meg, hogy mi a búbánatból? Tételesen sorold már fel, hogy szerinted miből lehet fenntartani 2020-ban mondjuk RHEL5-höz támogató infrastruktúrát? fejelsztői- és teszkörnyezetekkel (Adott OS-ben támogatott hardverekkel!), build-infrastruktúrával, mindennel együtt? Ha hardverspecifikus hiba esik ki mondjuk egy ügyfélnél RHEL5-ből, akkor azt ugye a supportnak tesztelnie/reprodukálnia kell tudni - azaz szüksége van az anno támogatott hardverből legalább egy megbízhatóan működő darabra. Honnan vegyen? És honnan szerezzen, ha a tesztlaborban megpusztult valami megmagyarázhatatlan okból (mert ugye szerinted a hardverelemek örökéletűek...)?  Kicsit kisarkítva a dolgot, elvárnád, hogy a Ford márkaszervíz tartson szerelőt meg alkatrészt a T-modellhez is?

Arról volt szó, hogy szerinted a rolling release a faja, mert az x éves frissítési ciklus meg a dist-upgrade miatt kihúzzák a talajt a felhasználók alól.

Nem erről volt szó. mt9 mondta az alábbiakat, több disztribúcióról. [1]

Szerencsére elég sok disztró kezd rájönni, hogy nem lehet fejlődni úgy, hogy ugyanazt csinálja 30 éven át. 

Én pedig erre szarkazmussal reagáltam [2], kifejezve az egyet nem értésem a folyamatos változtatgatással. Konkrétan nem volt szó rolling release vs. LTS ágakról és nem is tettem le a voksom a rolling release mellett. Ezt még utána külön tisztáztam is. [3]

Én azt gondolom, hogy 10 évente belefér (mégiscsak több, mint egytized emberöltő), hogy kihúzzák az ember lába alól a talajt és szánjon rá akár több napot, hogy átálljon az új rendszerre, amennyiben az új rendszer minden szempontból jobb és nem csak annyit tud felmutatni, hogy újabb™, bizonyos szempontból meg rosszabb is.

Ezek után az olyan szélsőségesen fejlődésmániás vagdalkozások, mint pl. "meg kell ismerni az újat, és elengedni a régit - amiben te tudvalévő, hogy baromira nem remekelsz" teljességgel értelmetlenek. Már rég nem ezen a síkon van a probléma.

Mondd már meg, hogy mi a búbánatból? Tételesen sorold már fel, hogy szerinted miből lehet fenntartani 2020-ban mondjuk RHEL5-höz támogató infrastruktúrát?

Abból, amiből a RHEL 6-ot, RHEL 7-et és RHEL 8-at párhuzamosan fenntartották. A security és maintenance támogatás nem úgy működik, ahogy a marketinganyagokban és a kifogáskereső PR-kommunikációkban azt előadták neked, hogy külön még egy egész Red Hat-nyi embert fel kéne venni, és amúgy is ehhez a világ összes pénze is kevés lenne. A biztonsági- és hibajavításokat sok esetben backportolják, tehát akár 3 párhuzamosan támogatott rendszer javításán dolgozhatnak ugyanazok a csapatok. Ugyanakkor, emlékeztetnélek, hogy a Microsofttal példálóztam ebben a kérdésben, nem a Red Hattal. Ott néhány nagyságrenddel több pénz van.

Kicsit kisarkítva a dolgot, elvárnád, hogy a Ford márkaszervíz tartson szerelőt meg alkatrészt a T-modellhez is?

Elvárnám, amennyiben a T-modellt 900 millió ember használja, ami az autótulajdonosok legalább 30%-a. Ezt úgy hívják: piaci igény.

"Abból, amiből a RHEL 6-ot, RHEL 7-et és RHEL 8-at párhuzamosan fenntartották." Oké, tehát a RHEL6 _előtti_ verziók használói hol és mikor fizették/fizetik meg az általad elvárt support költségét? Mert a 6-7-8 vásárlói, az ezekre támogatási szerződést kötő ügyfelek _nem_ a régebbi verzióknak a supportját finanszírozzák, hanem azt, amit használnak. Te azt mondod, hogy full kihúzzák a szőnyeget az üf. lába alól főverzió váltásakor - de azt mondod, hogy a support az nem ilyen, ott mindenki tud mindent támogatni, mindenki fel tzud szívni tetszőleges számú verzióhoz kapcsolódóan új ismereteket, illetve - és ez is kérdésem volt, de nagyvonalúan elsoklottál fölötte - az adott régi verziókhoz teszthardvere honnan lesz a RedHat-nek/IBM-nek? Mondjuk olyan, amit már x+sok éve nem gyártanak, nem kapható, nincs belőle működő darab csak néhány ügyfélnél esetleg? Ugyanis a supportos mögé a szoftveres problémákhoz kapcoslódóan tudásbázist lehet rakni, de hardvert, aza dott probléma reprodulálására már nehezen, vagy sehogy. Nos, honnan lesz tehát hardver mondjuk a RHEL5-ben még támogatott eszközökre?

"a Microsofttal példálóztam ebben a kérdésben [...] Ott néhány nagyságrenddel több pénz van" - Mennyi az a néhány? Egy, kettő öt? (Tízszer, százszor netán százezerszer annyi pénz - anagyságrend ugyanis tuzes szorzót jelent a köznyelvben...)

"ami az autótulajdonosok legalább 30%-a." - Melyik az a már nem támogatott OS, amit a felhasználók ekkora hányada használ mind a mai napig? Kérnék egzakt és megalapozott statisztikai és piaci adatokat citálni a kijelentésed mellé.

régi verziókhoz teszthardvere honnan lesz a RedHat-nek/IBM-nek?

Vásárolnak hivatalosan használt piacról. Már ha kidobták őket. Szerintem nem dobták ki, tehát most is van nekik. Azt ne mondd, hogy nincs az amerikai piacon egy számlaképes eladó, aki refurbished régi gépeket tud legálisan eladni garanciával.

Mennyi az a néhány? Egy, kettő öt?

2019-es adatok alapján a Microsoft nettó bevétele 39 milliárd dollár [1], a Red Hat-é 434 millió dollár [2]. A Microsoft 89x többet keresett a Red Hat-nál az előző évben. Ez egy közel százas nagyságrend.

Melyik az a már nem támogatott OS, amit a felhasználók ekkora hányada használ mind a mai napig?

Majd szépen leveszed a szemellenződ és utánanézel (StatCounter, NetMarketShare). Ami itt számít, az az, hogy a támogatás lejártakor (2020. január 14.) hányan használták a rendszert annak ellenére, hogy az alternatívák az átállásra rendelkezésre álltak. Jelenleg az Internetezők negyede használ még Windows 7-et, ami jól mutatja, hogy továbbra is igény van a használatára, a Microsoft mégse kezd ezzel semmit, csak hajszolja őket a csiligány, bloat, instabil, régi driverekkel inkompatíbilis rendszere felé.

"Közel százas" nagyságrendet írtam.

Harmadszori újraolvasásra talán már sikerülni fog. :)

De máskor amúgy elég annyit mondanod, hogy: Csardij vagyok, kötekedni jöttem. Nem kell erőlködnöd az általános iskolában tanított szövegértéssel. Biztos már régen volt és elfelejtetted.

"Vásárolnak hivatalosan használt piacról. Már ha kidobták őket. Szerintem nem dobták ki, tehát most is van nekik." - A RHEL5 2006-ban jött ki, és 2014-ben volt az utolsó release belőle, az "extended", support (ami induláskor is drága, és évente jelentősen növekvő árú szolgáltatás) valóban mostanság ért véget (2020.11.30), és nem véletlenül került annyiba per év. Ugyanis komplett infrastruktúrát kellett életben tartani 2006-ban standard hardverekből. De ennek ára, méghozzá igen magas ára van - nem véletlenül, hoszen egyre kisebb körnek kell "eltartania" a speciális igényt kiszolgáló eszközparkot és finanszíroznia az erre részben vagy teljesen(!) dedikált szakembereket.
 

"Jelenleg az Internetezők negyede használ még Windows 7-et, ami jól mutatja, hogy továbbra is igény van a használatára, a Microsoft mégse kezd ezzel semmit," - Tervezedd életciklusa végén befejezte a támogatást, ennyi. Lehetett tudni, hogy meddig lesz támogatott? Igen. Attól, hogy valaki tovább használja, mert "csak", attól még miért kéne támogatást nyújtani hozzá? Egy fizikai termékhez semnyújt a gyártója csillió év+1 napig gyártói szervízszolgáltatást és alkatrészellátást...

De téged, mint XP felhasználót miért bánt az, hogy az XP-hez képest bloat csilligány (satöbbi) Windows7-tel mi van...? Az XP-bőrbe hbújtatott 2k3-ad attól még nem lesz jobb meg támogatottabb, meg nem fog javítésokat és frissítéseket kapni még az ismert hibáira sem, merthogy az, amit a Microsoft kapott érte, az adott időtartamra fedezte a támogatás erőforrásigényét, és az már elmúlt. Arra meg, hogy egyedi támogatási megállpaodást köss a Microsofttal, arra kevés vagy - nem kicsit, hanem nagyon...

Ugyanis komplett infrastruktúrát kellett életben tartani 2006-ban standard hardverekből.

Vajon a 434 millió dollár hányadrészébe kerülne ezeket továbbra is fenntartani? Mert szerintem kevesebb, mint századrészébe. tehát egész számú százalékban sem lehetne kifejezni milliárdosék potenciális veszteségét rajta. Nem beszélve a Microsoft-ról, ahol meg kerekítési hiba lenne.

Tervezedd életciklusa végén befejezte a támogatást, ennyi.

Attól még, hogy a Microsoft önkényesen kitalált valamit, kizárólag a saját üzleti érdekeit figyelembe véve, az embereknek nem feltétlenül az lesz az igényük. Jelenleg többszáz millió embernek a Windows 7 további használata az igénye, a Microsoft pedig baszik lekövetni ezt, mint piaci igényt és baszik megfizethető támogatási opciót adni a magánfelhasználóknak, helyette inkább új számítógép vásárlásába és a régi kidobásába igyekszik hajszolni őket.

De téged, mint XP felhasználót miért bánt az, hogy az XP-hez képest bloat csilligány (satöbbi) Windows7-tel mi van...?

A Microsoft nagyvállalati arroganciájáról beszélgettünk, amire jó példa a Windows 7-hez való hasonlóan arrogáns hozzáállása, mint anno amit művelt az XP-felhasználókkal.

"Vajon a 434 millió dollár" - az nettó árbevétel, nem pedig nyereség, aminek a terhére a költségeket lehetne növelni. Sebaj, legalább megtudtuk, hogy a pénzügyi/gazdasági ismereteid kifejezetten stabilak. (Stabilan tartják a nulla közeli állapotot)
 

"Attól még, hogy a Microsoft önkényesen kitalált valamit, kizárólag a saját üzleti érdekeit figyelembe véve, az embereknek nem feltétlenül az lesz az igényük." - Minthogy pénzből él a Microsoft is, így teljesen természetes, hogy üzleti tervek alapján dolgoznak, és a termékek árát és a támogatási időablakot (amíg foglalkoznak az adott termékhez kapcoslódó problémákkal) az eladhatóság, a kapcsolódó költségek és az elvárt nyereség figyelembe vételével tervezik meg. Azzal, hogy nem támogatják, azzal csak annyi történik, hogy nincs rá támogatás, de ugyanúgy használhatja tovább bárki, mert a támogatás megszünése nem a használat tilalmát jelenti. Használhatod az XP-re maszkírozott 2k3-at? Igen. használhatom a régi XP-s meg W7-es virtuális gépemet a továbbiakban is? Igen.

"baszik megfizethető támogatási opciót adni a magánfelhasználóknak" - vett a home user egy marék gombért sok-sok évvel ezelőtt egy OS felhasználási jogosultságot. Azaz kifizette az OS életciklusának a végéig a támogatást - előre. Nem tovább, nem örökre, hanem egy korlátozott időszakra. Az, hogy ennek a meghosszabbítására pénzért sincs lehetőség, az üzleti döntés, üzletileg teljesen racionális nem fenntartani egy teljes infrastruktúrát és support területet olyasmire, amire döntően nincs fizetőképes kereslet. Nem, a "de csillióan használják" nem jelent fizetőképes keresletet. Aki fizetne érte, az fizet is - és OS-t vált, és máris kiesett ebből a körből. Aki meg nem vált, az ahogy az újabb OS-ért sem akar fizetni, az a régi további támogatásáért sem fizetne.

"a Microsoft pedig baszik lekövetni ezt, mint piaci igényt és baszik megfizethető támogatási opciót adni a magánfelhasználóknak, "

Értem, hogy a piaci igény az, hogy legyen megfizethető support extension (bár a többszáz millió [sic] jelentős része valószínűleg már az eredeti árát sem fizette k)i, csak ez olyan, hogy piaci igény nyilván volna magánhelikopterre is egy 20 éves szuziki áráért, aztán mégse lesz. Tudod, mert irreális.

Zeller.. azért abban talán egyet tudunk érteni hogy akik CentOS8 -ra átálltak.. azok bizony úgy álltak át hogy akkor 10+ év support. Ehhez képest húzták ki most alóluk a talajt.... Vagy nem ?

CentOS6, 7 maradt változatlan. Hirtelen a Centos8 alól kellett kirántani mindent is.

Ez azért így elég gáz :)

Hogy a Centos8Stream életciklusa milyen lesz, illetve hogyan lesz supportálva, az jó kérdés. Az viszont elgondolkodtató, hogy az, aki most azt mondja, hogy a CentOS-ból RHEL testing-et csináltak, az eddig mondta-e azt, hogy a RHEL az a CentOS testing?

Én még nem álltam át sehol CentOS8-ra, csak tesztgépem volt, illetve terveztem, hogy az új projektek alá esetleg CentOS8 is kerülhetne. Mivel a CentOS7 még jó sokáig támogatott, így nem volt/nincs kényszer arra, hogy váltáson törjem a fejem, minden setre én kivárok, és ezt tudom javasolni annak is, aki jelenleg CentOS8-on van, mert bár bejelentették, és eldönttetett, hogy így lesz, az örödg a részletekben lakozik - ha és amennyiben a CentOS-ban a RHEL8-cal azonos csomagok lesznek _hamarabb_, akkor semmi gondot nem jelent szeritnem.

Na, ezt nem is tudtam, hogy ennyire systemd-párti vagy te is :D Szerintem backportolni kéne Windowsra is, hogy a nyílászárókos emberkék se maradjanak ki a jóból. Sőt, mindjárt Poettering átszerződhetne a Microsofthoz, ott többet is keresne, meg még több felhasználót keseríthetne, mindenki jól járna a cserével, főleg a linuxosok.

Ami meg a Windowst illeti, félig értek egyet. Az önmagában nem volt baj, hogy lejárt az XP meg a Win7 támogatása. Az viszont valóban gond, amit írsz, hogy ami helyettük lett, az sok szempontból nem hogy jobb, hanem rosszabb, és csak azért lett váltás, hogy lehúzzanak egy plusz bőrt, ehelyett meg egy beváltabb rendszert kukáztak, mert csak. Nekem nincs bajom, ha új verziók vannak, meg migrálni kell, de tényleg csak azért váltani, hogy elmondhassuk, hogy x évente volt váltás, meg ne legyen unalmas, hogy ugyanaz a verzió megy, annak nem sok értelme van, ha nincs fejlődés mögötte. Mert ha a Win10-ben lenne egy normálisabb, továbbfejlesztett fájlrendszer (nem erre a ReFS-es szutyokra gondolok), jobb lenne a memóriakezelése, vagy akármije, modulárisabb lenne, akkor azt mondom, hogy váltsanak. De a Win8.x és 10 sok mindenben nem hogy előrelépést nem hoz, de visszafejlődés. Erre pedig még az se ok, hogy pénzt akartak kihúzni az emberekből, mert akkor lehetett volna csinálni, hogy 5-10 év lejártával újra megvetetni, újralicencelni a meglévő rendszert, új bőrt lehúzni így is le lehet mindenkiről, de legalább a váltás miatt nem szív senki, mert ugyan újabb sarc árán, de a jól megszokott rendszerét kapja vissza.

Kb. ugyanez a CentOS története. Rolling lett, és bár rollingpárti vagyok, de RHEL-vonalon rollingból ott volt már a Fedora, jó az félrolling, de akkor is. Ez a megszüntetés arra volt jó, hogy a fizetős megoldás felé tereljenek mindenkit, és nem a fejlődés része. Így meg csak szemét módon elvették az esélyt olyanoktól, akiknek megfelelt az addigi rendszer, és szívesen használták, megszokták. Most egy kevés emberke átnyergel RHEL Streamre, a többi meg disztrót vált, ami senkinek nem jó, mert más disztróvonalakra váltanak, nem RHEL alapra. Szóval pénzt nem nagyon húztak ki senkiből, inkább csak magukat lőtték lábon. Valami öltönyös-nyakkendős trendokos menedzser ezt is kitalálta jól egy értekezleten, azt hitte, hogy feltalálta a kereket.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

“Ez a megszüntetés arra volt jó, hogy a fizetős megoldás felé tereljenek mindenkit, és nem a fejlődés része. Így meg csak szemét módon elvették az esélyt olyanoktól, akiknek megfelelt az addigi rendszer, és szívesen használták, megszokták. Most egy kevés emberke átnyergel RHEL Streamre, a többi meg disztrót vált, ami senkinek nem jó, mert más disztróvonalakra váltanak, nem RHEL alapra. Szóval pénzt nem nagyon húztak ki senkiből, inkább csak magukat lőtték lábon. Valami öltönyös-nyakkendős trendokos menedzser ezt is kitalálta jól egy értekezleten, azt hitte, hogy feltalálta a kereket.”

Kb. ahogy irod is, legfeljebb a szandek lehetett meg, szerintem borzasztoan keves embert sikerul ezzel fizetosse tenni, meg marginalisnak sem mernem hivni, szepen tonkretesznek igy egy kozosseget, a,inek tagjai igy kenytelenek mas (legtobb esetben “rosszabb”) disztrora valtani.

A felhasználók saját maguk húzzák ki a lábuk alól a talajt, mikor beragadnak egy adott cég egy adott termékének, egy adott verziójára, és onnan nem tudnak kimozdulni, közben meg saját maguknak állítanak korlátot. Semmi alá nem kell 8 mag meg 64 giga RAM, linuxok általában elég sovány hardverrel beérik, a legbloatabbak is jól futnak egy olyan 15 éves gépen is, mint neked van, 2 mag, 4 giga RAM, de azon akár még egy Win10 is elfutkos, lehet kicsit komótosabban, de azért nem használhatatlanul, annyi a titka, hogy 10 alá kell egy SSD, nem baj, ha csak valami olcsó 5-6 ezer forintos 120 gigás csortrogány, csak ne HDD legyen alatta, akkor elfutkos.

Plusz ma már nem az OS gépigénye a meghatározó, hanem a böngészők és a web bloatsága, ez rója a régi gépekre a legnagyobb terhet, nem a modern OS-ek. Persze utóbbiak is bloatosodnak, de nem olyan ütemben, hogy akár egy sok éves gép is ne legyen hozzájuk elég.

A frissítések valóban bugzanak mostanában több platformon is, de azért még működőképesen lehet tartani. Nyilván nehezebb, mint régen, a világ meg az IT bonyolódik. Értem én, régi szép idők, C64 gombnyomásra indult ROM-ból, nem kellett hozzá frissítés, azonnal tudtál rajta BASIC-ezni, játszani, de azta más lett a világ, mások lettek az igények.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

" Semmi alá nem kell 8 mag meg 64 giga RAM," - Mondd, láttál már te mondjuk komolyabb adatbázist? Amit mondjuk néhányezer szálom terhel pár webes alkalmazásszerver-fürt? De ha OLAP-ot nézek, ott sem hátrány, ha bőségesen van memória meg CPU-mag a gépben... És még az in-memory DB-ket (pl. SAP HANA) nem is említettem...

Semmi alá nem kell 8 mag meg 64 giga RAM, linuxok általában elég sovány hardverrel beérik, a legbloatabbak is jól futnak egy olyan 15 éves gépen is

Egyrészt, az amerikai multiknál dolgozó fejlesztők ilyen gépeket kapnak, ráadásul 2-3 évente lecserélik őket. Mert a hardver olcsó™.

Nyilván, nem konkrétan 8 darab mag van benne és nem konkrétan 64 giga RAM, hanem a mai átlag konfigokhoz képest mindig annyival erősebb a konfig, amennyivel egy mostaninál lenne erősebb az említett.

Innentől kezdve a fejlesztőnek fogalma nincs arról, ha bloat kódot ír, hiszen az ő csúcsgépén az is gyorsan megy. Csakhogy, mivel semmi alá nem kell 8 mag, meg 64 giga RAM, a kódot másnap nem ilyen konfigokon fogják futtatni, ahol bloat lesz. Vagy fájdalmas bloat, amit a user is észrevesz és két lassulgatás között nem győzi hallgatni, ahogy süvít a ventilátor a laptopjában. Vagy nem fájdalmas bloat lesz, amit a user nem igazán vesz észre, de a gépe sokszorta több energiát pocsékol el, mint amire szükség lett volna egy hatékonyabb implementációnál.

A fejlesztőket elkényelmesítik az újabbnál újabb konfigokkal, hiszen sokat kell buildelni, ahhoz meg kell™ az erőforrás, gyakorlatilag azt lehetetlenítik el, hogy a bloat még fejlesztési időben kiessen és a fejlesztő pofája is égjen a demókon, hogy milyen undorítóan lassú megoldást csinált.

Végül, ezekből a bloat implementációkból egész framework-ök és ökoszisztémák állnak össze, amikben már csak relatíve nagy (bár multiék által könnyedén finanszírozható) ráfordítással lehetne optimális megoldást csinálni, ami elég nagy ahhoz, hogy menedzserék, befektetőék leszavazzák, majd a felhasználók vesznek új gépet.

ez biztos igaz a desktop alkalmazásokra - de én a munkám során 90%-ban szerver alkalmazásokkal foglalkozom - tehát a " .. Semmi alá nem kell... "  - azt pontosítanám, hogy milyen alkalmazásra gondoltál..

24 mag 256GB RAM előfordul - na jó nem mind 320 gép ekkora :-)

Nálam is csak a DB-szerverek ilyen erőgépek (jó, a vmware hostok sem kicsik...), de oda kell is a sok processzor, mert igen szigorú időlimiteknek kell megfelelni a komplett (adat be/megcsócsál/válaszok a megfelelő helyekre vissza) folyamatoknak. Most épp azon törpölök, hogy a mentést, illetve amentési területet hogyan szervezzem át, hogy kevesebb terhelést okozzon a DB-nek - két sire, mindenütt 2-2 node, és az egyedi mentési területeket gondoltam valami értelmes osztott területté összefűzni, site/host kiesésre felkészítve az egészet...

"Mert a hardver olcsó" - Igen bammeg, a hadverre elköltött +100$ bőven bejön azon, hogy a fejlesztés során nem 10-15 percig szöszmötöl a fejlesztő gépe valamivel, hanem csak 2-3 percig.  Az idő pénz, a fejlesztő munkaideje meg sokba kerül. Az, hogy a te környezetedben ezeréves ócska sz@rokon vergődik mindenki, az a ti bajotok, egy fejlesztéssel foglalkozó cégnél az a target, hogy a fejlesztés során a holtidő minél kevesebb legyen, minél kényelmesebben lehessen dolgozni. Tudjuk, neked fáj ez, meg az, hogy alád senki nem tol ilyen hardvert, de a hozzáállásod miatt nem is csoda/nem is baj.

hogy a fejlesztés során nem 10-15 percig szöszmötöl a fejlesztő gépe valamivel, hanem csak 2-3 percig

A felhasználó és a beszennyezett környezet meg majd megfizeti. A fejlesztő bére amúgy is tekinthető fix költségnek. Ráadásul nem amortizálódik, mint egy megvásárolt eszköz. A fejlesztő pedig akkor is ott fog dolgozni, amikor az erőmű helyett Raspberry PI-n egy hónap helyett másfél hónapig fejlesztett projekt véget ér. Tehát nem spóroltál semmit, csak nem tetted át a virtuális milliókat egyik skatulyából a másik skatulyába.

Ha bloat-ra játszol, minden felhasználónak, akik az adott szoftvert használni fogják pluszköltséget csinálsz, mert előbb-utóbb kénytelenek lekövetni az eszközvásárlásod, ha azt szeretnék, hogy náluk is normális sebességgel menjen a bloatware-ed. Ha erre nem hajlandóak, akkor időt (lassulgatás) és energiát (CPU) kell pazarolniuk a bloatware-ed használatára, ami megint csak sokkal több lesz, mint amit te megspóroltál. Bizonyos népszerű szoftverek esetében pedig ez több százmillió munkaállomást jelent, aminek a többletfogyasztása és a lecserélése is számottevő gigawattórákban és CO2-kibocsátásban, hiszen nyilván több ezer kilométerről kell odapöfögtetni a legtöbb helyre, mert úgy éri™ meg™.

Itt is igaz az örök mondás, hogy amikor valami sokkal olcsóbb, akkor valaki valamit nem fizetett meg. Ahogy a hardvereknél a laza törvényeknek köszönhető környezetterhelés és a munkások nyugati színvonalú bérét felejtik el multiék megfizetni, te a környezetszennyezést és a felhasználóknak okozott energia- és időpazarlást nem fizeted meg, amikor babzsákfejlesztőék segge alá tolsz egy csiligépet.

A 21. századi gondolkodáshoz pedig nem csak az tartozik hozzá, hogy van 5G-s okostelefonod, hanem a társadalmi felelősségvállalás is. Az nem oké, hogy te spórolsz 1000 dollárt azon a plusz két héten, ami a Raspberry PI-n való fejlesztéshez kéne, a százmillió felhasználódnak (tehát gyakorlatilag a társadalomnak) összesen meg összesen milliárd dolláros pluszköltségeket okozol. Akkor sem oké, ha az ügyfeleid még így is téged választanak, mert mondjuk technológiailag nincs a tiedhez fogható alternatíva a piacon. Ennyi erővel nyugodtan lehet ciánt engedni a Tiszába, ha a törvény nem tiltja, mert olcsóbb, mint fizetni a veszélyeshulladék-kezelésért, akinek nem tetszik, az meg horgásszon máshonnan.

" A fejlesztő pedig akkor is ott fog dolgozni, amikor az erőmű helyett Raspberry PI-n egy hónap helyett másfél hónapig fejlesztett projekt véget ér. " Lóf..szt. Ha az ideje döntő részében a f0s hardverre kell várnia, akkor veszi a kalapját, és odébb fog állni. És nem, a megrendelő nem fog adott fejlesztésért másfélszer annyit fizetni, mert nem hülye, hogy elhiggye, hogy másfélszer annyi időbe kerül adott dfolgot megvalósítani.

"Az nem oké, hogy te spórolsz 1000 dollárt azon a plusz két héten, ami a Raspberry PI-n való fejlesztéshez kéne," - gondolom, neked a munka velejárója az, hogy az idő minimum 70, de inkább 80%-ában arra vársz, hogy a gép befejezze a munkát, a maradékban meg ténylegesen kódolsz. Na ez lehet, hogy valahol elfogadható, de ott, ahol "pénzből élnek", ott nem. Ugyanis ez azt jelenti, hogy a dolgozó idejének döntő része "üresjárat", nulla produktum előállítása... Nem, nem lehet közben papír-ceruza-gondolkódósan folytatni a munkát, aztán amikor kész, akkor újra megcsinálni néhány lépést, aztán build+automatizált teszt (ami csak órák kérdése, hogy befejeződjön...)... Ja, és persze a raspi szép gadget, de érdemi picit is adatintenzív tesztelésre alkalmatlan.
 

Én is így vagyok vele, eddig ezért is volt CentOS. De annyira populáris lett az Ubuntu, hogy mér észrevehető tényező. Pláne ha a "szerver" is úgy néz ki, hogy nosza itt egy VM (valahol alatta hárommal Raid is van, de nem kell hogy érdekeljen), amire egy olyan image-et húzz fel, amit gyorsan tudunk multiplikálni és terhelés elosztani.

Csak a linken talalhato ket hivatkozasbol szemezgetve:

"This is where we see CentOS Stream fitting in. It provides a platform for rapid innovation at the community level but with a stable enough base to understand production dynamics."
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability. To make CentOS Stream the primary innovation hub for the RHEL ecosystem"
"Red Hat will also be moving all of our internal projects to CentOS Stream, so we’ll be able to share best practices and strategies with the broader community"
"We encourage all of our partners and developers to not just engage in CentOS Stream, but to start building their own branches and use this innovation hub to test solutions to their own specific challenges."
"CentOS Stream will be getting fixes and features ahead of RHEL. Generally speaking, we expect CentOS Stream to have fewer bugs and more runtime features than RHEL until those packages make it into the RHEL release."
"Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project."
"CentOS Stream is focused on the next RHEL minor release. This means we are improving and influencing the shipping releases of RHEL. Fedora ELN is a testing area for changes that may occur in the next major release of RHEL."

Ebbol nekem kicsit olyan erzesem van mintha csinalni akarnanak centos stream neven egy fedora-ng vagy hasonlot, hogy foverzion beluli de azert valtozasokat akarjak centos stream-ben tesztelni.
Ami emiatt nem lesz olyan stabil, gyakrabban frissul es eselyes hogy akik eddig ugy hasznaltak centost hogy license nelkuli rhel, de valami alkalmazas/hw miatt kellett mert centos tamogatott volt (ahogy persze rhel is csak az fizetos) annak lehet ezutan azt fogjak mondani hogy centos stream mar nem tartozik bele a tamogatott rendszerek soraba.

Már három hivatkozás van benne, abból idézve:

"We believe CentOS Stream truly is the future of enterprise Linux"

"Red Hat will also be moving all of our internal projects to CentOS Stream"

Ez akkor lesz igaz amit ír ha az RHEL9 is ilyen lesz. Mert az egyrészről örömteli, hogy 2024/2029-ig van support de ez azt is jelenti, hogy a 4.18-as kernel is addig marad (oké, hogy visszaportolnak sokmindent, de nem mindent) és az összes alapkomponens is (pl. libc). Egyébként volt már, hogy feladták az ABI kompatibilitást, az egyik pont kiadásban ugrottak egy nagyot a systemd-vel mert egyszerűen nem lehetett volna (vagy értelme nem lett volna) mindent visszaportolni. Ez probléma ha valamiből 2025-ben kéne újabb verzió, de akkor már az akkori forráskód sem fog lefordulni. Valamit valamiért, de talán megjelent igényként a nagy ügyfelek felől, hogy jó lenne ha úgy lenne LTS és ABI kompatibilis ha közben azért haladna is a korral a cucc. Ezt managerek simán képesek így megálmodni, hogy ez jó lenne, tehát legyen így. :) Ha a stream célja valóban az hogy ezt a problémát kezelni próbálja valahogy és a redhat tényleg ebben látja a jövőt, akkor ennek az RHEL9-ben is alapból így kell majd működnie. Meglátjuk.

Lehet, hogy jó lesz hosszú távon. A CentOS csomagjai rettenetesen elavulnak évek alatt, de számunkra ez is az előnye. Vagyis az, hogy a futtatott hasznos alkalmazás fut 10 évig anélkül, hoy bolygatni kéne, elég csak a security update-ket telepíteni.

Ami a hátránya, hogy a distupgrade nem létezik gyakorlatban, mindenképpen kell mellette másik distrot is használni ahol újabb csomagok vannak, de attól még vannak a Red Hat-ben is bajok néha 1-1 update után.

Centos Stream, OpenSuse, Ubuntu amik támogatással rendelkező distrok lehetnek a jövőben?

Az, hogy a stable disztróból egy testing/unstable státuszba rakják, azaz nem Fedora - RHEL - CentOS hanem Fedora - CentOS - RHEL lesz a "sorrend" gyakorlatilag a CentOS lesz a RHEL "testing" vonala. Persze lehet jó is, ha az ember "ésszel" frissít, azaz nem a CentOS current csomagokat használja, hanem azokat, amik már átcsorogtak a RHEL-be is.

A nincs dist-upgrade ott hátrány, ahol csillió évig (+1 nap) azonos egy darab hardveren fut minden is. De gondoljunk abba bele, hogy 5-10 év után azért a vasat is szokás cserélni, úgyhogy a support időszak végére nem csak az OS-lesz csereérett, plusz egy 5-10 évig üzemelő rendszer sok olyan dolgot, (örökséget meg ökörséget) cipel, amitől egy clean install-lal jobb megszabadulni. (Diszkterület felosztása: partíció vs. lvm, fájlrendszer ext* vs bármi más, legacy vs uefi boot... )

Én a támogatással bíró disztrók közé igen előkelő helyre raknám még az Oracle Linuxát is - datacenterben elég barátinak tűnik az árazása (ellentétben a Canonical per VM áraival...)

Szerkesztve: 2020. 12. 09., sze - 11:42

Ingyen RH megy a /dev/null-ba, azaz mar egy Centent sem er a CentOS.

Ez meg ingyenes : Oracle Linux : http://yum.oracle.com/ mar allok is neki tesztelni.

Kiraly!

ez nem az volt, ami miatt még a nagy RH-CentOS összeborulás előtt egyszer egy darabig az RH az összes változását egy baszott nagy diffben adta ki, hogy emígyen "segítse" az oracle pofátlan más... izé, átemelési kisérleteit? Mert akkor upstream nélkül azzal is lesz baj.

"az oracle pofátlan más... izé, átemelési kisérleteit" - a RHEL döntően GPL-es forrásból építkezik. AMi meg nem, azt jól le lehet határolni/ki lehet piszkálni a forrásból, ahogy azta CentOS (meg az Oracle Linux) készítői is csinálják. Az Oracle Linux esetén egy plusz van, az a saját kernel. Mondjuk én CentOS alatt elrepo-s kernelt használtam desktop-on - az tudta a notebook-on a három (2 külső meg a belső) monitoros módját :-)

Persze, hogy abból építkezik, csak nagyon nem mindegy, hogy a saját kernelbe az RHtól át lehet emelni egyesével a változásokat, vagy kapnak egy 28 megás diffet, hogy "ezt változtattuk meg a 4.9.863-as kernelben, amit rommá patcheltünk. Megteheti az oracle, hogy ezeket a GPL kódokat saját maga is pénzért adott disztróban adja, supportal? Persze. (Én ugyan személy szerint pofátlanságnak tartom, de persze). Megteheti az RH, hogy erre válaszul a GPL betűjének megfelelően ad egy nagy patchet, a metadata nélkül? Persze. (Én személy szerint kibaszásnak tartom a többiekkel, de persze). 

Amire utalni akartam az az, hogy eléggé úgy tűnt, hogy a stabil oracle linux (egyébként nem unbreakable volt, vagy mi a tök?) nem annyira az oracle engineering érdeme, szóval ha az RH elzárja az értelmes csapot, akkor az oracle linux mint alternatíva sem nagyon tud maradni így. 

Aztán persze simán lehet, hogy meg lehet majd eddig is csinálni, csak ők a centosnál nem teszik bele az effortot ezentúl, bár elég magas labda lenne. Mondjuk nem is nagyon értem, mit akar itt az RH elérni? A vaskalapos árazási stratégia miatt imho egyszer már bebukták a fél virtualizált és a kb teljes cloudos landscapet, és akkor most megint meglépnek egy ilyet.

Minden vissza debian-ra. (Amúgy is jobban szerettem azt mindig is)

Na de a forráskódokat ki kell adnia az RHEL-nek. Csak lesz már egy csapat aki újra elkezdi buildeni. Ha más nem akkor újraindul a scientificlinux. :) Addig is megnézzük mit kínál az Oracle RHEL rebuild terén.

Nem, en csak elmeletben okoskodom, hogy vegre 2024 a linux desktop eve legyen. Nekem van tervem, meg ha nem is tudom megcsinalni.

Te kerlek mondj jobbat, ha ennyi disztro van, hogy tud az egyik kiemelkedni, versenyezni a nagyokkal. Sehogy most.

A Nemo nyomaban volt egy resz, hogy csapdaba estek, majd megszervezte a kis hal, hogy mindenki azonos iranyba usszon, es kiszabadultak a halobol.

Most nincs halo, de egyseges irany sem. En  csak erre irom. 

Mennyi elpazarolt ido ennyi fele linux disztrot letrehozni, telepitot irni, karban tartani. Mindenki azt csinal az idejevel amit akar, jo pelda a Reactos, vagy par kis hobbi disztro, csak ha nem ezt, hanem egy nagy disztroba segitenenek, hasznosabb lenne, ha az lenne a cel, hogy legyen egy kiforrott, meg jobb linux.

Nezd a hardver gyartokat: melyik linux disztrot tamogassak? Biztos erted, csak nem ertesz egyet, ami nem baj.

Sokat gondolkodtam ezen én is, de a dolog ott bukik meg, hogy nem tudod egzaktul definiálni, mi a „legjobb”. Sőt még ennél kevesebbet se, hogy mi az ami „jobb”.

Senki se képes rá.

Van akinek a systemd „jobb”. NEKEM NEM.

Van akinek a pulseaudio „jobb”. Én: köszi de nekem a sima ALSA a „jobb”.

És akkor még nem is beszéltem az R=1 sőt R=0 usereket leginkább izgató kérdésekről:

—Legyen a disztróban DE, vagy csak WM? És melyik DE, melyik WM? __NEKEM__ a „legjobb” a DWM, de vélelmezem e nézetemmel bár nem vagyok egyedül, de akkor is egy parányi kisebbség gondolja csak így.

—Milyen legyen a csomagkezelő? Sőt, LEGYEN-E EGYÁLTALÁN?!

—Forrásalapú vagy bináris disztró legyen?

—Rolling release, vagy ne? Ha nem, milyen időközönként jöjjön új release?

—Legyen-e a disztróban alapból root? Legyen-e neki alapból engedélyezve a grafikus felületen való bejelentkezés? Egyáltalán, része legyen-e a grafikus felület az alaptelepítésnek?

—Főként Qt vagy GTK alapú programokra építkezzék? (Ha mindkettőre, az megintcsak az erőforrások pazarlása ugye).

—Lilo, Grub1 vagy Grub2 legyen a bootloader?

És még a legközönségesebb felhasználói programok esetén is kismillió variáció lehet, hogy azokat milyen „kapcsolókkal” fordítják, milyen „feature”-kkel. A gentoosok sokat tudnának mesélni erről... de azok is akik LFS-t használnak...

És még tengernyi kérdés, és mindenkinek más és más válasz a megfelelő, a „legjobb”.

Szóval az ügy reménytelen. Szerintem.

Ez a sok disztro nagy pazarlas. [...] Tul sok az elpazarolt eroforras.

Papíron jól mutat, hogy egyesítsük erőinket, és akkor milyen jó lesz, de a valóság az, hogy azért forkolgatnak meg módosítgatnak mindig mindent, mert valaki valamit másként szeretne. Egy systemd-t nem kedvelő Devuan-karbantartó aligha fog elmenni Debiant karbantartani, mert nem fogja egy systemd-s disztróra pazarolni az idejét. Ahogy Poettering és társai sem fogják kukába dobni a systemd-t és nem fognak elmenni mondjuk sysvinitet vagy runitet fejleszteni, hiszen ők a systemd-re esküsznek.

Egyébként is, a sokféleség jó is lehet. (#diversityinclusionsunshinerainbowunicorns =P )

Ertem. De a hosszu tavu cel miatt engedni kene valakinek. Nem tudok jobb peldat mint a Windows 10 es az Macos. Annak sincs most sok fo valtozata. Van Win10, de az alap az kozos, meg Home, Pro, Ent, de kozos az alap. Nincs 2 fele Windows 10 ablakkezelo.

Lenne systemd az alap, a tobbi addon.

Stb.

Fajdalmas lenne de hasznos.

Macos jobb pelda, mint a Windows 10.

Fentebb irtam, hogy ha rajtam kivul mas is latna a tavoli celt, akkor nagyot lehetne lepni.

Belegondoltam, hogy ha az osszes linux disztro osszefogna, ami free es nem ceg fejleszti, az lehetne kimagasloan a legnagyobb, hogy a ceges fejlesztok is inkabb arra irnanak appokat, nem sajat disztrot kezelnenek.

Irhattam volna Bsdt is, abbol is jo sok van.

Amit irtam, az utopisztikus, hiszen nagyon sok ember inkabb arra buszke, hogy o a 456. top linux disztro kitalaloja, amiben valami mas, mint a tobbiben, aztan veget er a fellangolas, meg csak huszan hasznaltak, es vege. Ok, szabad vilagban elunk, nem kenyszer, amit irtam.

 

Hogy tiszta legyen: minden tiszteletem azoke, akik szabadidejukben támogatnak barmilyen szabad szoftvert, megosztanak javitasokat, kitalalnak valamit, stb. Csak egy fokkal jobb lenne, ha nekem tok mindegy merre, csak egy fele haladna ez.

Belegondoltam, hogy ha az osszes linux disztro osszefogna, ami free es nem ceg fejleszti, az lehetne kimagasloan a legnagyobb, hogy a ceges fejlesztok is inkabb arra irnanak appokat, nem sajat disztrot kezelnenek.

Irhattam volna Bsdt is, abbol is jo sok van.

magyarul ha Mindenki az influencer -nek kedves OS megalkotásán dolgozna azzal elégedett lennél? :)

Sarkítottam, de értsd jól: minden problémát lehet más és más oldalakról és szempontok alapján közelíteni. Meg fogsz lepődni, de a különböző nagyobb distrib-k között szokott lenni 1-1 olyan dolog ami csak rájuk jellemző, de pont emiatt érdekesek annak akinek az színárnyalat tetszik.

Képzeld el, hogy a lakhatási problémákra keresik a választ és a remek mérnökök kitalálják egy csomó probléma forrását (meg néhányra időleges megoldást, újabbak előkészítését): a panelházat.

Azért lenne aki szomorú lenne, ha kizárólag "az egy legjobbb panel" megalkotásán kellene mindenkinek munkálkodnia. Pedig még ott is belefért, hogy csináltak ilyen-olyan-amolyan alvariánsokat :).

Ha lenne egyetlen NAGY „linux”, azaz disztró, akkor az tényleg hozhatna egy rövid ideig bizonyos előnyöket, oké, de igen hamar eljönne az a pillanat amikor épp emiatt sorvadna el: tudniillik nem lenne versenytársa, s így „jól van az úgy is” alapon fejlesztenének bele, mármint azok, akik egyáltalán foglalkoznának a fejlesztésével (ingyen). És eleve sok fejlesztő úgyis átmenne valami „szabadabb” platformra. Például a BSD-hez, és akkor abból lenne csillió újabb variáns. Vagy, én például akkor nem Linux hanem Minix alá fejleszteném a programnyelvemet ahogy magamat ismerem, egyszerűen mert azt használnám, arra térnék át, amennyiben úgy érezném, ott nagyobb a szabadságom. És tuti úgy érezném, ha Linux alatt rám lenne erőltetve a systemd meg a többi szar használata.

Szóval mondom, ezt felejtsd el. Az ötleted nemcsak megvalósíthatatlan, de még akkor se lenne értelme (hosszú távon legalábbis) ha ki lehetne vitelezni.

A Red Hat pedig már lassan végig is ér ezen az úton, ha a desktop Linuxot nézzük (gondolom azt nézzük, mivel a Windows 10 eredetileg desktop OS), systemd-vel, pulseaudio-val, GTK3-mal. Ami szomorúbb, hogy a Linux mögé beállt Linux-on élősködő multikat feltétel és kririka nélkül követő, befolyásosabb open-source projektgazdák is átveszik Poettering mesterműveit és nyomják le százezrek torkán, akiknek a többsége azért ment Linux-ra, mert elege lett a Windows egyre inkább lebutított, csiligány, fehérpapír-tablet-idealista kezelőfelületéből, a "stabilként" kiadott instabil szar béta minőségéből és az egyre nagyobb bloat mivoltából.

A közösség ettől bizony még úgy érezte, hogy nem vállalja be a kockázatot, hogy igaz a fud, vagy szeretett volna fejlődni (suprise suprise, a debian közösség tagjainak jó része valószínűleg nem azért csinálja, hogy jól supportálja ugyanazt 120+1 évig), és ezért szépen a saját szakállukra úgy döntöttek, hogy nekik ez így jó, legyen ez a default. Megjegyzem, a bolygó egyik leginkább működő valódi demokratikus közösségében.

Ja, és egyébként úgy is döntöttek, hogy nem ér annak a lábán taposni, aki meg akarja oldani, hogy menjen mással is, szóval a lehetőség nyitva állt, csak más farkával láthatólag sokkal könnyebb verni a csalánt, mint a sajátunkkal.

Ha tényleg így lenne, akkor opcionálissá, vagy legalább hivatalosan támogatottan leirthatóvá tették volna a systemd-t és nem kellett volna kiszakadnia a közösségből a Devuan-fejlesztőknek.

Ennyit a demokráciáról, ami döntési szinten valójában korporatokrácia volt.

Miért, a Devuan fejlesztők opcionálissá tették a systemd-t?

Nem. De debianra is visszarakható a sysvinit. Kérdés szerveren nem érint-e olyan alkalmazást, ami ettől nem vagy rendellenesen működne.

MXLinuxon választható, de ugye az nem szerverre való, és ott sem oldották meg úgy a systemd mentesítést, mint devuannál.

Az egyetlen disztró amin választhatóan elérhető a systemd és egy jópár initrendszer is, az a gentoo és származékai. De az meg nem produktív környezetbe való a nagy szakemberek szerint.

> Ha tényleg így lenne, akkor opcionálissá, vagy legalább hivatalosan támogatottan leirthatóvá tették volna a systemd-t és nem kellett volna kiszakadnia a közösségből a Devuan-fejlesztőknek.

Nem kellett nekik. Csinálhatták volna a debianan is, csak akkor arra is figyelni kell, hogy nem törik el a systemd-t sem.

> Ennyit a demokráciáról, ami döntési szinten valójában korporatokrácia volt.

A debian ezeket a döntéseket minden debian fejlesztő szavazatával hozza meg. Hosszú, nyilvános vitával előtte. A konkrét választási opciók hosszas egyeztetésével előtte. Ráadásul egy súlyozott preferenciasorrendes szavazással, ami a szokásos fekete-fehér-igen-nem játéknál lényegesen nagyobb eséllyel jut a még mindenkinek elfogadható kompromisszumra.

Szóval de, az attól még demokrácia, hogy neked nem tetszik az eredménye. (Éppen ettől demokrácia). Hálistennek ez ott kb senkit nem érdekel, mert abban a demokráciában viszont csak annak van belepoff, aki csinál is valami.

Nem igy latom. Leirtam mit lehetne elerni. Nem szeretem a systemdt hasznalni,de ez van, tanulom. En ebben nem leptem volna elore, bevallom nem talalkoztam olyannal, amihez systemd kell es elotte nem lehetett megoldani.

 

Tolem a nagy linux lehetne systemd nelkuli, nem en akarnam eldonteni.

Engedj te, baszki, használj te systemd MENTES disztrót! Nekem eszem ágában sincs átállni arra a bloatware szörnyetegre. Ember, én még a Grub2-vel is alig tudok együttélni, a legkomoilyabban az a gondolat kísért hogy a következő LFS-embe Grub1 lesz visszatéve. A faszomnak sincs kedve még systemd-vel is kínlódni.

Ez lesujto, szamomra a CentOS/RedHat a Linux..nem tudom mire valtok rola, ha kifut a 7-es tamogatasi ideje. :(

Gregory Kurtzer says:

December 8, 2020 at 4:27 pm

I am considering creating another rebuild of RHEL and may even be able to hire some people for this effort. If you are interested in helping, please join the HPCng slack (link on the website hpcng.org).

Greg
(original founder of CentOS)

 

Várjuk ki a végét, addig sok víz fog lefolyni a Dunán.

Mi lesz a centosre epulo cuccokkal, mint az xcp-ng?

Akadj már le erről a "túl sok disztró van, mindenkinek  egyet kellene tolni" dumával, mit zavar ez téged? Többen leírták, hogy a többség ezt saját kedvére csinálja, nem fognak beállni egy dolog mögé, már csak elvből sem. Oka van a rengeteg disztrónak, majd az evolúció megoldja.

Szerkesztve: 2020. 12. 09., sze - 13:30

If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.

Egy mondatban a lényeg. A CentOS a Red Hat profitérdekében kinyírja a stabil ágát és egy éven belül kísérleti nyulat csinál a CentOS 8-at preferálókból, 2024. június 30. (vagyis a CentOS 7 EOL-ja) után pedig a teljes felhasználóközönségéből. Ezzel nem csak az ingyen teszteltetés szívességét teszi meg a Red Hat-nak, hanem a stabilitást továbbra is preferálókat hajszolja multiék felé.

Ide pedig jöhetnek az "open source, te is bármikor forkolhatsz RHEL-t" típusú, szélsőségesen idealista hozzászólások. ↓

Oracle Linuxot ez vajon érinti majd? OL8nak is ugye 2029...vagy...most akkor majd az is 2021 dec 31?

Mondjuk az sem teljesen tiszta, az OL8 esetében, hogy akkor most fizetni kell érte vagy sem.

Egyik helyen (oralce oldalán) azt írják, hogy free and open source.

De persze ha rákeresek hogy mennyi az a free(az oralce oldalán), akkor azért röpködnek a 100-200, meg akár 1000 dollárok is.

 

Nyilván ha kell support, akkor kiköhögöm.

De ha csak fogom telepítem és használom boldogan, vajon eljön-e majd értem Oracle Bá' egy kis nyugdíj kiegészítésért?

Szerk: ( Természetesen céges környezetben )

Szerkesztve: 2020. 12. 09., sze - 17:33

De örülök hogy Debian-t választottam régen a VPS-eknek és nem CentOS-t. Igaz dist upgradekor mindig van valami szívás velük, de néhány óra alatt általában megoldható.

Sokkal életszerűbb, mint egy marketingesek vagy SJW-k által megalkotott, korporatokrata lózung vagy mozaikszó.

Ebben legalább egyedi és kreativitás van mögötte. Jól hangzik, és hordozza az alapító és barátnője nevét.

...... Ubuntu (máig felfoghatatlan, hogy lehetett így elnevezni egy főként nem Afrikában használt operációs rendszert)

...... Linux Mint (elnevezhették volna bármelyik fűszernövényről)

...... SuSE (a sárkány, hűdekomoly, kibaszott enterprájsz™)

Ezeknél már csak az UHU Linux volt rosszabb, ahol a .deb csomagok kiterjesztését .uhu-ra írták át.

Az UHU-s khm. hibás elgondolásodra már rávilágítottak előttem, én csak a SuSE-val kapcsolatban jegyezném meg azt, hogy nem sárkány, hanem kaméleon, és a céget eredetileg "Software- und System-Entwicklung" néven hozták létre, bár mondják, hogy a Konrad Zuse nevére hajazó elnevezés szándékos volt. Szóval a SuSE az bizony egy mozaikszó, a CamelCase meg a német helyesírásból jön :-)

Ubuntu (máig felfoghatatlan, hogy lehetett így elnevezni egy főként nem Afrikában használt operációs rendszert)

Mert az alapítója dél-afrikai származású.

Linux Mint (elnevezhették volna bármelyik fűszernövényről)

Elnevezhették volna, de a Linux Mint kitalálójának addigra már volt egy Linux Mint című blogja, és gondolom tovább akarta vinni a nevet.

SuSE (a sárkány, hűdekomoly, kibaszott enterprájsz™)

Ahogy fentebb írták, nincs köze a sárkányhoz, ignis "kibaszott enterprájsz™" neve van, mindenféle humor és könnyedség nélkül. Ahogy az a németeknél sokszor divat. :)

HTH.

Így többen vesznek majd RHEL-t, több lesz a profit. Teljesen logikus lépés volt. Aki meg nem akar/tud fizetni, az keres mást helyette.

echo crash > /dev/kmem

Vagy nem. Ugye a CentOS/RHEL párosban az volt a jó, hogy a dev mehetett CentOS-on, a prod meg fizetős támogatott RHEL-en, API/ABI inkompatibilitás nem volt. Na ez megszűnik ebben a formában. Ha valakinek haosnló "páros" kell, akkor ott lesz az Oracle Linux (ami nemcsak hogy kompatibilis, hanem ugyanaz, gyakorlatilag csak a support rednelkezésre állásáért fizet az ügyfél), vagy épp az Ubuntu, amihez szépen vesz a Canonical-tól supportot a delikvens - igaz, ez utóbbi per vm alapon számolódik, míg az Oracle esetében van "datacenter" jellegű licensz is, ergo annyi vm-et tolhatsz fel a virtualizációs környezetbe, amennyi fér, licnesz csak a fizikai node-okra köll. Ez utóbbiban az a kényelmes, hogy gyakorlatilag semmi nem változik fejlesztői/üzemeltetői szemmel, csak épp nem a centos/rhel, hanem az oracle repókat fogják használni a gépek. Ha meg lokális repószervert használnak, akkor dupla előny, hiszen elég egy disztrót tárolni, nem kell kettő, döntően azonosat... (Oké, ha egy regisztrált RHEL-es gép certjével csinálok rhel repó mirrort pulp-ban, akkor azt már tovább tudom osztani lokálisan tetszőleges gépre, de maradjunk a jogszerű megoldások mellett...)

Egyelőre maradoka RHEL7/CentOS7 vonalon, ahol ilyenek vannak - hogy a következő főverzió ott mi lesz, az jó kérdés, majd kiderül. Újy projektben viszont már érdekesebb a dolog: ami most "előttem van", ott még a hw is kérdéses, de ezzel a lépéssel a nagy kék előhúzatta velem a "gondold újra" kártyát is...

Ugy gondolom, ez gyakorlatilag kimutathatatlan szintu valtozas lesz, ha egyaltalan, igy gyakorlatilag nem, nem lesz tobb a profit. Amit nyernek igy, hogy a jelenlegi felhasznalok tobbseget elidegenitik es abszolut masfele nyitnak - kenyszerbol, es amig lehet, de semmikepp sem lesz kenyelmes, uj kornyezetet megszokni/megtanulni/megismerni. Az OL meg egy erdekes kerdes, de 8-ra nincs script, es tenyleg kerdes, hogy mit lep erre kozeptavon az Oracle (most persze, hogy csabitja az embereketm nyilvan), de siman elvaghatjak ezt a lehetoseget, ahogy maga a RedHat is.

Nem beszelve arrol, hogy ezeknek a probalkozasoknak akonverzios aranya meg szinten marginalis, ha szarmazik ezekbol egyaltalan uj ugyfel.

btw, itt nem ugyan azt látjuk mint a Novell -> SUSE esetén annó ?

Redhat -> CentOS.

És a HW gyártók azért szeretnek olyan rendszerekhez drivereket / fw-ket / stb-ket kiadni, amik fixek. Eddig pl egy HP fw csomag simán ment centoson is hiába volt rhel a téma, mivel binary-compatible volt a két rendszer.

Lehet ezek után ez sem fog majd menni. De ne csak fw frissítés, az megoldható máshogy is, driverekre kell itt gondolni.

hmm. érdekes.

Én meg úgy tudom, hogy a számozása szűnik csak meg, rolling distro lesz.

READY.
󠀠󠀠‎‏‏‎▓

Azért nem mindegy, hogy Fedora -> RHEL -> CentOS vagy Fedora -> CentOS -> RHEL az új verziók kiadásának a sorrendje...  Eddig a CentOS a RHEL forrására épült, ebben a rolling release-es mókában meg ez az én olvasatomban megfordul: azaz a CentOS lesz at "UAT/testing" rendszer, és ami ott "jól vizsgázott", az kerül a stabil RHEL-be.

Igen. Azért azt ne felejtsük el, hogy az hogy azok az idők már eljártak, mikor egy stdc++ verzióugrás miatt a komplett OS-t le kelljen gyalulni, és újratenni. Kb. 10 évvel ezelőtt ezért hagytam fel a CentOS szerverekkel.
Én azért első körben nem temetném a CentOS-t. Van mögötte bőven szürkeállomány, na és persze közösség is.

READY.
󠀠󠀠‎‏‏‎▓

Csak nekem fura, hogy valaki csinál egy disztrót, jelentős community épül köré, elismert és sokak által használt lesz, majd community által elismert és elfogadott vezetőség ELADJA az egészet....

Aztán megtörténik ami várható volt: a gazdája bedarálja/eltemeti, vagy épp csak a saját igényeihez alakítja.

Mindeközben a community nem az eladás miatt háborog, hanem mert a jelenlegi gazdája a saját igényei szerint játszik az új játékával.

Majd a csávó diadalmasan újrakezdi az egészet előről - ami kizárólag akkor érthető és elfogadható, ha ö személyesen nem húzott hasznot és/vagy nem értett egyet az eladással.

 

Félreértés ne legyen: szerintem - mint magánember - sem volt egy okos lépés, főleg nem így ahogy csinálták.

Gondolom megkapta a garanciákat arra, hogy az új gazda milyen szabályok szerint játszik a játékával. És ez általában jó pár évig megy, aztán az új gazdát megveszi egy nagyobb gazda és ugye ott már nem érvényes ez a megegyezés. Egy csomó példa van erre, hogy csak a nagyobb cégeket említsem:

Hudson -> Sun -> Oracle

OpenOffice -> Sun -> Oracle

MySQL -> Sun -> Oracle

Wildfly -> Red Hat -> IBM

CentOS -> Red Hat -> IBM

Miért lenne fura ?

A gazdája lehet hogy érezte, hogy túl nőtt már rajta és jobb ha nagyobb szervezet viszi tovább több erőforrással...

jót akart és jövőt a CentOS-nak, csak a világ változik és megtörtént, ami..

Nem tudni mennyit kaszált érte, de mindennek van ára (amennyit kifizetnek érte) -- hogy Red Hat Inc.- nek mennyit ért azt nem tudni..

Evolúció? Te is beálltál a fejlődésmániások utált soraiba? Mi az, hogy sw-ek evolúciója?! Úgy jó, ahogy van! nem kell új, elég a meglévőket befagyasztani. és azt supportálni időtlen időkig... Vagy nem...? mert mintha ezt szoktad volt korábban hangoztatni...

Szerkesztve: 2020. 12. 11., p - 22:47

.

rettentő sokat beszél a faszi, de a TL;DR továbbra is az, hogy jó lesz neked beta teszternek lenni, jobb lesz az egész, mert aktívabb a community, ha meg eddig csak örültél, hogy van, akkor nyugi, megígérjük, hogy ez is stabil lesz (tm).

Az egészben természetesen sok igazság van, csak szerintem továbbra is teljesen elmegy a lényeg mellett. A centos arról szólt, hogy ha open source, akkor bizony meg lehet kapni a végterméket ingyen is, ha valaki beleteszi az effortot. És a felhasználók jelentős részét nem érdekli, hogy egyébként az RH hogy, mit és miért csinál, egyszerűen arra kellett neki, hogy egy széles körben támogatott, működő platformot tudtak használni, ingyen, ha nem kellett a support. Na, ezt rúgta most fel az RH. Az ő szempontjából természetesen érthető, hogy megpróbálja a communityt jobban bevonni, és szarik az "élősködőkre", csak azok meg szarnak az RHra ebből a szempontból, nem akarnak bevonódni.

Nézd, az RH tényleg érti szerintem ezt az open source izét*, tudnak úgy "futtatni" open source projekteket, hogy az valóban az, nem csak időnként kidumpoljuk GPLben is jelleggel megy. Elhiszem nekik, hogy tényleg azt gondolják, hogy ez jó. Hova tovább, szerintem a stream egyáltalán nem egy rossz ötlet, a sigek -- már amelyik nem tetszhalott -- szintén az, még olyat is el tudok képzelni, hogy nem kontribútorként is lenne, ahol megkockáztatom, hogy még kicsit jobban is jár az ember a streammel. Csak nem látják a fától az erdőt: ezek hasznosak, csak ha kidobod a végéről a "stabil" reprodukciót, akkor a centos mint olyan nagyságrendekkel lesz kevésbé érdekes.

* többnyire, bár pont az összeborulás előtt volt ugye a centos kapcsán, hogy nem szabad leírni a RH nevét, volt helyette upstream vendor, ami már akkor is baszott nagy marhaság volt, és most a rockyval megint megkönnyeztem, hogy már ez van írva.

Hm... mázli, hogy RHEL7-en és CentOS7-en megyünk. Nagyjából már tudom is a főnököm reakcióját, mikor majd közlöm vele, hogy "na, hát akkor az eddigi prod környezetek mellé minden olyan rendszernél ahol a dev/test alá elég volt a CentOS, lehet venni RHEL licenszt, úgyhogy kéne tolni a büdzsében tervezésnél egy kettőnél nagyobb szorzót a RHEL licenszekre a következő években". Nagyjából eltorzult fejjel fog magából kielve ordítva kurvaanyázni az IBM-re, és közli, hogy álljunk át valami másra, a Red Hat meg ott rohadjon meg, az IBM-mel karöltve. :)

Nálunk nem arról van szó, hogy csak CentOS-en mennek a cuccok, 'ingyér''. Red Hat az alap, van ahol prod/test/dev környezetben is. Elég sok pénzt kifizetünk évente vmware/ms/rh licenszekre. az IT büdzsé jelentős részét teszi ki. Ahol nem kritikus, ott CentOS-en ment a dev/test, mert elég volt az is. Plusz épp idén, pandémia alatt, amikor mindenki behúzta a kéziféket, akkor vettünk egy szemmel is jól látható összegért (olyan 100+ M Ft), egyéb IBM termékeket is. 

Az IBM szimplán egy idióta, és megint nem érti a körülötte lévő világot. Pont az említett beszerzés alatt találták ki, hogy valami piszlicsáré indok miatt majd jól megbüntetnek minket 8M Ft-ra. A menedzsment meg megkérdezte, hogy pont most, amikor egy 100M Ft körüli beszerzést tervezünk csinálni, akkor szerintük ez jó ötlet-e? De jöttek nagy arccal, hogy ilyen-olyan szabálytalanságot találtak, balblabla. Aztán mikor a el lett nekik magyarázva, hogy akkor semmi gond, a tervezett beszerzés kb. feléből át tudjuk portolnni az IBM-en futó core rendszert másra, úgyhogy válasszanak. Vagy kifizetjük a 8M Ft-ot, de akkor nincs üzlet, elkezdjük az átállási projektet másra, VAGY elfelejtik a büntetést és akkor lesz üzlet. IBM oldalról csak ment a pislogás, aztán házon belül valahogy a sales lemeccselte a másik területtel a dolgot. De egyszerűen röhej, hogy képesek lettek volna 8M Ft miatt bebukni egy 100M Ft-os üzletet... Kb. annyi eszük van, mint a közmunkásoknak, ekik elloptak egy pávát, és megették. a tulaj elmondta, hogy a páva kb. 100e Ft-ot ért. Ha eladják, akkor az árából tudtak volna venni kb. 100kg húst. Ehelyett hozzá jutottak a pávából 1kg húshoz. 
Mondjhuk a dolgot így is bukják, mert ennek mentén elindult egy pilot projekt a core rendszer cseréjére, mert a cégnél a menedzsment kegyetlenül felszívta magát ezen a sztorin. Ha beválik az új rendszer, akkor mire a most vett IBM cuccok supportja megszűnik, a másik rendszer már kiforrja magát, és átveszi a mostani IBM-es rendszer helyét. Onnantól meg nincs szükség az IBM termékeire. Nem lesz se bünti, se biznisz. 

Ez egyébként leginkább ilyen kulturális különbség. Amcsik hozzá vannak szokva, hogy ha nem értenek egyet, akkor elmennek egy bíróságra, az megmondja mi van, aztán minden megy tovább, business as usual. Annó svéd kolléga mondta, hogy valami amcsi tűzfalas cég is járt úgy, hogy kitalálták, hogy valami licenszelés nem úgy számlálódik, ahogy az egész nordic regioban csinálták, és mostazonnal sokpénz pluszban (egész szépen beágyazódva viszonylag komoly helyekre). Az érintettek meg jöttek, hogy jó jó, de azért ebben ti is benne voltatok, egyezzünk már meg valahogy. Amcsi cég úgy érezte, hogy bíróság (hiába magyarázták a partnerek, hogy nem lesz ez jó ötlet), az ügyfeleik szépen kifizették, aztán az amcsi cég csodálkozott, hogy egy év alatt gyak minden észak európai ügyfelük kibaszta őket a picsába.

aztán házon belül valahogy a sales lemeccselte a másik területtel a dolgot

Egyébként ez minden túl nagyra nőtt zsíros seggű mamutot jellemez.

Anno magyarországi banknál éltem meg a legdurvább ilyet, ahol ugye gondolták, hogy majd szednek be pénzt az SMS-ek után, de ehhez kellett volna ~ 10 millió forintos fejlesztés egy külső rendszeren és pár emberhónap belső erőforrás. Hónapokig tologatták a dolgot, mert senkinek nem volt a tervsorán erre használható pénz, aztán jegelték, majd elővették, ismét jegelték, nagyjából három év telt el, a banknak amúgy évente 500 millió bevétele lett volna ebből.

Mi a lényegi különbség az Oracle linux és Centos között? Mert úgy érzem a hozzászóásokból, hogy az oracle egy rosszabb centos alternatíva. Miért? Mert nem olyan könnyű upgradelni Red Hatra vagy ennél sokkal duzrvább a helyzet? Azt olvastam, hogy valamit okosítottak a kernelen, tettek bele plusz drivereket emiatt lehet szopás az upgrade, azt elhiszem, de mégis mi vele a baj?

Ha alaposabban megnézed, kernelben mindenképp jobb alternatíva - frissebb kernelt tartalmaz, illetve a javítások is hamarabb jönnek ki rá, mint ahogy az eddigi CentOS-ba lecsorogtak. (Én desktop-on CentOS-ben is elrepo-s kernelt használok, mióta egy notebook-on szembe jött az, hogy az eredeti CentOS-os kernellel nem tudott két küldő monitort kezelni...