Když "Enterprise" znamená nepoužitelný

chromatic si ve svém posledním článku na modernperlbooks.com bere na mušku Enterprise Linux distribuce (konkrétně uvádí RHEL 5.5 a CentOS 5.5) u kterých se Perl zasekl na verzi 5.8.8, která byla vydaná před více než čtyřmi lety. Podle něj je takto prastará verze nepoužitelná pro programátory/uživatele jazyka. Vývojářům na těchto systémech doporučuje začít instalací App::perlbrew .

11.9.2010 13:43 | mj41 | Zajímavý článek

Komentáře

[bigBRAMBOR]

Centos pouzivam, verzi 5.5, a PERL jse opravu jedna z veci ktera me hodne stve. Myslim ze pauza mezi RHEL 5 a 6 je asi tak dvakrat delsi nez by si zaslouzila, a soucasny 5.5 uz je opravdu zastaralý.

[Ruža Becelin]

Nejdriv si (ty i autor clanku) precti tohle. Pokud je pro tebe RHEL/CentOS zastaraly, prejdi na neco jineho. RHEL ma stejnou strategii jako Debian Stable, take posledni novinky tam fakt nehledej.

Enterprise se to nejmenuje proto, aby mi tam update rozbil funkcnost systemu (i kdyz se jim to jednou povedlo s wget mezi 5.3 a 5.4), ale abych mel jistotu, ze provozovana aplikace pobezi celou dobu, kdyz je operacni system podporovany.

Navic autor clanku je dost mimo, protoze doporucuje instalovat perl 5.12/5.11, ktery nebude ani v RHEL6/CentOS6 (tam bude 5.10).

[Bedňa]

Mimo nieje, doporučuje to preto že opravujú padanie Perlu pri určitých regexpoch.

[Ruža Becelin]

Pokud mu pada Perl pri regexpech, ma nahlasit bug v BugZilla, tak se to totiz v Enterprise distribucich dela, ne brecet do blogu, ze to je moc stary.

[Rezza]

Nene, v enterprise distrech se jde pres support. A pry Lvicatko pozdravuje uzivatele Linuxu.

[Ruža Becelin]

Rozhodne, pokud mam RHEL

Pokud mam CentOS, mel bych hlasit bugy aspon do BugZilly.

Du druhou vetu uplne nechapu, ale to muze byt tim, ze uz jsou dve rano

[Bedňa]

Prepáč nechcem sa o týchto veciach hádať, ale ten problém je už vyriešený, práve prechodom na vyššiu verziu. Tak načo znovu riešiť patch. Hoci čiastočne by to zmysel malo pretože nová 5.12 prináša nové funkcie, kde zas môžu byť nové bugy. Niesom bezpečnostný analitik, tak ma neťahaj do detajlov :) To je skôr otázka na štatistický úrad, aké percento nových patchov kontra nových vlastnosí zníži bezpečnosť.

[Ruža Becelin]

Enterprise verze nedovoluje prejit na vyssi verzi kvuli riziku zavleceni novych chyb, popr. zmene funkcionality - proto se to resi patchovanim. Podivej se treba na kernel RHEL - to je mix nekolika verzi + spousta backportovanych patchu z novejsich jader.

[kavol]

Prepáč nechcem sa o týchto veciach hádať, ale ten problém je už vyriešený, práve prechodom na vyššiu verziu.

jak již napsal kolega, ale opakování je matka moudrosti - v nové verzi je možná nějaký tvůj konkrétní problém vyřešený, ale je tam zároveň deset nových, a někdy o dost zásadnějších, aneb na míň peněz přijde opsat z nové verze patch než mít několik dní downtime a muset nechat přepisovat polovinu svojí aplikace (zvlášť s přihlédnutím k tomu, že ten patch se opíše jednou, udělá to za tebe distributor, kdežto těch aplikací, co se na konkrétní verzi/chování spoléhají, je hafo, to jsou uživatelé s vlastním software nad daným OS, a dost často jsou to aplikace hodně kritické, např. řízení letového provozu - tedy, to asi nikdo v perlu nepíše, ale když update perlu rozbije OS pod tím, který má v perlu nějaké skripty, třebas, tak to v důsledku zneprovozní i tu aplikaci)

