PHP 7 end of life

PHP

A PHP Projekt bejelentette, hogy a PHP 7.4-gyel véget ért a PHP 7-es ágának támogatása. Használóinak célszerű mielőbb a 8.0/8.1 ágra váltani.

( uid_6201 v | 2022. 11. 28., h – 16:29 )

Majd ha a Linux disztribúció sem támogatja. Debian esetén még kb. 2 évig támogatva lesz, sőt lehet hogy lesz LTS ág.

 

Ubuntu 22.04 LTS is ezzel jön, ha jól látom... Úgyhogy az upstream-ben kimondott EOL-hoz képest ott is jóóóósokáig támogatott lesz. Mondjuk az érdekes, hogy a 22.04 kiadásakor azért már lehetett talán látni, hogy a hetes széria EOL igencsak ott toporog az ajtóban... Gondolom azért maradt mégis, mert a retek sok motyó, amit a 22.04 szállít, és php-függése van, az nincs felkészülve az újabb verzióra - majd talán a következő (utáni (utáni (...)) lts-ben...

( ggallo | 2022. 11. 28., h – 16:51 )

Szerkesztve: 2022. 11. 28., h – 16:53

A világ halad, a felhasználók nem annyira...

Migrátunk mostanában olyan 10 éve működő weboldalt ügyfél részére, aminél "imádkoztunk", hogy legalább PHP 5.6-tal működőképes legyen az addigi 5.2 után, mert 5.6-nál régebbi nincs a cél szerveren... A felhasználó persze azt mondja, neki eddig tökéletesen működöt, miért fizetne azért, hogy bárki hozzányúljön 7.x vagy pláne 8.x kompatibilissé tenni... Az, hogy biztonság, teljesítmény, stb., nem érdekli az utca népét.

Mondjuk ez a Java világában is így van, ahogy látom, mert ott is van még kuncsaftnál progi ami 1.6-ot kér maga alá úgy, hogy elvileg aktív program, nem elhagyott... De a fejlesztő szerint jól van az úgy. Fel lehet tenni, nem? Akkor mi a baj?...

PHP weboldal témában nem a PHP verzió lesz az issue, hanem maga a CMS, amin keresztül felszórják a malware, datingservice, phising és minden terjesztőt, esetleg kódolnak, de az ritka. Ha esetleg frissítik a CMS-t, akkor már az hozza magával az újabb PHP-t, de bőven csak a 7-es családra néznek.

Az az alapkiindulópont, hogy ő eccer kifizette és annak márpedig működnie kell, most nem létezik, hogy már baj legyen vele... Ha pedig megáll (pl. amikor beszórják Dr Malwarez-t az index.php -ba), akkor percenként milliós buktáról, meg elképesztő elfogadhatatlan dolgokról írkál gyorsabban, mint egy nagios (nem vicc).

Végülis ha veszel egy kalapácsot, elvárod hogy ne menjen tönkre 10 éven belül.
Egy szoftver terméknek miért kell olyan dolgokat tartalmaznia, ami miatt állandóan tutujgatni, módosítani, cserélgetni kell?

Tudom ... ezer indokot tudok felhozni jelen állapotokból.
De valahol egyébként tényleg nem normális ez a szemlélet.

Ezt meg kell beszélni a fejlesztésmániásokkal, meg hogy kidobunk mindent, mert jön a szupcsi új cucc, különös tekintettel a buzzwordokre. Egyébként egy ősrégi CMS-hez amúgy sincs már támogatás. Talán Wordpresséknél jönnek ki secfixek régiekhez, de a többiekre nem annyira jellemző.

Konkrétan 31 éve reszeltem ki kézi erővel a kalapácsomat (két furat kivételével), aztán faragtam hozzá nyelet. Édesapám barátja a kovácsműhelyében megedzette.
Köszöni szépen jól van. Sok apró szeget bevert már. A tanműhelybeli sorszámom ("6") bele van ütve, ezzel együtt külön szép emlék.

Másik ilyen szépség: mikrohullámú ételmelegítő. Már szintén 20 éves, jól megsárgult a burkolata de köszi nem akarom lecserélni.
Harmadik érdekesség: ipari rádióink szintén 20 évesek. Egyetlen komoly probléma jelentkezett már 10 éves koruktól. Ha frekvenciát kellett átkonfigurálni, a szoftverhez Win98-nél nem "korszerűbb" PC-t kell szerezni. Itt is a szoftvere a szűk keresztmetszet. Bár a hardver is lassan cserélve lesz, huszonév után.

> mikrohullámú ételmelegítő. Már szintén 20 éves

anyameknal kozel 40 eves samsung mikro van, meg Becsbol hoztak a 80-as evekben, sose volt javitva, naponta tobbszor van hasznalva azota is... a kijelzoje mondjuk mar alig latszik, ilyen vakumcsoves zolden foszforeszkalo fajta, nem tudom a pontos nevet.

de ugye mint tudjuk, regen minden jobb volt... akkor meg nem volt annyira divat a tervezett avulas meg a fillerbaszo sporolas az alkatreszeken mint manapsag.

szerk:  https://en.wikipedia.org/wiki/Vacuum_fluorescent_display

Ha plusz funkció vagy teljesítmény kell, akkor az nyilván pénz, és akinek ilyen igénye van, az rendszeresen fejleszti a cuccot, ami magával hozza az újabb PHP verzióra átállást is.

Aki viszont nem ilyen user, azt tájékoztatnia kellene a webfejlesztőnek (vagy weboldal előállító kisiparosnak), hogy a használt CMS/egyedi fejlesztés idővel biztonsági frissítéseket fog igényelni (mert az kizárt, hogy valaki sérülékenység-mentes progit írjon, a weben meg fokozottan ki vannak téve a támadásoknak), ami esetleg az oldal módosítását, kiigazítását is magával hozhatja. Azt pedig pénzbe kerül majd.
Persze a legtöbben az egyszeri lóvéra hajtanak, és nincs utánkövetés/támogatás, a user-ek meg nincsenek rendesen tájékoztatva és nem terveznek támogatásra összeget emiatt.

Szerintem az IT világban nem igazán megoldható ez a veszek egy kalapácsot és az legyen jó dolog, de az biztos, hogy máshogy kellene kezelni az egész "fejlődést".

5.2->5.4+ azert necces, mert ott valtozott az input parameterek kezelese, magic_quotes vagy mi. en jartam ugy, hogy frissitettem egy oldal alatt 5.2-rol 5.4-re es rogton feltortek, mert a php kivezette az input validaciot vegzo beepitett featuret es ezt onnantol a php-ben irt scriptnek kellett volna csinalnia (ami amugy jo dolog, csak ha erre nem figyelsz, akkor siman a frissites tobbet art mint hasznal)

https://en.wikipedia.org/wiki/Magic_quotes

na meg az eltavolitott funkciok, amik miatt majdnem minden verzio valtaskor at kell irnom a programokat.

legjobb, ha minden php funkcio wrapperben van, akkor csak 1 helyen.

persze megertem a masik oldalt is, ingyenesen hasznalhatom, kevesebbet kell karbantartaniuk.

neked aztan fura humorod van...

masik hogy ha a CMS 100 tamogatja a PHP x-et, a CMS 101 mar csak a PHP y-t, a stabil disztribucioban pedig a PHP x van, de a CMS-t frissiteni kellene, mert a CMS 100-at mar nem tamogatjak biztonsagi frissitesekkel, a disztibucio pedig amiben PHP y van meg nem stabil. ertem en hogy ok egy masik disztribuciot hasznalnak, ahol mar PHP y van, meg ingyen van a CMS, akkor is problema. ezek a multban sokkal kevesbe, de a jovoben egyre gyakrabban fognak elofordulni.

neked aztan fura humorod van...

hat ez mar eleg regota problema... anno erre hasznaltuk a phpfarm nevu csodat, ubuntura meg ott a sury-fele ppa, amiben 5.6-tol kezdve latestig minden php verzio megtalalhato es egymas melle parhuzamosan telepitheto.  igy siteonkent (fpm-el) lehet allitani tizedenkent a php verziot, es az egesztul fuggetlenul lehet az ubuntut is upgradelni.

https://launchpad.net/~ondrej/+archive/ubuntu/php

A CMS saját hivatalos konténerét (vagy saját építésűt) kell használni, amit egyrészt frissen tartanak, másrészt a függőségek optimális verzióit rakják bele. A disztróból "apt install" telepítés már nem a javasolt megoldás.

Ha nincs ilyen a CMS-hez, akkor el kell gondolkodni, hogy biztos jó-e az a szoftver, másrészt találtál egy piaci rést, amit esetleg be lehet tömni egy termékkel...:)

