Linux kernel releases

**megahead13** · 21-04-21, 21:19

Αρχικό μήνυμα από tiffany

Δε το έθεσα σωστά. Τα BSD έχουν υποστήριξη από τις εταιρίες λόγω άδειας που επιτρέπει τη χρήση κώδικα χωρίς υποχρέωση. Από την άλλη το GNU ορίζει πως πρέπει να δώσεις πίσω τις αλλαγές.

Χωρίς να μειώνω καθόλου την ποιότητα του κώδικα των BSD θεωρώ πως είναι ο μόνος λόγος που υπάρχουν. Απλά διότι κάποιες εταιρίες μπορούν να παίρνουν κώδικα χωρίς να δίνουν πίσω. Αλλιώς το Linux θα τις είχε σαρώσει και αυτές. Τώρα απλά βολεύονται χωρίς νομικά τερτίπια.

Σωστό αυτό. Όντως η άδεια του BSD είναι που το κρατάει ακόμα, αν και σε πολλές περιπτώσεις, όπως αυτές που ανέφερα πριν, επειδή ξεκίνησαν τα προϊόντα τους πριν 2 ή ακόμα και 3 δεκαετίες με βάση το BSD ίσως είναι πρακτικά αδύνατο να το γυρίσουν σε Linux. Και ίσως να μην έχει και νόημα από τη στιγμή που τα προϊόντα αυτά καθ' αυτά είναι καρακάργα σταθερά και παίζουν τζιτζί.

tiffany · 21-04-21, 21:32

Αρχικό μήνυμα από megahead13

Σωστό αυτό. Όντως η άδεια του BSD είναι που το κρατάει ακόμα, αν και σε πολλές περιπτώσεις, όπως αυτές που ανέφερα πριν, επειδή ξεκίνησαν τα προϊόντα τους πριν 2 ή ακόμα και 3 δεκαετίες με βάση το BSD ίσως είναι πρακτικά αδύνατο να το γυρίσουν σε Linux. Και ίσως να μην έχει και νόημα από τη στιγμή που τα προϊόντα αυτά καθ' αυτά είναι καρακάργα σταθερά και παίζουν τζιτζί.

Νομίζω πως το κομμάτι του δικτύου είναι όντως καλύτερο. Και γι' αυτό προτιμάτε για αυτές τις υλοποιήσεις.

Και κάτι πολύ σημαντικό είναι το API. Πριν χρόνια είχα διαβάσει μια συνέντευξη του GKH και τέθηκε αυτή η ερώτηση. Ανέφερε πως το Linux είναι ένας "ζωντανός" οργανισμός ο οποίος αλλάζει συνέχεια ενσωματώνοντας τις νέες τεχνολογίες. Δεν μπορεί να περιμένει τον κάθε Vendor στο πως θα υποστηρίξει το HW. Αν πρέπει να αλλάξει το Memory Subsystem διότι κάποιος έγραψε κάτι τρομερό δε θα περιμένει καμία πχ Nvidia στο πότε θα βγάλει οδηγούς.

Αντίθετα τα BSD έχουν milestones τα οποία είναι σχεδόν απόλυτα. Το FreeBSD 9 είναι ένα και το αυτό. ΔΕΝ αλλάζει τίποτα όσα χρόνια και αν περάσουν. Αντίθετα στο Linux μπορείς να έχεις μια "παλιά" διανομή με τον τελευταίο πυρήνα χωρίς πρόβλημα.

**megahead13** · 21-04-21, 21:44

Αρχικό μήνυμα από tiffany

Νομίζω πως το κομμάτι του δικτύου είναι όντως καλύτερο. Και γι' αυτό προτιμάτε για αυτές τις υλοποιήσεις.

Αυτό ίσως να ίσχυε μέχρι και πριν καμιά δεκαετία. Είχα βρει στο πρόσφατο παρελθόν papers που συνέκριναν το network stack των δύο πυρήνων. Πλέον είναι ισοδύναμοι σε αυτό το κομμάτι αν δεν κάνω λάθος (που δε νομίζω να κάνω). Και λογικό με τόσες εταιρείες πάνω σε δίκτυα που ασχολούνται με NOS λειτουργικά (και όχι μόνο) βασισμένα σε Linux.

Αρχικό μήνυμα από tiffany