[Grunt]

To jako že se backportují komplet všechny patche, jež pokrývají komplet všechny bezpečnostní bugy v daném distru? To musí být občas docela masakr.

[kavol]

komplet všechny ne - jenom na díry, které jsou uznány za dostatečně nebezpečné, anebo kvůli kterým zákazníci řvou (plus cokoli nač stačí volná kapacita, ale ta nestačí na všechny)

a masakr to je :-/

[Grunt]

Někdy mi to uvažování vyšších vrstev neleze do hlavy.

[kavol]

?

[Grunt]

No tato manažerská logika typu hlavně ať to jede (po manažersky hlavně ať je to v produktivním stavu). Bugy jsou prostě součástí počítačového života stejně jako < doplnit dle libosti – žádné vhodné přirovnání se mi zrovna vymýšelt nechce >. Je mi jasné, že backportovat všechny bezpečností záplaty je nad lidské síly programátorů (a to dokonce i v RedHatu) i kdyby snad byly posvěcení. Takto případnému útočníkovi stačí zjistit verzi systému (a že to občas nestojí ani moc úsilí), všechny známé bezpečnostní bugy od dané verze a pak k tomu ty, které nebyly záplatované a už může tahat exploit za exploitem a zkoušet ten svůj šťastný. Takový systém IMHO nemá moc daleko od děravých Oken. A třeba v případě řízení leteckého provozu by se tyto vyšší sféry jen modlili za tu schopnost uvést celý systém do stavu nefunkčního než-li čelit hrozbě útočníka/únosce. To je IMHO mnohem kritičtější. Ba co víc. Co já vím, tak se RHEL nasazuje především do bankovních institucí. Tak schválně. Co by byla větší ztráta? Systém v nefunkčním stavu nebo napadený systém na kterém má útočník volnou ruku pěkně v klídku a chládku bez jakékoliv prozrazení?

[Ruža Becelin]

Myslim, zes to uplne nepochopil. Nebackportuji se vsechny bezpecnostni zaplaty, ale jen ty, ktere se tykaji verze pritomne v danem distru. Priklad - pokud mam kernel 2.4.18-neco, tak asi nebudu backportovat patch z verze 2.4.32, ktera tam byla zanesena ve verzi 2.4.27, chapes?

Pokud se v novejsi verzi vyskytne bug, dela se audit, jestli se bug tyka i starsi verze, pokud ano, patch se backportuje. Popsal jsem to dost laicky, nekdo od RedHatu ti to urcite popise presneji,

Takze predstava utocnika zkousejiciho vsechny zname exploty na tisice deravych RHEL v bankach je dost mimo...

[Michal Karas]

Je mi jasné, že backportovat všechny bezpečností záplaty je nad lidské síly programátorů (a to dokonce i v RedHatu) i kdyby snad byly posvěcení. Takto případnému útočníkovi stačí zjistit verzi systému (a že to občas nestojí ani moc úsilí), všechny známé bezpečnostní bugy od dané verze a pak k tomu ty, které nebyly záplatované a už může tahat exploit za exploitem a zkoušet ten svůj šťastný.

To myslíš vážně? Protože jestli jo, tak bych si moc rád nechal rozšířit obzory a viděl nějaký ten exploit. Nebo klidně i odkaz na podrobnosti o tom, kdy a jak byl kompromitován RHEL kvůli bezpečnostní chybě, jejíž záplata nebyla backportována z upstreamu.

[pht]

A třeba v případě řízení leteckého provozu by se tyto vyšší sféry jen modlili za tu schopnost uvést celý systém do stavu nefunkčního než-li čelit hrozbě útočníka/únosce. To je IMHO mnohem kritičtější. Ba co víc. Co já vím, tak se RHEL nasazuje především do bankovních institucí. Tak schválně. Co by byla větší ztráta? Systém v nefunkčním stavu nebo napadený systém na kterém má útočník volnou ruku pěkně v klídku a chládku bez jakékoliv prozrazení?

Pracoval jste někdy na uvedených pozicích nebo jen tak melete?

[Grunt]

Jen tak melu.