Hogyúgyvan, mondaná egy tanult kolléga... A "legjobb", amikor ügyféligény okán a portálmotorba magába piszkálnak (vagy piszkítanak?) bele "testreszabás" (vagy inkább ügyféligány (sic!)) címszóval... Aztán lehet az péhápépistike, vagy épp nagy cég, ha nem óhajtja a továbbiakban támogatni a tákolmányt, akkor az üf. ott marad a sz@rkupaccal, amit se frissíteni, se bővíteni nem lehet, hogy a főverziók közötti migrálásról ne is beszéljek...

Mindig oda érünk el, hogy a hozzá nem értő, de szoftverfejlesztést vállaló emberek miatt vannak a gondok... Rendes fejlesztő ügyféligényre sem meg másra sem csinál ilyeneket, hanem megcsinálja rendesen. De sajnos ez a ritkább.
A legjobb kombó, mikor a nem-eléggé-hozzáértő "fejlesztő" találkozik a lehetetlenül-rövid-határidőkkel-vállaló munkáltatóval és beesik hozzájuk az "ügyféligény" egy laikustól aki látott/hallott valamit valahol...

Én mindig mondom, hogy a programozás 1) nem olyan egyszerű mint sokan mondják/gondolják, 2) születni kell rá, megtanulni csak egy bizonyos szintig lehet képesség nélkül, 3) nem való mindenkinek/bárkinek.

PHP esetén, hagy mondjak egy példát. Míg sok-sok évvel ezelőtt egy asszociatív tömb kulcsához nem kellett idézőjel, ma már kell, különben fatal error, mert újabban konstansként értelmezi a PHP.

Erre, hogyan lehet előre készülni?

Értelmesebb programnyelvet használsz. ¯\_(ツ)_/¯

Egyébként az a sok-sok évhez: szerintem már a PHP4-nél is warningolt rá (persze, azokkal ki foglalkozik...). Valamikor 2003-4 környékén írhattam az első PHP-s kódom, szerintem már akkor sem konstansként írtam le... PHP 5 meg 2004-ben jelent meg.