Και κάτι πολύ σημαντικό είναι το API. Πριν χρόνια είχα διαβάσει μια συνέντευξη του GKH και τέθηκε αυτή η ερώτηση. Ανέφερε πως το Linux είναι ένας "ζωντανός" οργανισμός ο οποίος αλλάζει συνέχεια ενσωματώνοντας τις νέες τεχνολογίες. Δεν μπορεί να περιμένει τον κάθε Vendor στο πως θα υποστηρίξει το HW. Αν πρέπει να αλλάξει το Memory Subsystem διότι κάποιος έγραψε κάτι τρομερό δε θα περιμένει καμία πχ Nvidia στο πότε θα βγάλει οδηγούς.

Αντίθετα τα BSD έχουν milestones τα οποία είναι σχεδόν απόλυτα. Το FreeBSD 9 είναι ένα και το αυτό. ΔΕΝ αλλάζει τίποτα όσα χρόνια και αν περάσουν. Αντίθετα στο Linux μπορείς να έχεις μια "παλιά" διανομή με τον τελευταίο πυρήνα χωρίς πρόβλημα.

Και γι' αυτό θα δεις πχ ότι το RHEL δεν τρέχει τον τελευταίο πυρήνα 5.x ή στο Cisco switch θα τρέχει κάνας πηρύνας 3.x ξέρω 'γω. Στο enterprise προέχει η σταθερότητα και η ασφάλεια και όχι η τελευταίο σούπα ντούπα δυνατότητα του πυρήνα. Αν είναι κάτι τόσο σημαντικό, πχ που βελτιώνει κατά πολύ την απόδοση του συστήματος (ή αν φυσικά αφορά security fix), γίνεται backport και τέλος.

tiffany · 21-04-21, 21:53

Αρχικό μήνυμα από megahead13

Αυτό ίσως να ίσχυε μέχρι και πριν καμιά δεκαετία. Είχα βρει στο πρόσφατο παρελθόν papers που συνέκριναν το network stack των δύο πυρήνων. Πλέον είναι ισοδύναμοι σε αυτό το κομμάτι αν δεν κάνω λάθος (που δε νομίζω να κάνω). Και λογικό με τόσες εταιρείες πάνω σε δίκτυα που ασχολούνται με NOS λειτουργικά (και όχι μόνο) βασισμένα σε Linux.

Και γι' αυτό θα δεις πχ ότι το RHEL δεν τρέχει τον τελευταίο πυρήνα 5.x ή στο Cisco switch θα τρέχει κάνας πηρύνας 3.x ξέρω 'γω. Στο enterprise προέχει η σταθερότητα και η ασφάλεια και όχι η τελευταίο σούπα ντούπα δυνατότητα του πυρήνα. Αν είναι κάτι τόσο σημαντικό, πχ που βελτιώνει κατά πολύ την απόδοση του συστήματος (ή αν φυσικά αφορά security fix), γίνεται backport και τέλος.

Για το πρώτο σκέλος δεν έχω να απαντήσω κάτι.

Το θέμα όμως δεν είναι μόνο το Red Hat αλλά και ο ΧΨΩ χρήστης. Αυτός δε θέλει ασφάλεια αλλά να παίζει ο υπολογιστής που πλήρωσε. Και αυτό δεν γίνεται άμεσα με τα BSD. Πρέπει να περιμένει καιρό για σωστή υποστήριξη την ώρα που ο Linus προσθέτει χαρακτηριστικά κάθε μέρα.

**megahead13** · 21-04-21, 22:04

Αρχικό μήνυμα από tiffany

Το θέμα όμως δεν είναι μόνο το Red Hat αλλά και ο ΧΨΩ χρήστης. Αυτός δε θέλει ασφάλεια αλλά να παίζει ο υπολογιστής που πλήρωσε. Και αυτό δεν γίνεται άμεσα με τα BSD. Πρέπει να περιμένει καιρό για σωστή υποστήριξη την ώρα που ο Linus προσθέτει χαρακτηριστικά κάθε μέρα.

Ε, καλά πόσους χρήστες βλέπεις με BSD desktop;

Επίσης το χοντρό χρήμα εδώ και πολλά, πολλά χρόνια είναι στο server/enterpise κομμάτι (data centres, cloud, services, κτλ) . Το desktop/client δεν αποφέρει πια τόσο κέρδος για να τους νοιάζει.

tiffany · 21-04-21, 22:11

Αρχικό μήνυμα από megahead13

Ε, καλά πόσους χρήστες βλέπεις με BSD desktop;

Επίσης το χοντρό χρήμα εδώ και πολλά, πολλά χρόνια είναι στο server/enterpise κομμάτι (data centres, cloud, services, κτλ) . Το desktop/client δεν αποφέρει πια τόσο κέρδος για να τους νοιάζει.

