> Drupal 7 EOL has been extended again. The ne...
# chat
z
Drupal 7 EOL has been extended again. The new EOL is January 25 2025!
“Ωριμάζοντας” και βλέποντας λίγο έξω από το Drupal κουτί, νομίζω πλέον αυτή η συζήτηση δεν έχει νόημα 😅 Το Drupal 7 απο τα επομενα (8-9-10-…) ειναι ουσιαστικά “αλλο προϊόν“, τόσο θα μπορουσες να τα ονόμαζες διαφορετικά. Θεωρώ τo “Drupal 7” θα συνεχίσει να γίνεται support μέχρι η χρήση του να πέσει σε “irrelevant” επίπεδο (ίσως κάτω του 5-10% ?), και αυτή τη στιγμή είναι κοντά στο 50%: https://www.drupal.org/project/usage/drupal Γιατί? Δεν έχει νόημα κανείς να πληρώσει “upgrade” αν δεν θέλει νέα λειτουργικότητα (new features, redesign κτλ). => Ή θα κανεις extend ή θα αφήσεις τους χρήστες ξεκρέμαστους. Και επειδή δεν είσαι κολοσσός (microsoft) που προσφέρει την “μοναδική” εναλλακτική, αν δεν γίνει extend πιθανότατα να χασεις τους χρηστες/μεγάλο κομματι πιτας. • Λίγοι θα πάνε σε Drupal 9+ • Άλλοι θα πάνε σε ανταγωνιστές (γτ αν τους εξαναγκάσεις σε remake => θα εξετάσουν απο την αρχή τις επιλογές τους) • Και πολλοί θα μεινουν στο unsupported Drupal 7 Αν προσπαθήσεις να φτιάξεις άρτιο migration path 7 -> 9/10, θα σου φάει απειρα resources που σημαίνει θα χάσεις απο κάτι άλλο (καινοτομία/ νεα ή εκσυχρονινισμό features κτλ). Τώρα είμαι σε “product” εταιρία και το βλέπω λίγο. Έχουμε legacy κωδικα που “δουλευει“. Δεν ειναι priority να τον εξαφανίσουμε όσο δεν δουλεύουμε σε features που να χρειαζονται κατι διαφορετικό απο αυτο που κανουν, γτ χρειαζεται παρα πολυ κοπο που θα τον χασουμε απο αλλου και μπορεί να μας πεταξει εξω η αγορά. Θέλω όσο τίποτα να τον φτιάξω, και σιγά σιγα αντικαθιστούμε κομμάτια του, αλλά σε ένα “ζωντανό προϊόν” δεν γίνεται απλά να πεις “θα πάρω έναν χρονο και θα το ξαναφτιάξω“.
Νομίζω για τετοια συζητηση θα ενδιαφερόταν και ο @tassos να πει μια γνώμη 😉
v
H αλήθεια είναι ότι αν έχεις ένα site και δουλεύει (σε οποιαδήποτε τεχνολογία), δεν προχωράς εύκολα σε ένα κοστοβόρο upgrade αν δεν το χρειάζεσαι οπωσδήποτε.
z
Δεν έχεις σοβαρό λόγο να το κάνεις. Νομίζω ότι κάναμε λάθος (ως κοινότητα) να προσπαθούμε να πιέσουμε (εμμέσως “απειλήσουμε“) τους site owners οτι αυτο θα ειναι end of life και πρεπει να αλλαξει “χθες“. Instead επρεπε να ειχαμε σκεφτεί καποια πιο δελεαστική εναλλακτική (αν υπηρχε)
n
Αχ, μου θυμίζεις τα PLC και τους αυτοματισμούς. Ακριβώς τα ίδια. 🙂 Ό, τι δουλεύει δεν το αλλάζουμε.
Αυτό το legacy support δεν δημιουργεί κενά ασφαλείας;
z
Αυτό το “Ό, τι δουλεύει δεν το αλλάζουμε.” το λέγαμε για “πλάκα“, αλλά πλέον βλέπω γιατί γίνεται και συχνά γιατί είναι αναπόφευκτα the way to go όσον αφορά την επιβίωση του προϊόντος. Φυσικά δεν σημαίνει ότι δεν προσπαθείς σιγά σιγά/όταν χρειάζεται να το βελτιώσεις/αλλάξεις αλλά αυτό γίνεται όταν χρειάζεται όχι για χαρη την αλλαγής βελτίωσης και μόνο. Υπάρχει valid λόγος που όλοι έχουν “legacy” κωδικα που “δεν αλλάζει” τόσο εύκολα, μονο σταδιακά.
Αυτό το legacy support δεν δημιουργεί κενά ασφαλείας;
Φυσικά, αλλά και τα καινούργια δεν δημιουργούν κενά? Πάντα πρέπει να προπαθείς να και ποτέ δεν θα είσαι 100% “ασφαλής“. Για μας, τρέχουμε bug bounty προγραμμα, και ότι βρίσκουμε το κλείνουμε ή με κάποιο τρόπο το κανουμε mitigate. Την περασμένη εβδομάδα κιόλας είχα Security Focus Week, που με αλλους 4 devs κλειναμε ότι είχαμε reported, και απο τέτοια reports βρήκαμε και άλλα παραπλήσια/ίδια λογική και κλειναμε. Το ίδιο και buggy… Buggy ή insecure κωδικας δεν ανήκει στο “ότι δουλεύει” 😉
n
Κατάλαβα. Η αλήθεια είναι ότι στους αυτοματισμούς είσαι πολύ δεμένος με το hardware και τα παλιά και unsupported API servers είναι επιρρεπή και για αυτό γίνονται πολλά attacks σε παλιά συστήματα. Τελειώνει το support, τέλος το security.
😢 1
t
Το Drupal ουσιαστικά το γύρισε σε rolling release που είναι πολύ καλύτερο από κάθε άποψη. Νομίζω ότι τα 7 θα πρέπει να κάνουν upgrade καθώς είναι μία σειρά από πακέτα που δεν θα τα υποστηρίζουν. Δλδ για ποια version PHP, ποια linux distros θα πακετάρουν παλιά executables; Λειτουργικά το λογισμικό πάντα είχε ένα συγκεκριμένο κύκλο ζωής -- δεν θεωρώ ότι θα πρέπει να μας ξενίζει, ούτε είναι απειλή ή εκβιασμός να πας παρακάτω.
s
εγω έχω ένα προιον γραμμενο σε php 5.2 που είναι με php-mysql ούτε καν mysqli. Πιο πιθανό να κλείσει η εταιρεία παρά να κάνουμε migrate/rebuild.
😄 1
t
Εντάξει, αλλά εσύ παίρνεις το την αρμοδιότητα να το συντηρείς
φτιάχνεις δικά σου πακέτα να τα έχεις στο server σου κτλ κτλ
Κανείς δεν μπορεί να σε σταματήσει σε αυτό
s
το επόμενο βήμα είναι να μπει σε docker
αλλά ναι, κάθομαι και κάνω build την php
αν και έχω βρει ένα πολύ ωραιο project που αλλάζει τις mysql_ σε pdo
$phpversion=phpversion(); if($phpversion!='5.2.17') { include_once('../inc/mysql/MySQL_Functions.php'); include_once('../inc/register_globals.php'); }
t
Με docker και ένα καλό network architecture δεν θα έχεις πρόβλημα
οπότε ο ίδιος κωδικας είναι php7 compatible 😜
z
Σε κάθε περίπτωηση πρέπει να υπολογίσεις το trade-off. Πόσα χρόνια ζωής θεωρούμε ότι θα έχει αυτό το software? Για τα χ χρόνια ζωής συμφέρει να το κάνεις upgrade με χ κόστος και να έχεις θεωρητικά “φθηνό” maintenance ή να το αφήσεις και να εχεις “ακριβό” maintenance? Ποια η πιθανότητα και ποιο το κόστος να συμβεί κάτι καταστροφικό λόγω παλιάς version? Μπορούμε να κανουμε mitigate αυτό και πως/με ποιο κόστος? Σε πολλές περιπτώσεις μπορεί η λογική απάντηση να ειναι “stay to drupal 7, ακομα και να ειναι unsupported”, και όχι “upgrade” Μπορεί σαν drupal community ή σαν agencies να “μας συμφέρει” περισσότερο το “rebuild to new drupal” και να κανουμε evangelize αυτό, αλλά βλέποντας λίγο απέξω, θεωρώ ότι δεν ειναι πάντα αυτό η καλυτερη επιλογή. Πολλές φορές είναι όμως. Δεν λέω τυφλά “stay to drupal 7”. Απλά παρουσιάζω ότι και αυτό το option εχει λογική για πολλους και γιατί.
t
Ναι είναι λογικό αυτό
s
κι εδω έρχεται το cloudflare με το υπέροχο waf του και μαζεύει λεφτουδάκια
γιατί όσο καλογραμμένο και να είναι ένα project, δεν ξαναγραφεται εύκολα
οπότε με ένα καλο waf μένεις ασφαλής
v
Γενικά τα timely updates /upgrades νομίζω ότι συμφέρουν overall. Δε συσσωρεύσεις breaking changes. Απλά στην περίπτωση του Drupal ουσιαστικά άλλαξε το προϊόν θεμελιωδώς και αυτό δημιουργεί θέματα by default.
z
Ναι, θα μπορούσες να πεις ότι είναι 2 διαφορετικά προϊόντα: Drupal 7 => aka “OldDrupal” Drupal 8+ => aka “NewDrupal”
v
Έτσι.
d
insert backdrop here (?)
v
Μια πιθανή λύση, αλλά είναι αυτό που είπε ο @zekvyrin. Χάνεις χρήστες.
z
Αν πεις στους χρήστες εύκολο upgrade πηγαίντε στο backdrop και μέσα σε 6 μήνες οι περισσότεροι πάνε, απο το 12.8% θα πέσεις στο 5-7-10% (δεν ξέρω σίγουρα ποσα ειναι drupal 7 ,αλλά κάποια ειναι) (source : https://techjury.net/blog/drupal-usage-statistics/ ) “Χάνεις” σε marketing ως κοινότητα => Γιαυτό όσο εχει μεγάλο ποσοστό, προτιμάς να το κανεις extend το support και να το μετράς στα στατιστικα
a
New EOL?! Πρέπει να φτιάξω νέο βίντεο με τον Dimitri! 😀
😮 1
🤣 1
f
Νομίζω υπάρχει και μια αλλη παράμετρος ωστε να μην "σταματήσεις" το support και τα security updates στο 7. Αν αρχισουν τα hacks στα D7, αντε να πεισεις μετα την αγορά οτι δεν "φταιει" το Drupal που το χακαραν, αλλα το συγκεκριμένο site που ηταν D7.
s
Ti na po kai ego pou exo akoma se production ena D6!!!! Vevaia pleon exei krifti apo piso apo to public network, kai iparxei ena decoupled frontend pou tou milaei. Alla opos kai na exei einai production 😞 2.5 Xronia paleuoun na to katartgisoun!!! PS o logos giati apla to "back end" paroti exoun ginei prosthikes den exei poia ta kainourgia kai oraia kaloudia kai den einai toso "friendly" stous editors PS2 kapoio idiaitero kostos sintirisis den exei PS3 Alla kapoia stigmi xtizis kai ztizis se kati palio kai meta einai terastio to kostos se develpoment time gia na figeis.
t
Ένα ενδιαφέρον άρθρο: https://martinfowler.com/articles/is-quality-worth-cost.html
z
@tassos Αυτό έχει να κάνει με το κτίζω τώρα Software focused on “quality” vs software focused on cost/speed. Συμφωνώ με όσα λέει, μεσο/μακροπροθεσμα πάντα το quality / clean ειναι πιο φθηνο τουάχιστον στις περισσότερες περιπτώσεις. Τα ίδια περιγράφεται Εδώ όμως η σύγκριση ειναι • Κάτι που δουλευει όπως πρέπει (=> quality is relatively good) και δεν χρειαζεται νεα features • vs rebuild σε κατι ποιοτικοτερο/πιο extendable με θεωρητικά μεγαλύτερο χρόνο ζωής όσον αφορά την αναπτυξη. Το argument που ειχα να κάνω είναι ότι αν δεν χρειάζεται νεα features, δεν εχει νόημα για τους περισσότερους το rebuild. Δλδ, αν δεν έχεις νέα features ή bugs να σε ενοχλούν συνεχόμενα (=> να μην γίνονται επαρκώς mitigate). Αν είσαι σε διαρκές development, δεν το συζητάω => start planning for migration yesterday Αν δεν είσαι όμως, και εχεις κάτι που ειναι σταθερό (και όσον αφορά το πως λειτουργει και όσον αφορά τα features) δεν χρειαζεται απαραίτητα
t
Αυτό που περιγράφεις είναι το ζουμί
αν χρειάζεσαι ή όχι νέα πράγματα
δλδ ποια είναι η ζωή του digital product
και σε πια φάση είσαι
z
Ναι αυτή ήταν η αρχική σκέψη/ argument. Το παλιό που δουλεύει όπως πρέπει, ειναι μεν non-extentable πλέον, αλλά αν δεν χρειάζεται extend θα μείνει “παλιο“. Αν χρειάζεται extend θα πρέπει γίνει rebuild κτλ. Θεωρώ ότι πολλά από τα D7 sites είναι σε στατική φάση / δεν αναπτύσσονται, απλα προσθέτεις content ίσως.
Martin Fowler btw δεν εχω διαβασει ακομα, αλλα ειναι 2 βιβλία που εχω στα “πρέπει” και εχει αναφορές απο αυτά στα Clean Code/Architecture που διαβασα φετος