Mondhattam volna a nullával való osztást is, ami a típusosság hiányában false volt az meg nulla. Ma már ez is kivételt dob. 

Voltak olyan dolgai a PHP-nak, ami a hiányosságából fakadó előny volt. Én magam is kihasználtam ezt, ezeket később át kellett írni.

Lehet egymásra mutogatni, hogy akkor ez kinek a hibája, de szerintem felesleges.

Viszonylag kevés, az is többnyire PHP-vel. Pont azért, mert ami smelly volt, azt nem használtam és alapvetően törekszem a warning free kódra. Nyilván van, amikor én is tudatosan ignorálok warningokat, bár arra jobb nyelveken van mód, hogy explicit kifejezd, hogy itt te most figyelmen kívül akarsz hagyni.

Amire emlékszem az 5.0-5.1-5.2 környékén némi dinamikus hívás a variable call környékén, ami egyik verzióban jó volt, másikban syntax error, harmadikban félig bugos, stb. Reflection API valószínűleg tisztább-szárazabb élmény lett volna összességében, főleg, hogy iszonyú smelly dolgokat volt képes csinálni. (Pl. static member methodba belehívsz akkor megkapja a hívó osztályt a $this-ben, csak hát egy static memberben mit keres egyáltalán $this...)

Viszont a tapasztalat meg úgy általában az, hogy jellemzően akik programnyelveket fejlesztenek, azok átgondolják, hogy mit csinálnak és nem szoktak eltörni dolgokat csak úgy. Nyilván van máshol is, csak ott általában az van, hogy egy új feature miatt lesz valami többértelmű és egyértelműsíteni kell a dolgokat. (pl. C#-ban voltak/lesznek most ilyesmi törések). Ezzel szemben a PHP fejlesztési metodikája meg az, hogy használjanak héber tokenneveket, mert kb. a csapat szerint vicces, szakmai érv a döntés mögött meg nuku.

Egyébként az általad említett dolog, hogy implicit konstanst használtál a hashmapek kulcsának (már eleve az, hogy arraynak hívják, ami egyszerre viselkedik tömbként, hashmapként és objectként, brrr..). Ez még egy picit is haladóbb juniornak is smellynek kellett volna lennie:

  • Warningol rá az alap beállítások alapján, önmagában figyelemfelkeltő.
  • PHP-ben a hibakezelésre rá lehet ültetni saját kódot, így akár esetenként komoly performancia veszteség is lehet belőle
  • Eleve smelly, hogy nem egzaktul definiált a konstansom. rendben van, hogy leírom, hogy $arr[cica], de mi van, ha a cica konstans közben definiált "kutya"-ként?
  • Egyáltalán miért akar bárki is nem definiált konstansokat használni?
  • medior szintű kérdés: egyáltalán biztos, hogy nekem ott egy hashmapra van szükségem és nem pedig egy jobban definiált adatstruktúrára, egyértelműen kifejtve az adatmodellem? Tesztelhető lesz-e egyáltalán a megoldásom? Nem fog eltörni egy változtatásnál? Stb.

Szóval nem, a implicit konverziós konstans, mint kulcs egy hashmaphez 15+ évvel ezelőtt sem volt jó ötlet, hiába engedte a nyelv. És ezek nagyja nekem mind olyan "előnynek" bizonyult, ami hosszú távon szinte mindig plusz, extra szívást hozott be, hibát fedett el, stb. Egyszerűen nem éri meg ezeket lecsapni, mert vissza fog ütni előbb-utóbb.

Ez most nem arról szól, hogy OOP-e vagy sem, OOP nélkül is nagyon szép dolgokat lehet csinálni, meg nem OOP-re kitalált nyelven is lehet nagyon szép OOP kódot írni. (példának okáért hozhatnám a Quake 2-t).

Inkább csak arról szól az egész, hogy a "megoldjuk okosba'" nem csak az élet más területein tud visszaütni.

"medior szintű kérdés: egyáltalán biztos, hogy nekem ott egy hashmapra van szükségem és nem pedig egy jobban definiált adatstruktúrára, egyértelműen kifejtve az adatmodellem? Tesztelhető lesz-e egyáltalán a megoldásom? Nem fog eltörni egy változtatásnál? Stb."

 

Erre írtam.

Értem, de ez betudható annak is, hogy alapvetően öntanuló módon csináltad az egészet és ráadásul még csak nem is a szakmád/szakterületed, amennyire tudom. És azt gondolom nem kell mondani, hogy mennyit számít, mikor vannak tapasztalt emberek, akik tudnak segíteni, iránymutatást adni.

Volt, hogy nekem is jól esett egy nem szoftveres cégnél szoftverfejlesztőként dolgozni, de utána onnan már csak a szakmai fejlődésem szempontjából is egy kifejezetten szoftveres céghez akartam menni.

Nem szakmám, műkedvelőként vagyok itt  a hupon. Lényegében ezen az ERP rendszeren tanultam meg kódolni.  Már amennyire megtanultam.* Azóta egyetemen tanulom ezt (két félévem van még hátra). Ebből már csak 1 programozási tárgyam maradt. Bár ezt is már felvettem korábban, csak olyan csapatot kaptam amivel/akikkel reménytelen volt a csoportos beadandó elkészítése, így elengedtem a tárgyat. Egyedül meg nem volt kedvem több ember helyett dolgozni a projekten.

Az éltem nagy részét, mint diszciplína az informatika tette ki. Széles és lapos ismereteim vannak a témában. Mindig annyit tanultam, hogy az alapvető feladataimat ellássam egy elégségesen jó szinten. Csak a hasznosságot néztem.

*A PHP mint nyelv korlátossá teszi a programozási tanulást, már csak azért is, mert az objektumok élete túl rövid. Többször felmerült bennem, hogy más technológiára építem fel újra a rendszert, de még nem vagyok rá elég motivált. 

Már amennyire megtanultam.* Azóta egyetemen tanulom ezt (két félévem van még hátra).

Az a baj, hogy az egyetemi oktatás az kb. a beugró szint. Rendesen programozni valaki megtanulni már munkahelyen fog megfelelő iránymutatás mellett. Egyetemen tudnak adni jó alapot, de arra már nem építik fel a házat.

Széles és lapos ismereteim vannak a témában.

Ami egyfelől jó, másfelől pont az ilyen jellegű dolgok esetén veszélyes, mint amit említettem is. De ahogy írtad, műkedvelő vagy, nem hivatásos fejlesztő.

Mindig annyit tanultam, hogy az alapvető feladataimat ellássam egy elégségesen jó szinten.

Csak vajon a szakma is ugyanazt gondolja-e az elégséges szintről, mint te? Ez itt a kérdés. Egyébként a te helyedben én se tettem volna másképp.

már csak azért is, mert az objektumok élete túl rövid.

Nem igazán oszt-szoroz, hogy milyen hosszú az életciklusa.

Többször felmerült bennem, hogy más technológiára építem fel újra a rendszert, de még nem vagyok rá elég motivált. 

Valószínűleg nem sok értelme van. Újraírni egy meglévő rendszert viszonylag ritkán van értelme/haszna.

"Csak vajon a szakma is ugyanazt gondolja-e az elégséges szintről, mint te? Ez itt a kérdés. Egyébként a te helyedben én se tettem volna másképp."

Az nem számít. (Bár amit eddig láttam az alapján semmi okom a szégyenre.) A legfontosabb, hogy az üzleti cél teljesült.

Tisztában vagyok vele, hogy aki egymagában kódol az sohasem fog magas szinten kódolni. Zéró visszajelzés mellett még a belső igény a jobbra is kevés. Rengeteget olvastam a témában, hogyan lehetne jobban csinálni, de ez önmagában kevés. Az kell, hogy valaki rámutasson a hibáimra és elvárás legyen annak kijavítása. Önmagunkkal szemben megbocsátóbbak vagyunk, mert elég vigaszt nyújt a tudat, hogy tudnánk jobban is csinálni.

2) születni kell rá, megtanulni csak egy bizonyos szintig lehet képesség nélkül