Και εκεί όμως που πέφτει τρελό χρήμα πέφτει και τρελό R&D. Κάθε μέρα ακούς και κάτι διαφορετικό. Οι "δικοί" μας θα το υποστηρίξουν πριν καν βγει σε φυσικό μέσο. Ενώ οι "απέναντι" όχι και τόσο γρήγορα. Εδώ είναι το θέμα. Δες το κι αλλιώς. Μεγάλα κομμάτια του υποσυστήματος οδηγών είναι παρμένα κατευθείαν από το Linux. Προφανώς λόγω λιγότερων "χεριών".

**imitheos** · 22-04-21, 12:40

Αρχικό μήνυμα από megahead13

Προσωπικά δεν τα γνώριζα αυτά τα πράγματα στην κοινότητα του FreeBSD (και του BSD εν γένει δηλαδή). Μου κάνει αλγεινή εντύπωση, ιδιαίτερα όταν, επαναλαμβάνω, το FreeBSD είναι στην καρδιά των προϊόντων μεγαλο-κατασκευαστών όπως η NetApp και η Juniper (πολύ χαρακτηριστικά παραδείγματα στο χώρο των αποθηκευτικών συστημάτων και δικτυακών προϊόντων αντίστοιχα)!!!

Δηλαδή αυτό γίνεται και στο OpenBSD που υποτίθεται είναι η κορυφή των BSD όσον αφορά security;;;

Αρχικό μήνυμα από tiffany

Οι του BSD έχουν άλλη λογική. Και δεν καταλαβαίνω το γιατί. Core commiters και οι άλλοι έξω. Δε λέω ο κώδικας τους παραμένει άψογος και αυτό φαίνεται αλλά εμποδίζει νέους προγραμματιστές που θέλουν να βοηθήσουν. Δε γίνεται να περιμένεις πότε θα δεήσουν να κάνουν review τον κώδικα σου και στο τέλος να τον απορρίψουν διότι δεν είναι στο άμεσο πλάνο τους η τάδε συσκευή.

Ίσως ο κυριότερος λόγος, όπως σε οτιδήποτε μεγάλο, είναι η αδράνεια. Όπως ανέφερα και πριν, έχει ειπωθεί πολλές φορές ότι υπάρχει ένα καθεστώς το οποίο δύσκολα κινείται. Έψαξα να βρω το μήνυμα ενός νέου dev που τα εξηγούσε αλλά δεν μπόρεσα να το βρω. Το google δυστυχώς δίνει προτεραιότητα σε νεώτερα posts έναντι παλαιότερων και σε δημοφιλή έναντι σε εξειδικευμένα. Ψάξε να βρεις πληροφορίες για ένα σπείρωμα μιας μηχανής και θα πρέπει να είσαι google guru για να το κάνεις. Ψάξε τι έφαγε για πρωινό σήμερα η Καρντάσιαν, 4.5 εκατομμύρια αποτελέσματα. Anyway, νομίζω ήταν ένα παληκάρι το οποίο έστελνε για καιρό patches τα οποία γίνονταν commit μέσω άλλων (ίσως είχε δουλέψει και στο gsoc, δεν θυμάμαι) και ενώ ήταν καλογραμμένα δεν περνούσαν ούτε τα μισά.

Βρήκα κάποια άλλα μηνύματα όπως του Benno Rice (χρόνια dev και μέλος του FBSD core), Charles Hannum (συνειδρυτή του NBSD), Julio Merino (χρόνια NBSD dev και μετέπειτα FBSD dev) αλλά υπάρχουν πολλά περισσότερα.

Σε γενικές γραμμές το πρόβλημα είναι αδράνεια. α) Υπάρχει μια ομάδα devs που είναι πολλά χρόνια και έχουν μάθει να δουλεύουν με ένα τρόπο και δεν θέλουν να αλλάξουν ακόμη και αν ο νέος τρόπος φέρει πολλούς νέους devs. Επίσης είναι όλοι γνωστοί, έχουν συνηθίσει ένα ρυθμό και δεν τους καίει να αλλάξει κάτι. β) υπάρχει έλλειψη "οράματος" δηλαδή ένα TODO / milestone / κτλ το οποίο να λέει πρέπει να κάνουμε αυτό μέχρι τότε, εκείνο μεχρι δείνα και το άλλο μέχρι παρατότε, γ) Υπάρχει έλλειψη "leadership". Υπάρχουν τα "core συμβούλια" που ως γνωστόν αν θέλεις κάτι να μη γίνει ποτέ, ανάθεσε το σε μια επιτροπή. Δεν υπάρχει ένας "leader", ένας benevolent dictator ο οποίος συννάμα να είναι αρκετά τρελός (πχ Linus Torvalds, Richard Stallman, Theo de Raadt, κτλ) και να τρέχει τους άλλους και να γίνονται πράγματα.

