Arch, νοοτροπία και κριτική

[imitheos]

29 λεπτά πριν, mphxths είπε

Θυμαμαι μια εποχη που κραζαμε το electron απο το πρωι μεχρι το βραδυ. Ο @jim_p εβγαζε σπυρια και μονο στο ακουσμα της λεξης. Χωρις ομως το electron δεν θα βλεπαμε skype και αλλες εφαρμογες να ερχονται στο λινουξ. Δεν μπορουμε με λιγα λογια να τα εχουμε ολα δικα μας. Να κλαιγομαστε στην Χ εταιρια να φερει το λογισμικο της στο λινουξ και να απαιτουμε να πληρωνει προσωπικο/team να καθεται να υποστηριζει νεο build απο το μηδεν για την παρτι μας και χωρις καν να την πληρωνουμε. Αρα φτιαχνουν νεα εργαλεια/πλατφορμες που μπορουν να ειναι κοινα μεταξυ λειτουργικων για καλυτερη και ευκολοτερη υποστηριξη του προιοντος και ειναι ολοι χαρουμενοι.

Δεν με πειράζουν τα νέα εργαλεία. Αυτό που εννοούσα και ίσως να μην το εξήγησα καλά (και σίγουρα ούτε τώρα θα το εξηγήσω καλύτερα :p) είναι ότι κάθε αλλαγή σε ένα υπάρχον project πρέπει να ζυγίζεται πάρα πολύ καλά. Δεν θυμάμαι ποιος developer έλεγε παλιά ότι στα project του έχουν τον κανόνα -10. Δηλαδή κάθε ιδέα ξεκινά από -10 βαθμούς και αυτός που την προτείνει πρέπει να επιχειρηματολογήσει έτσι ώστε να φτάσουν τουλάχιστον στο 0, μη σου πω και στο +5 για να υλοποιηθεί.

Αν μιλάμε για ένα νέο project, δε με ενοχλεί να γίνει ό,τι να ναι. Νομίζω πως και εκεί παράγινε λίγο το πράγμα με κάποιους "hipster" developers, για να χρησιμοποιήσω ένα στερεότυπο, που χρησιμοποιούν 35 rubygems τα οποία συμβάλλουν 1 γραμμή κώδικα το καθένα και θα μπορούσαν κάλλιστα να μην υπάρχουν αλλά οκ δεν με νοιάζει.

Για παράδειγμα ας πάρουμε το mkvtoolnix που είπα πριν. Δέχομαι κάποιος που δημιουργεί ένα νέο project να πει "έψαξα τα δύο build systems και με rake θα κάνω πιο γρήγορα τη δουλειά μου". Στο mkvtoolnix όμως, η αλλαγή προσέφερε ελάχιστα γιατί οι κανόνες είχαν ήδη γραφτεί οπότε ίσα - ίσα χαραμίστηκε κόπος για να ξαναγραφούν. Και ούτε αλλάζει η δομή συνεχώς για να πεις ότι συνεχώς ανανεώνονταν οι κανόνες στα makefiles. Έγινε εισαγωγή μιας νέας εξάρτησης (η οποία έφερε μια ολόκληρη γλώσσα) χωρίς να προσφέρει κάτι ιδιαίτερο.

Ο firefox εισήγαγε σαν εξάρτηση την clang για ένα τμήμα του οπότε και να έχεις gcc σαν κύριο compiler, πρέπει να χτίσεις το χτικιό llvm και clang. Οι rust devs επέλεξαν να ενσωματώσουν (έχω καιρό να ασχοληθώ οπότε ίσως να έχει αλλάξει) τον llvm στον κώδικά τους οπότε και να τον έχεις χτισμένο, χτίζοντας την rust ξαναχτίζεις ολόκληρο τον llvm.

29 λεπτά πριν, mphxths είπε