[pht]

Abych to vysvětlil, tak z toho, co znám o těchto prostředích

1) Serverový OS nebude nejslabší článek řetězu - RHEL má zero day bugfixy poměrně promptně a navíc má defaultně zaplý selinux. Ona ta placená podpora tak nějak opravdu funguje.

Prakticky jediná možnost je si koupit exploit na takovou tu chybu o které nikdo neví a která tam už je pěknou řadu let jak je z toho občas skandální senzace a lidi jako vy si jen řeknou hm a zapatchují to. Ale je podstatně jednodušší se nabourat buď do PC klienta nebo do business aplikace.

2) Kritické systémy mívají kontroly, redundanci a záložní plány takže v případě poruchy nebo napadení to stačí vypnout - víra v počítače není 100% jak to známe z filmů.

3) "Systém v nefunkčním stavu" stojí dost peněz a to obvykle tolik že výše uvedená rizika je nutno do designu započítat.

[vencour]

Jj, reakční dobu 1h u nejvážnějších případů jsem u nikoho ještě neviděl, jen u RHELu.

[kavol]

Takto případnému útočníkovi stačí zjistit verzi systému (a že to občas nestojí ani moc úsilí), všechny známé bezpečnostní bugy od dané verze a pak k tomu ty, které nebyly záplatované a už může tahat exploit za exploitem a zkoušet ten svůj šťastný.

nějak jsem ovšem nepochopil, proč by mu totéž nestačilo i u systému, kde bude nová verze Perlu ...?

Co by byla větší ztráta? Systém v nefunkčním stavu nebo napadený systém na kterém má útočník volnou ruku pěkně v klídku a chládku bez jakékoliv prozrazení?

problém je, že systém se sám od sebe nenapadne, zatímco rozbít by se "sám od sebe", tedy po updatu na novou verzi, mohl

zdá se mi, že předpokládáš nový = nenapadnutelný, což je nesmysl, realita je spíš opačná

[petr_p]

V rámci jedné řady RHEL je nutné držet kompatibilitu. Perl drží kompatibilitu pouze uvnitř mikro verze (5.8.x kompatibilní jsou, 5.x.y již být nemusí). Proto není možné uvnitř jednou vydané řady distribuce RHEL měnit perl, jak by se někomu hodilo.

Pokud tě tato chyba pálí, napiš na podporu a věř mi, že někdo se tvým problémem zabývat bude ;)

[Luigi]

malý postřeh: používám v celé své (docela velké) rodině Gentoo. Od malého serveru s VPNkami až po desktopy, notebooky a netbooky. Je to dokonalá škola správy (pokud na to člověk nekašle) a umožní člověku pochopit co je za slůvkem enterprise. Rozdíl je obrovský a přesně tak jak tu je psáno - nelze vyměnit nějakou verzi za jinou (jako třeba v Gentoo) jen tak. Došlo by ke ztátě integrity toho systému jakožto testovaného enterprise prostředí. Ten rozdíl je obrovský a jsou místa kde je nutné k tomu tak přistupovat. A že je něco 4 roky staré... pokud se sledují chyby je to v pořádku. Základem je stabilita. Právě proto, že to Gentoo používám vidím ten rozdíl (výhody/nevýhody). Já u každého update procházím changelogy, fóra, testuji. Pak teprve všechny stroje zmigruji. Toto dělají v případě enterprise autoři a dělají to určitě lépe. ( Ale mě to baví a líbí se mi Gentoo ... )

[mj41]

Řekl bych, že autor dobře zná argumenty, kterými tvůrci distribucí postup obhajují, ale nesouhlasí s nimi.

Je to trochu začarovaný kruh. Jako vývojář se snažím spoléhat jen na ty funkčnosti pro které existují automatické testy. Je tedy jednoduché držet se posledních funkčních (zpětně kompatibilních) verzí. Prostě kouknu na výsledky testů a vím, zda upgrade něco rozbije nebo ne. Navíc chromatic jako jednu z možností pro kritické komponenty jádra, kde distribuce nejsou schopny otestovat funkčnost dostatečně rychle/automaticky doporučuje mít v systému dva Perly. Ten skrytý pro systém a ten normální aktuální pro uživatele.