Ebben újabban már nem vagyok biztos. Az félrevezető, hogy amíg bizonyos szakmákat 10-15 évig tanulsz, mire elfogadható szintre jutsz belőle (és ezt mindenki elfogadja), addig a programozást valamiért mégis 3-12 hónapos bootcampeken oktatják.

Ahhoz, hogy 3 hónap alatt megtanulj junior (de használható) szinten programozni, ahhoz tényleg kell valami gyári tehetség. De ha mondjuk (hogy ilyen demagóg példát mondjak :)) az orvosi képzéssel hasonlítod össze, akkor oda sem elég/kell önmagában a tehetség, "csak" a 15-20 év kemény munka.

Inkább az a félrevezető, hogy oké, hogy eljut valaki junior szintre, de utána mi van. Mert addig tök jó, ameddig utána a junior bekerül néhány senior keze alá, aztán tanul tovább, lát dolgokat, stb. (mint ahogy kb. minden más szakmában is valahol ez a normális), addig itt meg a junior kikerülhet bárhova.

Csak egy példa, covid alatt elkezdtem hobbiból fával dolgozni, illetve citerákat készíteni. Oké, hogy ma már tök sok mindent meg lehet tanulni internetről, de nagyon látom a különbséget aközött, amit pl. HauchTomi csinált, aki a hagyományos képzésről tett fel videókat és aközött, ami az 5-10 perces (jellemzően látványos, amcsi) Youtuberasztalos videókban van, ami kb. a 2 perc alatt elolvasható tutorialok színvonala: van nagyon sok olyan tudnivaló, amit csak évek alatt, tapasztalattal szed magára az ember és nem mindig triviális, hogy mi miért hülyeség. Nemrég 4 ujjamon 7 helyen sikerült kicsit megvágnom magam (szerencsére inkább csak felszínen és inkább csak kellemetlen volt, de lehetett volna sokkal rosszabb is) az anyaggal, mert megpörgette a maró, mert hülyeséget és hülyén akartam csinálni, illetve meg akartam spórolni némi munkát. Ugyanilyen a kezdő programozó is, csinálnak sok hülyeséget és ha nincs mellette egy tapasztalt ember, aki időben a körmére csapjon, akkor meg fogja vele magát égetni. Valószínűleg nem az ujjait vágja el vele, de valakinek egyszer még komoly gazdasági kárt fog vele okozni. Rosszabb esetben egy olyat, amibe egy komplett cég belebukhat.

a tenyeken nem valtoztat.

most pl. owncloud changelogban talaltam:

Function `utf8_encode` will be deprecated and removed in future PHP versions. It has been replaced with function mb_convert_encoding.