Αληθεια ειναι. Αλλα πιστευω οτι με 4γιγα ραμ και 4-πυρηνο επεξεργαστη τρεχεις μια χαρα οποιοδηποτε desktop λειτουργικο στις μερες μας. Και μιλαμε για πολυ προσιτο hardware απο αποψη κοστους. Ναι εχουμε γινει spoiled , αλλα πλεον εχουν αλλαξει τα δεδομενα των εφαρμογων/παιχνιδιων/λειτουργικων και το hardware ως ενα σημειο ειναι προσιτο.

Δεν μπορω να καθομαι με τον διπυρηνο στο 1.3GHz που εχω στο χρεπολαπτοπ μου ομως και να κραζω το compile που παιρνει πολυ ωρα... Δεν μπορω να κραζω κατι σημερινο με δεδομενα ... 10ετιας

Γιατί να μην είναι αρκετός ο διπύρηνος στα 1.3GHz για ένα desktop και πρέπει να έχεις 4πύρηνο και 4GB μνήμη; Τι άλλαξε στο τοπίο xorg - mesa - gpu driver - desktop τα τελευταία χρόνια; Άσε το compile. Για απλό χρήστη binary διανομής τι άλλαξε και έφερε τόσο bloat;

Εδώ έρχεται αυτό που είπα ότι κακομάθαμε (και ειδικά οι developers με τα τεράστια laptop τους). Δεν θυμάμαι σίγουρα σε ποια περίοδο ήταν αλλά νομίζω ήταν KDE3 -> KDE4. Είχα διαβάσει για εκτενείς βελτιστοποιήσεις του κώδικα και είπα να το δοκιμάσω. Δοκίμασα στο ίδιο ακριβώς hardware το KDE4 (το οποίο μάλιστα ήταν alpha) και ήταν απείρως πιο αποκρίσιμο (ξεχνώντας την σταθερότητα φυσικά) από το 3άρι. Άρα λογικά στο 3άρι, μεταξύ άλλων, δεν ασχολήθηκαν με σχεδίαση των αλγορίθμων που χρησιμοποιούσαν και πήγαιναν Αθήνα - Λονδίνο μέσω Νέας Υόρκης. (Εννοείται δεν προσπαθώ να μειώσω τον κόπο των KDE devs).
 

Spoiler

Edit: Αν και πηγαίνω ακόμη πιο offtopic από πριν, να πω λίγο καλύτερα τι εννοώ με σχεδίαση αλγορίθμων. Ας χρησιμοποιήσω ένα παράδειγμα από το project euler. Έρχομαι και σου λέω ότι θέλω να μου βρεις τον μικρότερο αριθμό που διαιρείται με όλους τους αριθμούς από το 1 μέχρι το 20 και σου δίνω σαν βοήθεια ότι ο 2520 διαιρείται με όλους 1 - 10.

Εσύ μπορείς να γράψεις ένα κώδικα που να ξεκινά με το 11 και να διαιρεί 11 με 2, 11 με 3, ένα - ένα με τους αριθμούς 1-20 και όταν δεν διαιρείται με κάποιον να απορρίπτει τον αριθμό και να πηγαίνει στο 12, και ούτω καθεξής μέχρι να φτάσεις στο σωστό 232792560. Όταν αυτόν τον αλγόριθμο τον δοκιμάσεις σε ένα 8πύρηνο i7 θα πάρει 1sec οπότε θα σου φανεί ικανοποιητικός αλγόριθμος και δεν θα ασχοληθείς παραπάνω. Στον δικό μου 2πύρηνο όμως, αυτό παίρνει 8sec και σε ένα μονοπύρηνο P4 θα πάρει 30sec.

Αν εσύ σαν dev είχες ένα αργό μηχάνημα, τότε αναγκαστικά θα έμπαινες στον κόπο να  βελτιστοποιήσεις τον αλγόριθμο και να πεις "ρε σύ αντί να ξεκινάω από το 11 και να αυξάνω κατά 1, μπορώ να ξεκινήσω από το 2520 και ελέγχω τα πολλαπλάσιά του. Επίσης αφού ξέρω ότι διαιρείται με 1-10, μπορώ να ελέγχω μόνο από 11 - 20".