Při vývoji chci používat poslední oficiální produkční verzi Perlu. Nebo má RedHat vlastní větev Perlu a CPANu, která by byla vhodnější? Neříkám, že se občas něco nerozbije, ale vždy mi to připadalo jednodušší než problémy, které přináší starý Redhatem patchovaný Perl, viz. třeba [1]. Neprogramuju věci 4 roky, abych v době kdy vydám produkční verzi pro ně konečně existovala produkční Enterprise distribuce, kde to poběží.

Produkční systém, který bez změn běží 10 let je spíše vyjímka. Vemte si např. jak vypadal web před 10 lety. Chápu, že pro adminy je supr, když všechno mají nainstalované z oficiálních RPM, upgrady běží automaticky a oni na to nemusí léta sahat. Pro vývojáře a uživatele to ale už taková idylka není.

[Sid]

To je prave ten rozdiel, ze neprogramujete na 4 roky, pouzivatelia enterprise rieseni ano. Je uplne bezne mat support pre aplikacie napr. 6 rokov v cene produktu. Samozrejme cena produktu je niekde inde :). Musite rozlisovat od svojej aplikacie, co ked padne je to kazdemu (okrem vas) celkom suma fuk a od systemu, ktory ked padne tak skody idu do milionov. Potom celkom dobre pochopite vyznam tychto verzii. Odhliadnuc od toho, ze nie kazdy system rovna sa autmaticky web a pristup z vonka. Funkcne testy su pekna vec ale nepokryju vam vsetko. Predstavte si napr situaciu, ze sa niekto v OS pohra napr. s planovacom a nahradi ho nejakym uplne inym. Vasa aplikacia je za tie roky celkom rozumne vyskusana a naraz mozete pri urcitych sposoboch zataze sa dostavat do problemov. A nemusi to byt uplne ocividne, ze problem je prave planovac. Zakaznika samozrejme nezaujima OS, jeho zaujima preco vasa mega draha aplikacia sa nechova tak ako chce. Takze pekne zijete s chybami co su vo vasom enterpise distre, samozrejme nadavate, ze preco to ti blbci este neopravili ale v principe ste na to lepsie ked viete, ze to a to nejde, ako ked je tam x skrytych chyb o ktorych sa vobec nevie.

Podla mna skor je otazka ci pre vacsinu aplikacii je vobec nutnost enterprise distra. Asi nieco na sposob kupime si Oracle na uctovnicky system z 5 uzivatelmi, ved nam to odporucali :).

[bigBRAMBOR]

Ja samozrejme vim co je prednosti RHEL, a proto jsem ji zacal i pouzivat, ale nekdy se konzervativni pomalu pomaloucku stane zastaralým, ani si toto autori poradne nevsimnou. To ze mas system odladeny a spolehlivy je k nicemu kdyz mas problem pustit co potrebujes. Kdyz vezmu ze takovy CentOS by mel byt jako delany na mensi servery, treba na ruzne redakcni systemy, tak si musim priznat ze si na nem pro zastaralost PHP a PGSQL, treba u drupalu, bez EPEL neskrtnu.

[Heron]

Jestli ono to není spíše naopak. Jak to, že je dnes 4 roky staré PHP / PERL nepoužitelné? Jak to, že Drupal nejede (mě teda jede) na současné jedničce v enterprise distribucích?

Toto není chyba RHELu.

[bigBRAMBOR]

trochu se zpozdenim, me taky jede, na PGQL, ale pro problemy pri updatech, ktere ocekavali novejsi verzi PGSQL, jsem mohl bud delat rucni upravy v databazi, nebo dat novejsi verzi databaze.

[Ruža Becelin]

V podstate sis odpovedel sam - potrebujes novejsi veci, tak si nainstaluj EPEL apod. Ja mam Subversion 1.6 na RHEL5 a taky to funguje. Jediny detail je, ze RedHat EPEL a spol nesupportuje, ale s tim clovek tak nejak pocita...

[pavlix]

Pokud vím, tak by EPEL neměl upgradovat balíky ze základu. Ale rád se přiučím, jak se to řeší.