Αυτός λοιπόν ο συνδυασμός οδηγεί σε στασιμότητα. Εγώ και άλλοι τρελοί "πιέζαμε" πόσο καιρό για πράγματα που οι devs όλων των BSD θεωρούσαν μη-απαραίτητα.
* "Είναι τρελό να έχουμε ακόμη τα BSD disklabels και cylinders και sectors. πρέπει να υλοποιηθεί υποστήριξη για GPT" -> "Έλα μωρέ, αν δεν έχεις > 2TB μια χαρά παίζει το disklabel. επίσης είναι σήμα κατατεθέν των BSD, δεν γίνεται να αλλάξουμε".
* "Δεν μπορεί ακόμη να χρησιμοποιούμε ξεχωριστές κατατμήσεις και να πρέπει να κάνεις backup / restore για να αλλάξεις ένα μέγεθος. Επίσης έχουμε μόνο UFS το οποίο δεν είναι καν journaling" -> "Έλα μωρέ, το UFS είναι καρά - stable, τι να κάνεις την ευελιξία των ZFS, BTRFS, κτλ".
Και πολλά άλλα τέτοια όπου μάλλιασε η γλώσσα μας να παλεύουμε άσκοπα.

Το NetBSD ήταν νομίζω πρώτο που υποστήριξε GPT / UEFI αλλά χωρίς να έχει ευέλικτο fs (ευτυχώς είχε τον LVM του linux που λίγο έφτιαχνε τα πράγματα). Μετά υλοποίησε GPT (και μετέπειτα UEFI) το FBSD με ευτυχώς καλή υλοποίηση για ZFS, και το OBSD υλοποίησε μόλις πριν λίγο καιρό UEFI με hacks στην disklabel αντί για ξεχωριστή υποστήριξη gpt (νομίζω δεν είμαι σίγουρος) οπότε τα άλλα BSD δεν μπορούν να διαβάσουν OBSD "disklabel" και δεν έχει ούτε ZFS ούτε τίποτα. Μόνο UFS χωρίς journalling (νομίζω έχει τα softupdates αλλά δεν θεωρούνται stable και δεν προτείνονται. το NBSD έχει το WPBL για journalling το οποίο νομίζω θεωρείται stable).

Όσον αφορά για την "κορυφή" του security που είπε ο megahead, πολλές φορές τα πράγματα που βγαίνουν προς τα έξω (όπως και για το λίνουξ φυσικά) είναι λίγο μέσω "rose colored glasses" που λένε και στο χωριό μ. Δηλαδή ακούμε να προβάλλονται μόνο τα θετικά. Το μπάχαλο που είναι στο FBSD (όπως και σε όλα τα μεγάλα projects) δεν πολύ ακούγεται. Ούτε καν εσύ, που είσαι γνώστης των πραγμάτων, δεν το περίμενες. Ο τύπος που έγραψε τον hypervisor του NBSD (ώστε να παίζει acceleration στο qemu όπως είναι το KVM στο λίνουξ) βρήκε ένα κάρο λάθη στον hypervisor του OBSD και τους έστειλε διορθώσεις. Είχε μέχρι και security προβλήματα. Ομολογουμένως είναι biased άποψη, αλλά οι devs του NBSD γενικά δεν έχουν και σε πολύ περιοπή τον κώδικα του OBSD. πχ αυτό, αυτό, κτλ.

(4) Considering the overall poor quality of code coming out of OpenBSD, I
wouldn't feel confident with us importing their code, whether it be wg,
or anything else at large.
...

I've given a 5-minute look at OpenBSD's if_wg.c file considered "production-
ready". 40 lines of code into the wg_input() entry point it looks like there
is already a vuln:

**megahead13** · 22-04-21, 15:53

Όλα αυτά, ας πούμε για χάρη της κουβέντας, είναι καλά κι έχουν ένα νόημα από τη σκοπιά ότι το BSD είναι ιστορικά ένα πολύ server/network oriented λειτουργικό για το enterprise και οι desktop χρήστες του είναι ένα απειροελάχιστο ποσοστό σε σχέση με τους desktop χρήστες του Linux, οπότε κάποιες από τις latest and greatest δυνατότητες δεν έχουν τόσο μεγάλη σημασία, ώστε τελικά να υλοποιηθούν. Από αυτή την οπτική γωνιά ένα core group devs στο οποίο πάρα πάρα πολύ δύσκολα θα μπουν νέοι devs ίσως και να είναι σωστό (για μένα δεν είναι, αλλά τεσπά). Να μην υπάρχουν όμως σωστές και αυστηρές διαδικασίες review του κώδικα;;; Αυτό που έγινε με το WireGuard είναι μεγάλη ξεφτίλα για όλους!