Αυτός ο αλγόριθμος κάνει την ίδια δουλειά και χρειάζεται 0.2sec αντί για 8sec.

Για αυτό το λόγο πρέπει σαν dev να έχεις όσο πιο αργό μηχάνημα γίνεται γιατί τα γρήγορα μηχανήματα (σε συνδυασμό με τους ρυθμούς της ζωής μας φυσικά) προάγει την τεμπέλικη σχεδίαση. :p

 

Επεξ/σία 9 Οκτωβρίου 2021 από imitheos

[mphxths]

23 λεπτά πριν, imitheos είπε

Ο firefox εισήγαγε σαν εξάρτηση την clang για ένα τμήμα του οπότε και να έχεις gcc σαν κύριο compiler, πρέπει να χτίσεις το χτικιό llvm και clang.

Οχι , δεν πρεπει να χτισεις τιποτα. Τα χτιζει ο dev για σενα. Τι ? Οχι ? Δεν θελω να πιασω το θεμα source distros για μια ακομα φορα ...  Αν μιλαμε για compiles , μιλαμε για δυο περιπτωσεις. Ειτε source-based distro , και ξερεις τι λεω για αυτες , ειτε για καποιο ξεκαρφωτο compile πακετου που δεν υπαρχει στα ρεπος της διανομης. Ε εκει , δεν με ενδιαφερει τι θα τραβηξει για να γινει το compile , μιας και τα make deps θα φυγουν στο τελος. 
Μην αρχισουμε τα , δεν εχω χωρο στον δισκο , δεν εχω πολλους πυρηνες να κανει το compile...εχουμε και πυρηνες και gbytes και χωρους και τα παντα
Η ουσια αυτων που γραφεις παραμενει σωστη , αλλα δεν ξερω αν επηρεαζεται ο μεσος χρηστης αμεσα. Ισως ειναι πιο "βαρυ" το binary ? Κατα ποσο ? Μπορει να μετρηθει ποσοτικα δηλ ? Και ποσο επηρεαζει ενα συγχρονο μηχανημα ?
 

23 λεπτά πριν, imitheos είπε

Γιατί να μην είναι αρκετός ο διπύρηνος στα 1.3GHz για ένα desktop και πρέπει να έχεις 4πύρηνο και 4GB μνήμη; Τι άλλαξε στο τοπίο xorg - mesa - gpu driver - desktop τα τελευταία χρόνια; Άσε το compile. Για απλό χρήστη binary διανομής τι άλλαξε και έφερε τόσο bloat;

Θες να απαντησω γενικα ή στην περιπτωση που το μηχανημα τρεχει καποια λινουξ διανομη ? Θα απαντησω και στις δυο περιπτωσεις.
Γενικα , οπου γενικα εννοουμε windows λειτουργικο , διπυρηνος <2GHz και 4gb ram , δεν φτανουν. Η ραμ οριακα φτανει , ο επεξεργαστης θα χωλαινει. Γιατι οπως και να το κανουμε , για να σου προσφερουν τα windows ενα σωρο καλουδια/features/ευκολιες/κλπ τρεχουν την μανα και τον πατερα τους στο background. Βαλε συν ο,τι θα εγκαταστησεις εσυ και θα βαλουν καποια background διεργασια... χαθηκε το παιχνιδι  
Στην περιπτωση που τρεχει καποια λινουξ διανομη , η κατασταση ειναι πιο απλη σε καποιες περιπτωσεις/θεματα. Αν τρεχεις καποιο ελαφρυ DE , σε γενικες γραμμες δεν θα εχεις προβληματα. Στο χρεπολαπτοπ εχω διπυρηνο 1.3GHz , 4gb ram , ssd και τρεχει arch/xfce και σε γενικες γραμμες τα παει καλα. Δεν του εχω φορτωσει τιποτα ομως. Αφηνει μια αισθηση οτι χωλαινει ... κυριως απο θεμα επεξεργαστη.
Απο την αλλη αν θελησεις να τρεξεις κανα gnome/kde και εχεις παλια gpu που δεν εχει σωστο driver ή και καθολου και ολο το DE θα τρεχει στο cpu , τοτε αντε γεια  Και δεν μιλαω για το browser h/w accel που ειναι σχεδον ανυπαρκτο. Kαι δεν μιλαω για οτιδηποτε εξτρα βαλεις που θα βαλει καποιο service να τρεχει στο background , γιατι οπως και να το κανουμε , θελουμε τις ευκολιες μας...
Αν ειναι να ανοιγοκλεινουμε τα προγραμματα μονο οταν τα χρειαζομαστε ... κατι κανουμε λαθος   