[Ruža Becelin]

EPEL je staveny tak, ze (narozdil od jinych) nekoliduje se zakladnimi baliky od RHEL. K tomu mam ja sve vlastni repo s baliky, ktere potrebujeme k praci, napriklad Subversion 1.6 od WanDisco. Ty take nekoliduji, ale pred kontrolni RPM se urcuje, jestli se nainstaluje verze z RHEL nebo z meho repa.

[pavlix]

Aha, takže ty novější balíky byly zahrnuty do zkratky "apod.". Pak je vše v pořádku.

[bigBRAMBOR]

u EPELU nevim, ale treba baliky DAGa kolidují, a myslim ze EPEL taky, resi se to moduly do YUM, ktery repositar muze delat upgrade ktereho a ktrereho uz ne.

[Michal Karas]

To samé by se dalo říct o Ruby. S verzí 1.8.5 se už člověk dneska těžko jinde potká. K dispozici je RVM, které krom správy více verzí/implementací interpretu umožňuje vytvářet i navájem na sobě nezávislé gemsety.

Přijde mi to jako skvělý nástroj pro lokální vývoj, ale že bych to cpal do enterprise distribuce? A instaloval kvůli tomu na nějaký produkční server všechny vývojářské nástroje potřebné pro kompilaci? To mi fakt přijde na hlavu. Radši si vytvořím vlastní balíček s REE, které si nastěhuju někam do /opt, když na tom serveru k něčemu potřebuju aktuálnější verzi Ruby. Ale kdo ví, třeba mám o použití enterprise distribucí trochu jiné představy, než k čemu se ve skutečnosti používají.

[samox86]

mrkni sem: http://press.redhat.com/2010/08/19/red-hat-enterprise-linux-extended-life-cycle-support-launched/
red hat ponuka predlzenie podpory RHEL3 o dalsie 3 roky ;)

[Heron]

která byla vydaná před více než čtyřmi lety

A to si stěžuje, že je to příliš nové a málo otestované?

Vývojářům na těchto systémech doporučuje začít instalací App::perlbrew

Vývojáři nemusí mít na své pracovní stanici RHEL. Důležité je, aby to pak jelo na produkčním serveru (tedy vyvíjet mohou klidně na Fedoře, ze které se za rok, dva stane další RHEL. A pojede jim to produkčně dalších 7 let.

[JoHnY2]

Neznam stav Perlu v RHEL, ale musim se zastat konzervativniho modelu pri sprave distribuci jako je RHEL a Debian stable. Je to totiz jedina cesta jak zabranit naprosto nevypocitatelnejm problemum s kompatibilitou. Na novejsi verze mame aspon v debianu testing a backporty, jak to maj panove v RHEL a CentOSu nevim.

Trochu jina vec jsou bugy zpusobenym starim baliku a jejich zaplatovani. Tam je to potom holt o hromade hnusnejch patchu na strane distributora a pokud to nedela, tak by mel dostat za usi. Osobne mam z clanku dojem, ze to je prave pripad perlu na RHEL.

[pht]

Je to totiz jedina cesta jak zabranit naprosto nevypocitatelnejm problemum s kompatibilitou.

Není.

[Shadow]

Mohl byste to rozvést?

[pht]

... musim se zastat konzervativniho modelu pri sprave distribuci jako je RHEL a Debian stable. Je to totiz jedina cesta jak zabranit naprosto nevypocitatelnejm problemum s kompatibilitou.

Není to cesta (vůbec) jak "zabránit problémům s kompatibilitou". Nemá to nic společného s kompatibilitou.

Je to jen způsob jak získat 100% kontrolu nad obsahem zdrojových kódů.

Dělají to za účelem prodeje podpory toho co ten kód dělá. Ale má to i své stinné stránky, např. že někdo může rozhodovat o tom jestli se nějaká vlastnost backportuje nebo ne - viz zmíněný problém s perlem.

[Petr Bravenec]

Aha, takže CentOS je něco jako Debian - spousta věcí tam nejede, ale zato mám zaruku, že to nepojede spoustu let.

[kyytaM]

Debian nema bakcporty?

[mepho]

Nie, je to nieco ako Debian, spusta veci tam nejede, ale za to mas zaruku, ze to co ide pode spustu let.

Náš administrátor shledal tento komentář závadným.

Náš admin shledal tento text nevyhovujícím slušným mravům.

Zobrazit komentář

[l4m4]

A co je tam za verzi Perlu?

[Mordae]

Hmm a tam je perl v jake verzi? Aha, rucne, ok... A python? Hmm a co vsechny ty knihovny, ktere moje aplikace potrebuje? Jo rucne zkompilovat, nainstalovat jine, zvlast placene. Aha, ok. A opravy chyb ve vsem tom SW tretich stran? Jo ahaaa, nainstalovat dalsi produkt 3. strany, ktery bude hlidat verze SW a pripadne si muzu napsat i automaticky silent instalator a ten nastroj mi umozni distribuci novych verzi napric siti. Ok... Jo voni Windows neumi smazat soubor, ktery je pouzivany, ahaaa, takze pri upgradu dllky musim mit vypnutou aplikaci, to je fajn, ok...

Uz by konecne nekdo mohl udelat nejakou rozumnou distribuci Windows, co?

[Laco]

Skus PowerShell

[Václav "Darm" Novák]

Nemohl jsem si pomoct...

[l4m4]

A tím konkrétně myslíš ,zkus interpretovat existující aplikace v Perlu PowerShellem` nebo ,zkus přepsat všechny existující aplikace v Perlu do PowerShellu`?

[Grunt]

[the oringe juice]

Co to má být? Tvoje fotka?

[Grunt]

Tvoje fotka?

Kdepak. To je fotka příbuzného. Moje je tahle:

[munich machine]

"attention whore"

[Václav "Darm" Novák]

Nikoliv, pouhopouhý troll… A ani to mu moc nejde :)