megneztem, szerencsere itt csak az fpdf tartalmazza.

debian stable php7.4-ben nincs a logokban, kovetkezteteskeppen vagy nem fut ra a program (nem neztem) vagy majd csak 8.0-ban fogja logolni, de a kovetkezo debian stable-ben ha mar 8.1 lesz, akkor ezt nem fogom latni, csak egyszeruen belefutok.

ezert a frissitesi strategia, hogy teszt vm-ben frissitem a rendszert, atszinkronizalom a programokat, ami nem mukodik atirom, mielott az eleset is frissitenem.

neked aztan fura humorod van...

Az is megoldás lenne, ha az elterjedtebb disztrók (mint pl. a Debian) és az elterjedtebb alapszoftverek (mint pl. a PHP) valami módon egymáshoz igazítanák azokat a változásokat, ami várhatóan komolyabban érinti a rájuk épülő rendszereket. Így nem merülne fel, hogy felteszi az ember a friss, aktuális Debian 11-et és azzal szembesül, hogy abban a már EoL PHP 7.4 érhető el... Oké, majd adnak ki a 7.4-hez secfix-et, ha felmerül valami. De ez akkor sem jó így. A Debian 12 meg még majd csak lesz valamikor jövőre, és semmi garancia, hogy a Debian 12 életciklusa alatt nem lesz EoL a PHP 8.1...

mondjuk a debianban mindig 3+ eves verziok vannak mindenbol megjeleneskor. ububan meg 1+ evesek. slackware meg siman sec update-el lecserelte a php verziot...

ha valahol van letjogosultsaga a rolling releaseknek az pont a webszerver. vagy vannak a workaroundok, mint ubihoz a sury-fele ppa amiben van 5.6-8.2 minden php verzio, azt rakod fel amelyik epp kell.

hat mi mar vagy 5-6 eve hasznaljuk elesben eleg sok prod szerveren, tobb 100 site megy rola foleg 5.6 es 7.x verziokkal, ujabban mar 8.1 is van par. nem volt sose gond vele. ha jol lattam a ficko valami tarhely szolgaltatonak/nal dolgozik, szoval vszinu tudja mit csinal.

nyaron frissitettem alatta az ubi 18-akat 22-re, nem tort el semmi, meglepo modon.

elotte regen phpfarm-oztunk, de minden al-al verzio frissitesnel vagyha plusz modult kertek ujra kellett buildelni az egeszet forrasbol, meg kitalalni epp milyen -dev csomag hianyzik neki...

Akkor ne nyúljatok neki hozzá. Majd hirtelen fossa össze magát a rendszer, elkezd nem működni, valami kritikus folyamat okoz bevételkiesést, lehet nekik jó távoli javítási időpontot mondani, nem sürgős, múltkor még azt mondták, hogy tökéletesen működik, minek nyúljon hozzá bárki.

Az 5.2 konkrétan egy 16 éves verzió, a támogatása is 11 évvel ezelőtt szűnt meg. Nyilván annyi idő nem volt neki elég a váltásra, kéne egy kis haladék. Csak minek. Az a baj, hogy nem értik, hogy a szoftver nem olyan, mint egy elektronikai eszköz, hogy megveszed, működik, azt hiszik, hogy örökké fog menni. Működik, de cserélődik alatta az OS, hardver, és kompatibilisnak kell maradni, hogy migrálni lehessen másik rendszerre, mikor a jelenlegi vas, megoldás kihal, nem működik többé.

11-16 év ráadásul nagy idő, az kb. olyan, mint mikor valaki a 2000-es évek közepén még DOS-os rendszerhez ragaszkodott volna.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> Az 5.2 konkrétan egy 16 éves verzió, a támogatása is 11 évvel ezelőtt szűnt meg.

csak 11? gyanus, mert 2013 korul mar iszonyat nehez volt 5.2-t felszenvedni egy rendszerre, reg kivezetett 0.9 verzioju openssl es hasonlo regeszeti leletek voltak a dependecyk hozza. bar vegulis az csak 9 eve volt.

> mint mikor valaki a 2000-es évek közepén még DOS-os rendszerhez ragaszkodott volna

van ugyfelem ahol meg dos-os konyveloprogramot hasznalnak, amit meg valamikor a 90-es evekben vettek... letezik mar neki eleg reg windozos verzioja es meg is vettek volna, de az adatok migralasra olyan horror arajanlatot kaptak hogy vegul inkabb maradtak a dos-nal :)

> működik, azt hiszik, hogy örökké fog menni

magyarazad ezt el mondjuk regeszeknek, muveszettorteneszeknek, restauratoroknak.  azzal fognak jonni, hogy ok sem festik ujra a mona lisat par evente, ha megjelenik egy korszerubb festek...

Na jó, de úgy nem nehéz, ha csak egy replika van az internetre kötve valódinak tűnő ecsetvonásokkal, míg az eredeti festmény a pincében van jól elzárva, biztonságban, szinte senki által nem hozzáférhetően...

De tőlem lehet ilyen adatbázisuk is... csak 5 méterről nézegethetik és nincs nyúlka-piszka :)

> De tőlem lehet ilyen adatbázisuk is... csak 5 méterről nézegethetik és nincs nyúlka-piszka :)