Να καταληξουμε σε καποιο συμπερασμα ? Σωστα αυτα που λες. Αλλα το hardware εχει προχωρησει τοσο , που τον τελικο χρηστη δεν θα επρεπε να τον νοιαζουν τετοια θεματα. Ως εναν βαθμο βεβαια. Το bloating του προγραμματισμου θα πρεπει να εχει και ενα οριο.
Επισης καποια στιγμη πρεπει να παψει η χρεπολαγνεια. Διαβαζω το thread με τα 11αρια και αναφερουν σε τι μηχανηματα τα κανουν εγκατασταση , και θυμαμαι τα νιατα μου ... δηλ καπου ελεος.

Επεξ/σία 9 Οκτωβρίου 2021 από mphxths

[Επισκέπτης]

Στις γλωσσες υπερ-υψηλου επιπεδου ο προγραμματισμος μοιαζει σε πολλες περιπτωσεις σαν μια συλλογη βιβλιοθηκων, κανεις δεν ψαχνει αλγοριθμο ποσο δε μαλλον και βελτιστο. Τωρα για το make το gnu βρισκεται υπο διωγμον. Τοσο απλα

[asfodelus]

3 ώρες πριν, imitheos είπε

Ο firefox εισήγαγε σαν εξάρτηση την clang για ένα τμήμα του οπότε και να έχεις gcc σαν κύριο compiler, πρέπει να χτίσεις το χτικιό llvm και clang. Οι rust devs επέλεξαν να ενσωματώσουν (έχω καιρό να ασχοληθώ οπότε ίσως να έχει αλλάξει) τον llvm στον κώδικά τους οπότε και να τον έχεις χτισμένο, χτίζοντας την rust ξαναχτίζεις ολόκληρο τον llvm.

Συγνώμη για το off-topic αλλά το llvm είναι μια εργαλειοθήκη κατασκευής compiler. Η γλώσσα Rust έχει χτιστεί πάνω στον llvm (και του έχει προσθέσει ρουτίνες γιατί κάνει πράγματα στην στατική ανάλυση που δεν έκανε πριν καμία άλλη γλώσσα).  Εύκολα ή "εύκολα" μπορείς να φτιάξεις μια δική σου γλώσσα προγραμματισμού φτιάχνοντας μόνο το εμπρόσθιο κομμάτι  σε yacc/lex και στην συνέχεια καλώντας ρουτίνες του llvm  να έχεις optimized assembly. Με gcc είναι πολύ ποιο δύσκολο (εκ σχεδιασμού), οπότε Rust εξ ορισμού θα θέλει το llvm. Τα πλεονεκτήματα της Rust σε ένα project όπως το servo είναι προφανή. 

Τεχνικά τώρα είμαι ενάντια στην φιλοσοφία του Arch  και για αυτόν τον λόγο. Γιατί θα πρέπει να με απασχολεί το παραπάνω; Αν μια διανομή δεν περιέχει compile τα πακέτα, είναι για μένα ακριβώς το ίδιο με το να μην τα περιέχει. Η φιλολογία περι AUR είναι ουσιαστικά μια απάτη. Αν κάνω κάτι compile το κάνω και με το χέρι φίλος. Μια διανομή πρέπει να την στήνεις και να αρχίσεις να κάνεις την δουλεία που την θέλεις αμέσως. Εξαιρώ το να αλλάξεις το wallpaper με την ζωγραφιά της κόρης σου, γιατί όλοι μας ξέρουμε πως είναι πολύ ποιο καλαίσθητη από αυτήν της διανομής και δεν μας βγαίνουν τα μάτια έξω όταν την βλέπουμε :-). 