[pavlix]

Bulvár?

Zajímavé je, že dneska je čtyři roky starý perl nepoužitelný. Nezbývá mi než se zeptat na odpověď na jednu z následujících otázek.

a) Proč takto nepoužitelný perl vůbec vyšel?

b) Co se ve světě tak zásadního změnilo, že tato verze perlu magicky přestala být použitelná?

[petr_p]

Tak. Dodám, že stabilní verze perlu v Gentoo je rovněž 5.8.8.

[pavlix]

Hezká poznámka. Díky.

[mj41]

a) Proč takto nepoužitelný perl vůbec vyšel?

Proč někdo vyráběl analogové černobílé CRT televize? Snad proto, že to ve své době bylo to nejlepší co se dalo uživatelům nabídnout.

b) Co se ve světě tak zásadního změnilo, že tato verze perlu magicky přestala být použitelná?

To se zeptejte těch co si z obchodů domů odnášejí už jen digitální barevné LED LCD televize.

Teď vážněji. Programátoři prostě pracují a uživatelé chtějí jejích vylepšení používat. chromatic zmiňuje Perl 5.8.9, poslední produkční je Perl 5.12.2 a to jsou jen dva ze všech perl*delta.

Perl není stará černobílá televize, jak by se podle Enterprise distribucí mohlo zdát.

[Heron]

Černobílé CRT se dodnes používají a evidentně nejsou určeny (stejně jako RHEL) pro ty, co si z obchodů odnášejí digitální LCD jen proto, že je to cool a moderní.

[pavlix]

Nejsem si jistý, zda jste můj komentář pochopil.

Proč někdo vyráběl analogové černobílé CRT televize?

Toto přirovnání podle mě selhává, protože podsouvá předpoklad, že černobílá CRT televize je zcela nepoužitelná. Osobně na tento předpoklad nevěřím.

To se zeptejte těch co si z obchodů domů odnášejí už jen digitální barevné LED LCD televize.

Ale já se opravdu ptal na to, co se změnilo ve světě počítačů, že předchozí verze věhlasného programovacího jazyka Perl se ze dne na den stala nepoužitelnou.

Když pominu to, že nevidím důvod se ptát náhodných kupujících LCD televizí na čistě programátorskou otázku... tak podle mě přirovnání opět zcela selhává, například už na tom, že Perl nepatří do kategorie spotřebního zboží.