ezek (nalunk) ilyenek... 10+ eve valami EU vagy egyeb palyazatbol lefejlesztettek, digitalizaltak bele egy csomo muemleket/kepet/zenet/szamokat/akarmit, azota meg csak nezegetik. de mar se penz se akarat nincs a fejlesztesere, de az orokkevalosagnak szantak, azt szeretnek ha unokaik is latni fogjak... hisz ezert digitalizaltak, de szerintem az eredeti tul fogja elni a digitalis masolatot :(

Ez pontosan így történt. Áttettük, látszólag működik, innentől részünkről kész. A webszerver üzemeltetést adjuk alá, nincs magához az oldalhoz egyéb közünk.

Az utosó mondatra: el kell áruljam, van olyan ügyfelünk, ahol azért van a mai napig Win7 32 bit telepítve (internet elérés oda-vissza letiltva már egy ideje...), mert azon tudja futtatni a kb. 100 ügyfél könyveléséhez mai mapig használt DOS-os, igazi karakteres felületű (!) szoftverét... Nem is tudom nevessek vagy sírjak. Semmi módon nem tudjuk rávenni, hogy lecserélje valami maira, ami ráadásul a munkáját is nagyban könnyítené, nem csak a mi életünket.

Egyszer még réges-régen előző munkahelyemen szóba került a PHP és a teljesítmény kérdése. Aztán kimértük, átlagosan egy oldal legenerálásának idejének 90%-a az adatbázis oldalon ketyegett. Onnantól kezdve alapvetően csak a PostgreSQL-ben optimalizáltuk a dolgokat, meg ha valami látványosan lassú volt. Nem érte meg vele szöszölni.

Verzióváltásokat persze megcsináltuk.

Hja ez arany. Nyilvan erosen tulzo de kurva sok igazsag van benne.

Szeretem mindig interjun megkerdezni a delikvens mondja el a monolith es microsrvice architecture elenyeit es hatranyait.
Eskuszom 10 bol 9 nem erti a kerdest, hogy hogyan lehet elonye a monolithnak es hogy lehet hatranya a microservicenek...

http://www.youtube.com/watch?v=xnJwT_30p6k

Nekem az a kedvencem, amikor fejlesztők devops-ok akarnak lenni, minden szavuk az, hogy hogyan kellene valamit Kubernetessel, Dockerben, <random divatszó>-ban megoldani, miközben a saját gépükön futó Windowson kikapcsolják a tűzfalat meg az összes beépített security funkciót, mert azok bekapcsolt állapota mellett nem tudnak fejleszteni/tesztelni. Azért nem tudnak, mert a Windowsban idestova 22 éve megjelent tűzfal szolgáltatásban nem képesek egy darab custom szabályt sem felvenni. Nem értik, nem ismerik a működését. Ezek után azt hiszem, hogy nem a devops-szal kellene kezdeniük.

Napjainkban futó, igaz történet ^^^

trey @ gépház

megtortent eset alapjan: devops magusunk osszekokanyolt egy webes adatbazist, sok millioert, ami allt 4db docker kontenerbol. az egyikben volt a postgres db. igen, benne! igen, nem perzisztensen. aztan amikor a host gep meg lett frissitve es rebootolva, eltuntek az adatok, orokre. oh yeah. na jo nem, mert volt backup es abbol elo lehetett valahogy vakarni, de ez akkor is milyen design?

Jesszumpepi. Nálunk egyetemen voltak üzemeltetés témájú választható tárgyak (tartományok, routing protokolok gyakorlatban, ésatöbbi, bár maga a hálózat kötelező volt, gyakorlattal, meg is jegyezte annó itt egy fórumtárs, hogy sok átfedés volt a CCNA anyaggal, ami szerintem nem is volt akkora baj). Talán nem ártana kötelező panelbe is betenni pár ilyen tárgyat. Én fel is vettem többet is, mert érdekelt.

( influencer | 2022. 11. 30., sze – 14:42 )

Már az 5.x verziótól kezdve ideálisabb lett volna jobban átgondolni, többet tervezni, majd kevesebb főverzió létrehozása és hosszabb ideig támogatása.
Nagy felelőtlenség a PHP nyelvet fejlesztőkről, hogy ilyen gyorsan haladnak és így elengedik a régi verziókat.
Könnyű okoskodni, de úgy lett volna ideális a PHP nyelvet fejleszteni, hogy amit már kitaláltak, az fix, és az új verziók lefelé kompatibilis. Tehát az 5.x kódbázis fut a 8.x verzión, de nem használja az újabb funkciókat, viszont működik.
Esetleg úgy megoldani, hogy mint egy kompatibilitási szint, az 5.x támogatott a 8.x verzióban is, ha jelezve van a kód elején, hogy az PHP 5.4 forrás, akkor a 8.x az 5.4 verzióhoz való binárisokat tölti be, ami biztonságilag karban van tartva.

Talán soha nem fog eltűnni az 5.x-es PHP, mert nincs annyi kapacitás, hogy átrakják 8.x verzióra az összes olyan kódot, ami egyszer a célnak megfelelő volt, de nincs 8.x alternatívája elérhetően.

Nem lehet megbecsülni, mennyi munkaóra ment el a világban azzal, hogy a meglévő, megfelelő kódot új PHP verzióra rakták át. Mert valaki helyettük eldöntötte, hogy kell.

azt nyilvan nem varhatjuk el hogy 5.x kod fusson 8.x-en vagy 7.x-en, de legalabb arra figyelhetnenek, hogy a 7.x egyes alverzio egymassal kompatibilisek legyenek legalabb visszafele, tehat 7.4-el mukodjon a 7.0 vagy 7.2 ala irt kod is. de meg ez se sikerult nekik. az 5.x-rol nem is beszelve, ott minden alverzioban varialtak a szintaxist meg a mindent is... ahogy a 8.x eseten is.

akkor eleg lenne 5.6, 7.4 es 8.latest karbantartani (es supportalni a szervereken) a mostani kb 10 fele verzio helyett.

meg a python import future-hoz hasonloan megoldhatnak hogy pl. a 7.latest-ben is lehessen opcionalisan hasznalni 8.x dolgait, hogy egyszerubb legyen mindket verzioval kompatibilis kodot irni. meg a python 2to3-hoz hasonloan irhatnanak kod migralo/konvertalo toolt... de inkabb magasrol szarnak az egeszre :)