Αν τώρα κάποιος θέλει να ασχοληθεί με τεχνικές BDSM βέβαια είναι προφανώς ελεύθερος να το πράξει, μαγκιά του και πάσο. Ας βάλει Arch

Επεξ/σία 9 Οκτωβρίου 2021 από asfodelus

[mphxths]

1 ώρα πριν, asfodelus είπε

Η φιλολογία περι AUR είναι ουσιαστικά μια απάτη. Αν κάνω κάτι compile το κάνω και με το χέρι φίλος.

Δεν ειναι τοσο απλα τα πραγματα στο AUR. Δεν ειναι οτι ο maintainer εκει απλα εβαλε στο PKGBUILD τις εντολες για το compile και αυτο ηταν. Μπορει να εχει προσθεσει patches , dependencies για το install/build , σε καθε νεα εκδοση να τσεκαρει οτι ολα δουλευουν οπως πριν και λοιπα. Και προκειμενου να εχω διαθεσιμο προγραμμα/παιχνιδι που δεν υπαρχει στην διανομη δεν με χαλαει να τραβηξω ενα compile ...

Το compile με το χερι , ενεχει κινδυνους και δυσκολιες..δεν ειναι ετσι απλα τα πραγματα οπως ηταν παλια

Επεξ/σία 9 Οκτωβρίου 2021 από mphxths

[rhtoras]

Στις 9/10/2021 στις 2:07 ΜΜ, jim_p είπε

Το pamac δεν ειναι του manjaro?

ε βάλε το octopi που είναι και posix αφού το έχουν και στο void και στα bsd και ο main dev είναι πολύ καλός έτσι και αλλιώς

[jim_p]

Στις 9/10/2021 στις 1:05 ΜΜ, mphxths είπε

Απαξ ομως και εχεις την συνταγη (PKGBUILD) , μετα δεν τον εχεις αναγκη αν το παρατησει. Ακομα και για την παρτι σου το συντηρεις στο πισι σου αν δεν θες να ασχοληθεις με το AUR. Αλλαζεις το "source" και τα checksums στο PKGBUILD και συνεχιζεις να εχεις το πακετο ενημερωμενο  

Σημειωστε καποιος αυτο^ και τη σημερινη ημερομηνια. Χτες βγηκε επισημα ο xorg 21 και το αντιστοιχο πακετο στο arch εγινε flagged as out of date. Οταν ενημερωθει, ο nvidia 340 του aur θα ειναι πλεον ασυμβατος με τον xorg του repo οποτε το πακετο θα παρει ποδι την επομενη μερα κιολας.

Τοτε θελω να δω αν καποιος απο αυτους που εχουν την "συνταγη" θα το συνεχισει. Και ελπιζω η δικαιολογια του mphxth για την αφαιρεση του να μην ειναι ιδια με αυτη για τον nvidia 304 που μου ειπε καποτε σε πμ, οτι "δεν υπηρχε ενδιαφερον για τον 304 γιαυτο βγηκε απο το aur".

[mphxths]

3 ώρες πριν, jim_p είπε

Τοτε θελω να δω αν καποιος απο αυτους που εχουν την "συνταγη" θα το συνεχισει.

Αναλογως. Αν πηρανε καινουργια καρτα γραφικων , οχι , δεν θα το συνεχισουν .  

[jim_p]

Δικαιολογιες οπως και πριν.

Αλλο πραγμα το αν ΘΕΛΕΙ καποιος να το συνεχισει, και αλλο πραγμα αν ΜΠΟΡΕΙ καποιος να το συνεχισει. Εδω μιλαμε για το δευτερο, που και να θελει δεν γινεται. Και οχι μονο στο arch με το σουπερ aur, σε καμια λινουξοδιανομη.