Teď vážněji. Programátoři prostě pracují a uživatelé chtějí jejích vylepšení používat. chromatic zmiňuje Perl 5.8.9, poslední produkční je Perl 5.12.2 a to jsou jen dva ze všech perl*delta.

Příště bych doporučil tu úvodní omáčku rovnou přeskočit.

Programátorům (Perlu) nikdo nebrání dál pracovat. Uživatelům (perlu) tedy programátorům perlových aplikací nikdo nebrání nový perl využívat, za předpokladu, že si dobře rozmyslí použitelnost výsledné aplikace na cílové platformě.

Tudíž jsem za odpověď dostal něco, co vypadá jako posměšek nad tím, že nechápu nutnost okamžitého nasazení nové verze perlu na všech produkčních strojích. Ale nedostal jsem ani nejmenší náznak konkrétní změny, která takovouto potřebu implikuje.

[mj41]

Pro mně a většinu uživatelů je černobílá CRT televize již nepoužitelná. Chápu, že ti co na ní pouští jen staré černobílé videokazety jsou spokojeni. Taky náš opravář je má raději. Co, ale my co točíme filmy barevně v HD, protože to zákazníci požadují? RHEL není pro nás? Co jiného nám RedHat nabízí? Pochybuji, že by RedHat cílil jen na ty co mají doma video a staré černobílé videokazety.

Samozřejmě pokulhává spíše srovnání RHELu s televizí. Přirovnáním jsem odpovídal na otázku "Proč takto nepoužitelný perl vůbec vyšel?", která zase mně spolu s Bulvár? připadala trochu jako výsměch. Má reakce se tedy nesla v tomto duchu.

Samozřejmě, že se předchozí verze perlu nestala nepoužitelná ze dne na den. Méně použitelnou se stává průběžně s tím jak vznikají novější verze, pokud jsou tyto kvalitnější/schopnější. Také s tím jak je ostatní začínají potřebovat/požadovat v modulech na CPANu.

RedHat taky vydává nové verze, protože pouze opravovat bezpečnostní problémy zákazníkům nestačí. Pokud RedHat usoudí, že druhý den po vydání nového Perlu je potřeba mít jej na všech produkčních serverech, tak většině adminů to vadit nebude. Uživatelé budou jen rádi.

Článek ve zkratce říká, že pokud chcete vyvíjet v Perlu, tak vám Enterprise distribuce práci neusnadní, spíše naopak. Samotný autor nevidí důvod, proč by se v době, až to výrobci distribucí budou umět nemohl v Enterprise distribucích objevovat novější Perl.

[pavlix]

Samozřejmě pokulhává spíše srovnání RHELu s televizí. Přirovnáním jsem odpovídal na otázku "Proč takto nepoužitelný perl vůbec vyšel?", která zase mně spolu s Bulvár? připadala trochu jako výsměch. Má reakce se tedy nesla v tomto duchu.

Tak v tom šlapete a šlapete a dál ukazujete zřejmé nepochopení mého komentáře.

Tedy ještě jednou, ta věta byla v reakci na tvrzení autora, že je Perl ve verzi v enterprise distribucích nepoužitelný. Já jsem se ptal, proč takovýto, podle něj nepoužitelný perl byl jeho vlastními autory a spousty tvůrci perlovských skriptů po léta úspěšně používán... když je nepoužitelný.

To je vše.

[mj41]

Já jsem vysvětloval co nepoužitelný pro většinu uživatelů znamená. Použitelný dnes může znamenat nepoužitelný za čtyři roky. Tak to chápu já, autor a většina uživatelů. Z použitelného na nepoužitelný se tedy programovací jazyk dostává postupně. Zastánci Cobolu a Fortranu by tady do nekonečna mohli vysvětlovat jak ten jejich jazyk byl od svého vzniku použitelný a proto takový i navždy zůstane.

K vašim původním otázkám jsem toho napsal již dost. Na reakci "zřejmé nepochopení" nemá cenu reagovat, musel by jste být konkrétnější.

