Vlákno názorů k článku
Konec bezpečnostní podpory pro PHP 8.0
od Josef Marianek - Doufam ze to RockyLinux drzi dyl (zatim jsem...
-
Josef MarianekBronzový podporovatelDoufam ze to RockyLinux drzi dyl (zatim jsem to nezkoumal). Ta doba podpory mne prijde moc kratka, i kdyz na druhe strane asi nebude zas tak velky problem jit na vyssi desetinkovou verzi bez ztraty funkcnosti neceho.
-
Nezbyva vam než doufat, každopádně nekompatibilní změny tam jsou
https://www.php.net/manual/en/migration81.incompatible.php
https://www.php.net/manual/en/migration82.incompatible.php
https://www.php.net/manual/en/migration83.incompatible.php -
Michal ŠmucrBronzový podporovatel
Od RHEL 8 počínaje se používají modulární repozitáře a balíčky se vydávají v různých streamech.
Některé z balíčků mají podporu stejně dlouhou jako komplet celý systém (celý životní cyklus - 5 resp. 10 let).
Ale jsou balíčky, u kterých se hodí rychlejší cyklus vydávání, který kopíruje upstream, a nevadí kratší podpora než u zbytku systému.
Některé z nich tam máte k dispozici rovnou, takže např. Firefox nebo Rust se vám může průběžně aktualizovat na jiné verze a nemusí to být zarovnané s desetinkovými verzemi systému.
Nakonec máte balíčky s rychlejším vydáváním, kde si můžete vybrat.
Dostanete se k nim tak, že přidáte a povolíte odpovídající stream přes dnf.Balíčky s php v základním AppStreamu RHEL 9 jsou ve verzi 8.0 a budou podporovány po celou dobu vydávání distribuce. Pokud byste potřeboval novější verzi, tak si přidáte a povolíte stream php (dnf module install php), tam jsou novější verze s kratší podporou.
Podobně můžete přidat streamy pro Node.JS, Postgres atd.Mrkněte na výstup u dnf modules list a https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle.
Počítám, že i odvozené distribuce (freeloaders ;) ) to budou mít stejně. Alespoň, co jsem se díval na Rocky, tak to tak je.
A samozřejmě modulární repozitáře byly ještě předtím ve Fedoře, viz.
https://docs.fedoraproject.org/en-US/modularity/ -
Podle mne je vývoj PHP jako programovacího jazyka zcela chybný a to zejména v tom, že nedrží zpětnou kompatibilitu kódu. Celé to vývojáři PHP podseknou tím, že podpora verzí je 3 roky. Jsou projekty, které se píší třeba rok, pak nějakou dobu nasazují, Tedy v produkci takový systém vydrží reálně rok a půl a pak se jako zahodí a začne se psát znovu ? Opravdu tomu někdo věří ? V reálu s každou novou verzí php vznikne nový izolovaný virtuál, kde se hromadí zákazníci, kteří potřebují běžet své aplikace na té které nepodporované verzi PHP. Programovací jazyk by měl být jako jazyk běžném životě. Měl by se dát používat celý život, ne směšných pár let.
Jen osobní názor. -
Celá vaše úvaha je chybná ve všech bodech:
- To, že je oficiální podpora tři roky neznamená, že po těch třech letech ten balíček zmizí.
- Když vyvíjíte aplikaci, tak ji průběžně aktualizujete na nějakou verzi. Takže i kdybyste psal aplikaci rok, tak prostě na konci toho roku zkontrolujete jestli poběží na nejnovější verzi a je to.
- To, že přestane podpora pro nějakou verzi neznamená, že ten kód musíte komplet přepisovat. Nechápu, jak jste na takovou úvahu přišel. Prostě vytvořil jste aplikaci v nějaké verzi, a chcete ji aktualizovat na novější. Tak si projdete těch pár okrajových záležitostí. Práce na hodinku.
- PHP komunita je velmi konzervativní. Je reálné upravit kód pro 5.2 tak aby běžel pro 8.3. Je vysloveně snadné poladit kód pro 5.7, aby běžel na 8.3.Naopak, kluci od PHP to vyladili výborně (a další jazyky to dělají podobně). Je zde nějaká oficiální podpora, kde lze očekávat určitě služby (bugfixy, bezpečnostní opravy, etc). A následně vás oficiálním prohlášením o ukončení podpory motivují k updatu. Čímž se šetří síly a nebrzdí pokrok. Perfektní vybalancovaný kompromis.
-
No zní to hezky, dokud se člověk nepodívá na realitu https://w3techs.com/technologies/details/pl-php
Ostatně i popularita, jaké se těší Ondřej Surý za jeho repo (a velké díky za ně), o něčem svědčí. -
Asi žijeme každý v jiném světě. Já se starám o hostingové servery (naše i jiných webhosterů), kde běží weby a aplikace zákazníků. Za těch 25 let jsem si nevšiml toho, že by webdesigneři měli snahu upravovat a přepisovat pár let staré webovky do novějších verzí PHP. A je jedno jestli je to postavené od základu na vlastním autorském frameworku nebo je to jen naohýbaný Wordpress, Drupal, Joomla. Vždy je tam nějaká zásadní modifikace nebo plugin, který již neběží v novější verzi a tedy ani neběží na novějším PHP. Ještě mám v živé paměti upgrade php4 na php5. Stejně bolavý byl přechod php5.6 na php7. Z každého přechodu zbyly desítky webů a aplikací, kde nebyla snaha/síla/finance je přepsat do novějšího php.
Co s tím ? Říct zákazníkovi, že vyhodil 30, 100tis za web, který nelze provozovat a je třeba ho za 3 roky zahodit ?
Nepolemizuji, jen osobní zkušenost. -
Proč by se měl web zahazovat, není snad problém provozovat víc verzí PHP najednou. Třeba Český hosting: 8.2, 7.0, 7.3, 7.4, 5.2, 5.3, 5.4, 5.5, 5.6
https://www.cesky-hosting.cz/webhosting/parametry-webhostingu/
28. 11. 2023, 12:23 editováno autorem komentáře
-
I když je provozujete najednou (což mi nedává smysl) nebo z bezp. důvodů odděleně od podporovaných verzí, nemění to nic na tom, že v dané verzi nikdo neopravuje chyby..
A přitom by stačilo držet zpětnou kompatabilitu kódu, klidně i pomocí nějakého php_flagu který by zapnul podporu legacy funkcí a klidně by to mohlo běžet na poslední verzi php.
Např. drtivá většina webů, které nejdou z 5.6 přemigrovat na 7.x je jen o tom, že mysql_xxxx fce se nahradily mysqli_xxxx. Další vypnuté fce a chování málokdo používal. -
Zrovna mysql_ prefix by slo resit povinnym preload includem v php.ini :)
Nezkousel jste se divat, zda neexistuje nejaky projekt, ktery by resil tyhle nekompatibility? (jiste, za cenu ztraty vykonu).
Ale vetsi problem budou treba vyzadovani [idx] namisto {idx}, to uz je problem syntaxe a nevim zda php ma moznost neceho co by bylo ekvivalentni c-preprocesoru, aby si sahl na zdrojak pred parsovanim.
-
Což je všechno práce, kterou někdo musí udělat. Proč musí všechno oddřít vývojáři jazyka? Neměla by tam být nějaká spolupráce o rozdělení nákladů?
Působíte na mě jako někdo, kdo si naivně ukousl ten krajíc, že prostě nebude uživatelům říkat špatné zprávy. To je prostě vaše blbé rozhodnutí, ne chyba jazyka.
-
Ono platí takové pravidlo, když něco roz....ám, tak si to taky po sobě opravím.
Když se to umí (třeba jako pánové Kernighan a Ritchie), tak to funguje, právě teď, koncem roku 2023 jsem pokusně přeložil program v K&R dialektu s -Wall -Werror. Ale holt co si myslet o projektu, kde se dělají nekompatibilni změny dokonce mezi minor verzemi...
Jo, že je moderní, agilní, .... a výsledkem je, že je Internet plnej děravejch verzí.
-
Ale to je přece zcela normální, že ve vývoji se nějaká funkcionalita či vlastnost označí za depricated a následně dle plánu odstraní. Děje se to v programovacích jazycích a stejně tak i v dalším SW. On i ten Cobol či Fortran ( tedy jazyky, kterými se programovaly před mnoha dekádami sálové počítače ) nejsou stejné jako tenkrát ... a i tehdy v nich docházelo k nekompatibilním změnám.
Projekt který je živý, tak má dost času se se změnami vyrovnat a produkt upravit. Navíc se dnes často využívají frameworky, které tyto změny do značné míry pokryjí.
Souhlasit lze ale s tím, že životní cyklus PHP by skutečně mohl být delší. Z druhé strany tu jsou všude kolem nás běžně projekty běžící stále na PHP 5.6 - tedy produkt releasnutý před více jak 9 lety a již cca 5 let mimo support. Přestože byla podpora této verze mimořádně prodloužena, tak to reálně ničemu nepomohlo.
-
> Souhlasit lze ale s tím, že životní cyklus PHP by skutečně mohl být delší.
Si myslím, že ne.
Vývojáři prohlásí dva roky.
Progresivní distribuce přidaj rok, aby se neřeklo.
Konzervativní distribuce přidaj třeba deset let.Já jako klient té aplikace budu balancovat, co je pro mě výhodnější. Čím více mi to vývojáři a distributoři usnadní zůstat u toho kde jsem, tím spíše nehnu zadkem. Jenže pak když to bude třeba, tak to zase může být příliš velký skok, a mě to přijde drahé upgradovat... Chce to ideálně někde ten střed. Takovej rozumnej tlak na upgrade, aby to příliš nezahnilo, ale zase nic zběsilého, abych nemusel fixovat co měsíc jako v nodejs.
-
DannyStříbrný podporovatelAkorat ten tlak na upgrade narazi na... obligatne na ty prachy :-) Protoze vsichni chteji ve svych aplikaci nove featury a na nejaky refactoring... budget casto nezbyva, protoze to navenek navic nic noveho navenek viditelneho neprinese. A ve vysledku je to krasna tikajici bomba - co se jednou projevi tim, ze skrze nejakou aplikaci provozovanou na obstaroznich a davno nezaplatovanych verzich knihoven vam utecou firemni data, jo to pak videt uz je :-) Ale samozrejme ti, co rozhodli ze se nic prepisovat nebude a udrzi se stare verze za kazdou cenu se pak k (manazerske) odpovednosti nehlasi ;-)