a fejlesztok leszarjak ok a sajat gepukon futo WAMP-ban epp levo php-vel dolgoznak. aztan feltoltik a tarhelyre es csodalkoznak ha nem megy, es nyomjak az ugyfel fele hogy "hat szar a szerver, nalam mukodik, nezze meg", innentol a szopofaktor at van passzolva az uzemeltetoknek...

Ne is modd! Mennyi ügyfél levelezése romlott el, mert a fejlesztő legyártott csodája nem működött az aktuális webtárhelyen, és az ügyféllel együttműködve (az üzemeltetést kihagyva) bérelt máshol (szigorúan cPanel!) webtárhelyet, de az egyszerűség kedvéért a DNS zónát is átkérték oda (mert fogalma sincs a legtöbbnek, hogy a weboldal címe egyetlen rekord a DNS-ben amit át lehet írni, és nem kell egy szerveren lennie a weboldallal a teljesn DNS zóna kiszolgálásnak), és onnantól rossz helyre mutatott az MX... A user meg hív, hogy nem jönnek-mennek a levelek. Ő semmit sem csinált, más sem csinált semmit, csak úgy elmúlt...

igen, ismeros...  ennel mar csak az a jobb, amikor valamelyik nagy szolgaltatonal berel tarhelyet, amihez kap "ajandekba" par email fiokot is, amit nem hasznal. az MX hiaba nem mutat oda, a szolgaltato mailszervere ugy gondolja, hogy o a destination arra a domainre is, ezert annak a szolgaltatonak a tobbi ugyfele nem fog tudni levelet kuldeni nekik. es mire ezt megmagyarazod a szolgaltatonak a 3 szintu supporton keresztul, hogy toroljek mar ki a pitsaba a mailszerverukrol a domainunket mert nem naluk levelezunk...

Úgy-úgy! És amikor Google Workspaces-ben marad így bent levelezési tartomány, és a fél @gmail.com feladó levele oda kézbesül a valódi MX által mutatott szerver helyett... A Google-nál hívjon az ember fel valakit, hogy vegyék már ki... :-D
Akkor derül ki, amikor az átállás után nem jönnek a levelek: hogyegyébként azért jöttek hozzánk, mert elvesztették a hozzáférést a Google rendszerhez, és azt hitték (a szomszéd Pisti azt mondta) elég DNS-t variálni meg máshol előfizetni...
Persze a Google Workspaces-t a másik szomszéd Pisti intézte 10 éve, már fogalma sincs milyen e-mail címmel regelt és azóta már asztalos, hagyjuk ezzel békén. Aztán 3 hét alatt sikerült a nemfizetés miatt teljesen letiltott acc-hoz admin hozzáférést szerezni, újra előfizetni és intézkedni...

Én csak pár év üzemeltetési gyakorlattal adnék fejlesztő diplomát :)

Az egyik cég ahol dolgozom, kb az egész életük a weben megy és a doménjük űrebkritikus, új webshop-ot készíttetett. Én már az elején jeleztem, hogy nem biztos, hogy a wordpress a világ legjobb webshop platformja, de lehurrogtak, hogy ezek profik. Elkészült a nagy mű és jött a kérés, hogy regeljem át nekik a DNS szervereket (igen cpanel+worpress) jött a pislogás amikor szimplán azt válaszoltam, hogy nem. Jött a hiszti, hogy az feltétlenül kell (!) nekik a weboldal működéséhez...
Na itt kissé aljas módon, megkértem pontosan írják le mire van szükségük, és utána, hogy lesz beállítva az új DNS szerver. Elküldtek egy cpanel doksit, meg az IP-t ahol van cpanel-jük  :) A választ továbbküldtem a főnökségnek, apró kommentekkel, hogy engedélyezzék ők, mert addig én nem adom oda a DNS-t, de az új beállításokkal akkor megáll az M365 mindenük, a nagyker weboldal, a cloudflare mindenre, a viszonteladók cloud olda stb.
Döbbenet, hogy annyira sötétek voltak, hogy még azt sem fogták fel, hogy a levelezés is DNS-től függ. Mikor konkrétan rákérdeztem mi lesz az MX-el, azt mondták, a cpanel-nek remek levelező felülete van :) A hogyan kerülnek át oda a meglevő levelek kérdés kicsit megzavarta őket, ja, hogy már van levelezés, nem baj a régi levelek ottmaradnak az Outlook-ban volt a válasz :D

Most új websop készítő csapatot keres a cég  :D

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