Pro mně prostě všechny Perly (a tipl bych si, že i ostatní dynamické programovací jazyky) ve verzi starší dvou až tří let jsou méně použitelné než ty aktuální. Chcete tvrdit, že první Perl 5 nebo dokonce Perl 1 je stále použitelný a bylo zbytečné jej v Enterprise distribucích upgradovat? Pokud ne, tak mi řekněte kdy je ta správná doba? 10 let? Nebo více? Autor článku jako znalec Perlu tvrdí, že po čtyřech letech je již Perl z praktického hlediska pro uživatele nepoužitelný a je nesmyslné mít jej ve stávajících distribucí.

[pavlix]

většina uživatelů

Vycucané z prstu, že?

Z použitelného na nepoužitelný se tedy programovací jazyk dostává postupně.

S tím souhlasím, jen se to děje daleko pozvolněji než si myslíte.

Zastánci Cobolu a Fortranu by tady do nekonečna mohli vysvětlovat jak ten jejich jazyk byl od svého vzniku použitelný a proto takový i navždy zůstane.

Pokud by byl tento jazyk již zcela nepoužitelný, žádné skutečné zastánce by neměl.

Pro mně prostě všechny Perly (a tipl bych si, že i ostatní dynamické programovací jazyky) ve verzi starší dvou až tří let jsou méně použitelné než ty aktuální.

Fajn, takže už ustupujete :). Nejdřív byly nepoužitelné, teď už jsou jen méně použitelné.

Autor článku jako znalec Perlu tvrdí, že po čtyřech letech je již Perl z praktického hlediska pro uživatele nepoužitelný a je nesmyslné mít jej ve stávajících distribucí.

Autor článku není zase taková autorita, aby mohl smyslupně popřít existenci všech uživatelů starší verze perlu. Ani vy nejste.

Let's end this stupid flame.

[mj41]

Vycucané z prstu, že?

Ne. Vlastní zkušenosti a zkušenosti autora.

Pokud by byl tento jazyk již zcela nepoužitelný, žádné skutečné zastánce by neměl.

Takže nepoužitelné jazyky podle vás neexistují? Každá kniha si najde aspoň jednoho čtenáře. Každý jazyk má svého zastánce.

Nejdřív byly nepoužitelné, teď už jsou jen méně použitelné.

Však o tom rozdílu se celou dobu bavíme. Já i autor pokládáme čtyři roky starý perl za "nepoužitelný". Samozřejmě, že slova můžou mít různou váhu. Pro mně je tma v noci a čtyři roky starý perl nepoužitelný. Pro vás nepoužitelné jazyky neexistují, stejně jako neexistuje tma.

Ale máte prvadu, už to k ničemu nevede.

[pavlix]

Ne. Vlastní zkušenosti a zkušenosti autora.

Hezké, to už máme celé dva lidi :). Jen tak dál.

Takže nepoužitelné jazyky podle vás neexistují?

Záleží na tom, jestli je někdo může s úspěchem použít :). V dnešní době bych za kritickou nepoužitelnost (z ohledem na čas a také typ jazyka, samozřejmě), označil například absenci podpory Unicode (nebo aspoň BMP část, v našem prostředí).

Ale to už hodnotím subjektivně a s ohledem na účel, například jazyk použitý při návrhu automatické pračky bez displaye by se bez toho obejít mohl :).

Pro mně je tma v noci a čtyři roky starý perl nepoužitelný.

Když už jsme u přirovnání... tak bych přirovnával s tmou v noci, když jsem byl loni v létě za polárním kruhem. Ano, byla noc, trochu se sešeřilo... ale to bylo tak všechno. S tím perlem taky, chybí pár nových vlastností, které by člověk rád, ale většina věcí se v tom dá úplně normálně napsat.

Jasně, je to jenom o míře... ale přijde mi důležité nebýt extremista a ani jedním směrem.

[mj41]

Mongrel2 Says, "Goodbye Python, By Zed A. Shaw

The distros have killed Python.

Yes, antiquated broken versions of Python are installed on every Linux.

[petr_p]

Ten člověk (1) nenapsal, co bylo rozbitého, a (2) z článku není poznat, kdy byl napsán. Třeba nyní Gentoo má 2.6.5, Fedora 13 má 2.6.4., Debian stable 2.5.2 (testing 2.6.5).