Επεξ/σία 28 Οκτωβρίου 2021 από jim_p

[tritonas00]

17 ώρες πριν, jim_p είπε

Οταν ενημερωθει, ο nvidia 340 του aur θα ειναι πλεον ασυμβατος με τον xorg του repo οποτε το πακετο θα παρει ποδι την επομενη μερα κιολας

ωχ παει ο media player μου, κριμα, επρεπε να παρω με intel gpu τοτε

εκεινη η μλκια ο nouveau ειναι ακομα γτπ μετα απο τοσα χρονια?

Επεξ/σία 29 Οκτωβρίου 2021 από tritonas00

[jim_p]

Ναι. Αν πας στο θεμα της nvidia στο adslgr θα δεις τι εχω πει για τις 2 μερες που αναγκαστικα να τον χρησιμοποιησω.

[jemadux]

Στις 3/10/2021 στις 6:28 ΜΜ, rhtoras είπε

 

 

Για το samba και systemD δεν ξέρω τι ακριβώς σου παρουσίασε γιατί δεν μου έχει παρουσιάσει ποτε τίποτε όταν δοκίμασα. Βέβαια δεν έχω systemD οι λόγοι εδώ:https://www.slant.co/versus/12956/12960/~systemd_vs_runit

μια χαρά τρέχω samba με openrc στο artix  ..
ή μονη  γ🤬🤬🤬νη διαφορά που έχει  το artix ειναι το init system ..

τίποτα άλλο ... και μπας που λέμε για samba να ξέρεις οταν ενεργοποιείς μέσω openrc την smb 
ενεργοποιείτε αμέσως το nmb 

[jim_p]

Στις 28/10/2021 στις 8:42 ΠΜ, jim_p είπε

Σημειωστε καποιος αυτο^ και τη σημερινη ημερομηνια. Χτες βγηκε επισημα ο xorg 21 και το αντιστοιχο πακετο στο arch εγινε flagged as out of date. Οταν ενημερωθει, ο nvidia 340 του aur θα ειναι πλεον ασυμβατος με τον xorg του repo οποτε το πακετο θα παρει ποδι την επομενη μερα κιολας.

Τοτε θελω να δω αν καποιος απο αυτους που εχουν την "συνταγη" θα το συνεχισει. Και ελπιζω η δικαιολογια του mphxth για την αφαιρεση του να μην ειναι ιδια με αυτη για τον nvidia 304 που μου ειπε καποτε σε πμ, οτι "δεν υπηρχε ενδιαφερον για τον 304 γιαυτο βγηκε απο το aur".

Περασε λοιπον ο xorg 21.x στο arch χτες και αρχισαν ηδη τα παρατραγουδα με τον nvidia 340 και τον nvidia 390
https://aur.archlinux.org/packages/nvidia-340xx
https://aur.archlinux.org/packages/nvidia-390xx-dkms/

Για να δω ποιος απο αυτους που εχουν την "συνταγη" θα συνεχισει. Μιλαμε παντα να δουλευει κανονικα και οχι με αλλαγες τυπου ignoreabi που εχουν αμφιβολα αποτελεσματα.

Btw, o 390 ειναι ακομα επισημα supported απο την nvidia, αλλα δεν βλεπω να ερχεται ενημερωση που θα τον κανει συμβατο με τον xorg 21.x τους επομενους μηνες.

[mphxths]

@jim_p 

Οσοι εχουν την αιχμη της τεχνολογιας σε hardware , πανε σε αιχμη της τεχνολογιας ... διανομη. Οι υπολοιποι καθονται στο debian με τον xorg version 0.1  

[jim_p]

Αρα κανεις γαργαρα το οτι η "συνταγη" δεν δουλευει πλεον, ασχετως ποιος θα την "μαγειρεψει"...

Listerine.jpg