nem a php vedelmeben irom, de pl. python2->python3, gtk2->gtk3, qt4->qt5->qt6 ilyen szempontbol milyenebb? nem hasznaltam ilyeneket azert kerdem, tenyleg nem tudom, csak latom a parhuzamot abban, hogy ha a regit mar nem tamogatjak, at kell irni az ujra.

neked aztan fura humorod van...

Hozzáteszem, arról is gyakran lehet hallani, hogy a GCC fordító is változik az újabb verziókkal, de felteszem nem olyan gyorsasággal, mint a script nyelvek. Mindenesetre sok projekt kap olyan visszajelzést, hogy a kódjuk nem fordul a legújabb GCC-vel.

Ilyenkor nincs mese, ott is elő kell venni a vésőt, bár a projektgazdára hárul a móka, nem az üzemeltetőre.

Nyilván nem általános jelenség. Pár éve találkoztam olyannal, mikor a Fedora disztró épp' GCC verziót lépett, hogy nem tudták a szintén verziót lépett  Ruby nyelvet build-elni, mert a legújabb GCC-vel hibát dobott. Jelezték is a Ruby fejlesztők felé, akik meg is oldották hamarosan. Szórványos eset, de előfordul.

> ilyen szempontbol milyenebb

csak foverzional van visszafele se kompatibilis valtozas, es az se 1-2 hanem 10-20 evente.

php-nel meg siman megoldjak hogy 5.2-es kod ne mukodjon 5.3-al, vagy 7.3 ne mukodjon 7.4-el.

ha csak az 5.x php program nem mukodne 7.x alatt azt elfogadnam, de az egyes alverziok se kompatibilisek visszafele se...

Ahogy előttem írták, a változás üteme sokkal lassabb másnál, és inkább figyelnek a főverzión belüli kompatibilitásra.

Üzemeltetőként azt mondom, hogy a PHP esetében a legnagyobb baj, hogy a legtöbb PHP program ki van csapva a nagyvilág felőli elérésére. Az összes többi sorolt alap inkább szűkebb körben elérhető, jellemzően nem publikus webes appok alá van, nem annyira kritikus a frissítgetésük, mert védhetőbbek. Persz a Python webre is erősen használt, de ott megvan az, hogy ritkán változik, és főverzión belül maradva nem tör el semmit a változás.

Az elvárható lenne, hogy legalább ne legyen ennyi főverzió alatti verzió. Legyen 7, 8, majd évek múlva jöjjön a 9. Gondolják át jobban. Hálásak lehetünk nekik, hogy ingyen ezt készítik, csak lehetnének következetesebbek, mit tesznek a világgal, hogy ennyi féle verzió van. 

Sokkal jobb lenne kevesebb PHP verzió. A sok verzióval többet ártottak, mint használtak. Jót akartak, csak nem sikerült. Nem írok példákat, sok más nyelvben kevesebb verzióval érdekes módon tud élni a nyelv.

nem az a baj, hogy ennyi alverzio van, hanem hogy azok se kompatibilisek egymassal, meg visszafele se...

es ennek tenyleg az az eredmenye, hogy egy webszerveren kell 3-5 kulonbozo php verziot futtatni parhuzamosan, meg ezeket frissiteni, valakinek karbantartani stb

Egyetértek. A Pythonnál is ez volt, hogy a 2-es meg a 3-as már szintaxis szintjén sem kompatibilis, meg is bánták a nyelv készítői, a jövőre nézve garantálták, hogy több ilyen vad váltás nem lesz. PHP-nél is meg kéne fontolják. Perl-nél sem volt kicsi a változás, bár ott azért jobban visszafelé kompatibilis. Ezt úgy kéne levezényelni, mint a C-nél, C++-nál, Fortrannál, hogy teljes a visszafelé kompatiblitás az újabb szabványokkal, és az újdonságok használata csak opcionális, nem kötelező.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

pythonnal azert 10+ evente van ilyen valtas, php-nel meg minden alverzional evente 2x... azert az se mind1 milyen gyakran kell at/ujrairni a kodokat.

meg pythonnal azert elegge jol megtamogattak az atallast, eleve vagy 10evig parhuzamosan fejlesztettek a 2.x es 3.x, ott a 2.3 tool, meg pl. a 2.7-be beleraktak a future importot amivel a nem kompatibilis 3.x szintaktikat be lehet hozni 2.7 ala is (print function, unicode strings stb), meg ott a 'six' a libraryk valtozasainak lekovetesere... szoval szerintem a fejlesztok megtettek minden toluk telhetot hogy az atallas minel egyszerubb legyen, ez a php-rol azert kevesbe mondhato el :(

( Hevi v | 2022. 12. 06., k – 23:30 )

Szerkesztve: 2022. 12. 06., k – 23:30

'Cause I'm PHP, I'm dynamite
PHP, and I'll win the fight
PHP, I'm a power load
PHP, watch me explode!

( x-daemon | 2022. 12. 16., p – 00:28 )

PHP 7.4 LTS and ZendPHP 8.2 Builds Now Available

Long-Term Support for PHP 7.4 Now Available

Zend LTS for PHP 7.4 is now available for purchase. Zend PHP 7.4 LTS includes automated bug fixes and security patches for PHP 7.4 through at least December 2026 — plus on-demand consultative support from experts with decades of experience administering and troubleshooting PHP-based applications across diverse application integrations, platforms, and environments.

neked aztan fura humorod van...