**xtremae** · 22-04-21, 21:10

Σε πρόσφατη συνέντευξή του πάντως ο Jason Donenfeld εξέφρασε την ικανοποίησή του σχετικά με τη συνεργασία του τόσο με το Linux όσο και με το OpenBSD, αφού αυτά ακολούθησαν διαφανείς διαδικασίες και έκαναν τουλάχιστο τον κόπο να τον ενημερώσουν. Το FreeBSD αντί να κινηθεί εν κρυπτώ και παραβύστω (με τα γνωστά αποτελέσματα) έπρεπε να τηρήσει τους τύπους και να γνωστοποιήσει την πρόθεσή του στους δημιουργούς του WireGuard.

tiffany · 22-04-21, 22:10

Αρχικό μήνυμα από xtremae

Σε πρόσφατη συνέντευξή του πάντως ο Jason Donenfeld εξέφρασε την ικανοποίησή του σχετικά με τη συνεργασία του τόσο με το Linux όσο και με το OpenBSD, αφού αυτά ακολούθησαν διαφανείς διαδικασίες και έκαναν τουλάχιστο τον κόπο να τον ενημερώσουν. Το FreeBSD αντί να κινηθεί εν κρυπτώ και παραβύστω (με τα γνωστά αποτελέσματα) έπρεπε να τηρήσει τους τύπους και να γνωστοποιήσει την πρόθεσή του στους δημιουργούς του WireGuard.

Μα το θέμα δεν είναι το FreeBSD αλλά η Netgate που αποφάσισε μόνη της να προσθέσει κώδικα χωρίς να συμβουλευτεί το FreeBSD. Προσέλαβε τον τύπο ο οποίος έγραφε "κακό" κώδικα χωρίς έλεγχο. Απ' ότι διάβασα το πρόβλημα ήταν τόσο σοβαρό που με ένα απλό ping κρέμαγε το ΛΣ.

**xtremae** · 23-04-21, 18:05

Αρχικό μήνυμα από tiffany

Μα το θέμα δεν είναι το FreeBSD αλλά η Netgate που αποφάσισε μόνη της να προσθέσει κώδικα χωρίς να συμβουλευτεί το FreeBSD. Προσέλαβε τον τύπο ο οποίος έγραφε "κακό" κώδικα χωρίς έλεγχο. Απ' ότι διάβασα το πρόβλημα ήταν τόσο σοβαρό που με ένα απλό ping κρέμαγε το ΛΣ.

Η Netgate δε μπορεί να προσθέσει κώδικα στο FreeBSD, πόσο μάλλον χωρίς να ενημερώσει. Για να συμβεί αυτό, θα πρέπει να βρεί κάποιον μέσα από το πρότζεκτ, στην προκειμένη περίπτωση τον Matt Macy που έγραφε κακό κώδικα, ο οποίος με τη σειρά του έχει το δικαίωμα να κάνει τις όποιες αλλαγές. Από τη στιγμή που το FreeBSD έχει εμπιστευτεί (εδώ και χρόνια) τον Macy με commit bit τότε η ευθύνη και το πρόβλημα είναι στο FreeBSD και όχι στη Netgate.

**famous-walker** · 23-04-21, 18:33

Αρχικό μήνυμα από xtremae

Η Netgate δε μπορεί να προσθέσει κώδικα στο FreeBSD, πόσο μάλλον χωρίς να ενημερώσει. Για να συμβεί αυτό, θα πρέπει να βρεί κάποιον μέσα από το πρότζεκτ, στην προκειμένη περίπτωση τον Matt Macy που έγραφε κακό κώδικα, ο οποίος με τη σειρά του έχει το δικαίωμα να κάνει τις όποιες αλλαγές. Από τη στιγμή που το FreeBSD έχει εμπιστευτεί (εδώ και χρόνια) τον Macy με commit bit τότε η ευθύνη και το πρόβλημα είναι στο FreeBSD και όχι στη Netgate.

Σίγουρα υπάρχει θέμα με το freebsd. Από την άλλη επίσης είναι μεγάλο φάουλ της netgate. Και το πώς διαχειρίστηκε την κατάσταση αφού αποκαλύφθηκε η ποιότητα του κώδικα και τα προβλήματα, αλλά και η ανικανότητα που επέδειξε στο να έχει κάποιο βαθμό ελέγχου σε κώδικα που έχει παραγγείλει αλλά και γενικότερα σε κώδικα που βάζει στα προϊόντα της.