Επιστροφή στο Forum : Η Microsoft δίνει στο GitHub τον πηγαίο κώδικα του MS-DOS 4.0
Σε συνεργασία με την IBM, η Microsoft έδωσε στη δημοσιότητα τον πηγαίο κώδικα για το MS-DOS 4.0, περισσότερα από 35 χρόνια από τότε που το λειτουργικό σύστημα έκανε μια υποτονική εμφάνιση πριν από τα Windows 3.x.
Το MS-DOS 4.0 είναι ένα κατάλοιπο από την εποχή που η IBM και η Microsoft βρίσκονταν στη δίνη της κοινής τους περιπέτειας με το OS/2. Ήταν αξιοσημείωτο για την υποστήριξη κατατμήσεων σκληρού δίσκου FAT16 μεγαλύτερων από 32 MB και την προσθήκη του MS-DOS Shell. Ήταν επίσης μια από τις τελευταίες εμφανίσεις του προγράμματος εγκατάστασης SELECT.
Ο κώδικας εμφανίστηκε ενώ ένας ερευνητής ονόματι Connor Hyde (γνωστός και ως Starfrost) κατέγραφε τη σχέση μεταξύ του DOS 4, του MT-DOS (Multitasking DOS) και του OS/2. Ο Hyde αλληλογραφούσε με τον Chief Technical Officer της Microsoft Ray Ozzie, ο οποίος βρήκε τον σκονισμένο κώδικα στη συλλογή του από δισκέτες.
Οι δισκέτες του Ozzie, οι οποίες φαίνεται να χρονολογούνται από το 1984, περιέχουν μη κυκλοφορημένα δυαδικά αρχεία beta Multitasking DOS και περιλαμβάνουν επίσης την πηγή ibmbio.com.
Ο Hyde επικοινώνησε με το Γραφείο Προγραμμάτων Ανοιχτού Κώδικα της Microsoft (OSPO) για να δει αν ίσως η πηγή του DOS 4 θα μπορούσε να κυκλοφορήσει. Ο Scott Hanselman, αντιπρόεδρος της Microsoft για την κοινότητα προγραμματιστών, με τη βοήθεια του αρχειοφύλακα Jeff Sponaugle, έκανε απεικόνιση των δίσκων και σάρωσε τα τυπωμένα έγγραφα.
Η ομάδα OSPO δεν μπόρεσε να βρει τον πλήρη πηγαίο κώδικα για το MT-DOS, αλλά βρήκε τον πηγαίο κώδικα για το MS-DOS και ανέβασε τον κώδικα στο GitHub (https://github.com/microsoft/MS-DOS/tree/main) με την άδεια MIT.
Εκτός από την πηγή για το MS-DOS 4, υπάρχουν επίσης τα αρχεία του Ozzie, μαζί με τα σαρωμένα PDF της τεκμηρίωσης του Multitasking DOS. Αν και αυτός ο χάκερ ζει σε ένα γυάλινο σπίτι όσον αφορά τα τυπογραφικά λάθη, η εύρεση του οράματος της Microsoft για το μέλλον που ονομάζεται "Multi-Taking MS-DOS" [sic] στις σημειώσεις [PDF (https://github.com/microsoft/MS-DOS/blob/main/v4.0-ozzie/Multitasking%20DOS%20BETA%20-%20Release%20Notes.pdf)] προκάλεσε ένα ειρωνικό χαμόγελο.
Αν και οι προσπάθειες του Hanselman είναι αξιέπαινες για τη διάθεση αυτού του κομματιού της ιστορίας, θα ήταν καλό να υπήρχε κάποιου είδους αντίστροφη μέτρηση για τη δημοσίευση του κώδικα άλλου παρωχημένου λογισμικού. Ο Hanselman είπε ότι τα MS-DOS 3.3, 5 και 6 είναι τα επόμενα στη λίστα, αν και θα πρέπει να αφαιρεθούν ορισμένα από τα βοηθητικά προγράμματα του τελευταίου.
Σύμφωνα με τη Microsoft (https://cloudblogs.microsoft.com/opensource/2024/04/25/open-sourcing-ms-dos-4-0/), ο κώδικας μπορεί να εκτελεστεί σε έναν αρχικό IBM XT, σε ένα νέο Pentium ή μέσα στους εξομοιωτές ανοικτού κώδικα PCem και 86box. Παρόλο που δεν διαθέτουμε κανένα παλιό κιτ της IBM, καταφέραμε να ενεργοποιήσουμε τον κώδικα χρησιμοποιώντας το 86Box και νοσταλγήσαμε πριν ευχηθούμε να είχαμε εγκαταστήσει το MS-DOS 5 ή 3.3.
255715
πηγή (https://www.theregister.com/2024/04/26/ms_dos_4_open_source/?utm_source=dlvr.it&utm_medium=twitter) via DeepL
Για χομπίστες έχει πλάκα η είδηση, για τους άλλους είναι απλά μία ανάμνηση.
Άντε και σε άλλα 30 χρόνια να μας δώσουν τον κώδικα των Windows XP.
Άντε και σε άλλα 30 χρόνια να μας δώσουν τον κώδικα των Windows XP.
Υπάρχει ήδη στο 4chan :lol: :lol: :lol: :lol:
dimitri_ns
28-04-24, 17:52
Άντε και σε άλλα 30 χρόνια να μας δώσουν τον κώδικα των Windows XP.
Τι να τον κάνουμε ?
Φιλοσοφικές συζητήσεις με γκόμενες ?
Tzitziloni
28-04-24, 18:05
Ο κώδικας μπορεί να γίνει build με χρήση του Dosbox ακολουθώντας τις οδηγίες στο runme.bat.
Στα παραλειπομενα, ο Mark Zbikowski έκανε commit για να αντικαταστήσει το όνομα του Tim Patterson με τα αρχικά ΤP στο παρακάτω comment:
; Brain-damaged Tim Patterson ignored ^F in case his BIOS did not flush the
; input queue.
Ο κώδικας είναι 85% assembly.
Πάντως μου έκανε εντύπωση οτι υπήρχε πραγματικό (Preemptive) multitasking στο DOS αλλά δεν το έβγαλαν λόγω έλλειψης ενδιαφέροντός. Ακόμα και για τα windows 3.1 θα ήταν πολύ χρήσιμη αυτή η δυνατότητα.
τον καιρό εκείνον το πρόβλημα δεν ήταν ο CPU ή το λειτουργικό αλλά η RAM. Τα 8086 συστήματα τότε είχαν το πολύ 512 KiB RAM μιας και το DOS δεν έβλεπε πάνω απο 640KiB. Ο έχων 1MiB RAM εθεωρείτο θεός και ήθελε 80286 και DOS 4.0 τουλάχιστον για να τα εκμεταλλευτεί.
οπότε χωρίς μνήμη τι Multitasking να κάνεις? Με το ζόρι χωράει το λειτουργικό και μία καλογραμμένη εφαρμογή.
o 80286 ήταν ο πρώτος CPU της intel που υποστήριζε ας-πούμε virtual memory και είχε σχεδιαστεί να είναι business-oriented CPU που θα χρησιμοποιηθεί από την επιστήμη και τις επιχειρήσεις.
Και μετά ήρθε ο Personal Computer και τo Prince of Persia (https://en.wikipedia.org/wiki/Prince_of_Persia_(1989_video_game)) :lol:
o πρώτος 32bit CPU που μπορούσε να εκτελέσει πραγματικό ας-πούμε protected multitasking ήταν ο 80386 ενώ το πρώτο λειτουργικό της MS που μπορούσε να τον χρησιμοποιήσει μέσω της κατάρας που ονομάζεται swap file ήταν τα Windows for Workgroups 3.11.
... και μετά ήρθαν τα NT και αλλάξαμε πίστα :)
αφήνω εδώ αυτό για να γελάσουμε ... :mrgreen:
Απο το MS-DOS / v4.0-ozzie / Multitasking DOS BETA - 286 Compatability.pdf (https://github.com/microsoft/MS-DOS/blob/main/v4.0-ozzie/Multitasking%20DOS%20BETA%20-%20286%20Compatability.pdf)
Το ρολόι γράφει 30 Οκτωβρίου 1984.
https://i.ibb.co/0ZyB3H7/Screenshot-2024-04-28-214756.png (https://ibb.co/ftd87jg)
Ο κώδικας είναι 85% assembly.
^αυτό.
Αν κάποιος ενδιαφέρεται να μάθει πως γράφανε εφαρμογές όταν έκαστο kb είχε σημασία,
και δεν μπορούσες χαλαρά να κάνεις import x_lib;
τα παλιά συστήματα/εφαρμογές είναι study material.
Άλλη εποχή βέβαια...
για σήμερα δεν έχει σημασία όσο κάποιος δεν γράφει baremetal ή os drivers/daemons.
Για χομπίστες έχει πλάκα η είδηση, για τους άλλους είναι απλά μία ανάμνηση.
Για μένα ειναι στην κατηγορία 8bit content. Δεν ξέρω γιατί έχουν λυσάξει με αυτή την εποχή. Αισθητικά (pixelated), παιχνίδια εντελώς άχρηστα, οθόνες crt. Η μουσική είχε χαβαλέ.
Για μένα η χρησιμότητα των 8bit είναι ότι λόγω απλότητας μπορείς να καταλάβεις πως λειτουργεί βασικά ένας υπολογιστής. Καμιά επαφή με σήμερα, αλλά γίνεται. Αντίστοιχα θεωρώ ότι θα ειχε νόημα και να δεις το λογισμικό.
Τώρα να πάρω μηχανάκια με δεν ξερω τι board να τρέχει emulator σε θήκη της εποχής να παίζει παιχνίδια και να γράφω κώδικά δεν το καταλαβαίνω.
Βλέπω των 8bit guy και όχι μόνο να έχουν αναπτύξει παίχνίδια για τα μηχανήματα της εποχής και μου κάνει τρομέρή εντύπωση τα λεφτά που ξοδευόνται και πως βγαίνει το εισόδημα τους.
Για μένα ειναι στην κατηγορία 8bit content. Δεν ξέρω γιατί έχουν λυσάξει με αυτή την εποχή. Αισθητικά (pixelated), παιχνίδια εντελώς άχρηστα, οθόνες crt. Η μουσική είχε χαβαλέ.
Για μένα η χρησιμότητα των 8bit είναι ότι λόγω απλότητας μπορείς να καταλάβεις πως λειτουργεί βασικά ένας υπολογιστής. Καμιά επαφή με σήμερα, αλλά γίνεται. Αντίστοιχα θεωρώ ότι θα ειχε νόημα και να δεις το λογισμικό.
Τώρα να πάρω μηχανάκια με δεν ξερω τι board να τρέχει emulator σε θήκη της εποχής να παίζει παιχνίδια και να γράφω κώδικά δεν το καταλαβαίνω.
Βλέπω των 8bit guy και όχι μόνο να έχουν αναπτύξει παίχνίδια για τα μηχανήματα της εποχής και μου κάνει τρομέρή εντύπωση τα λεφτά που ξοδευόνται και πως βγαίνει το εισόδημα τους.
Λέγεται "νοσταλγία". Νοσταλγία μία μοναδικής και υπέροχης εποχής (για όσους την ζήσανε).
Αισθητικά (pixelated), παιχνίδια εντελώς άχρηστα,
Μπορεί τα παιχνίδια να ήταν pixelated, αλλά έπαιρναν άριστα στο gameplay. Σε έκαναν να σκέφτεσαι και να κολλάς με το παιχνίδι ακόμα και τις ώρες που ήσουν εκτός και δεν το έπαιζες.
Για μένα ειναι στην κατηγορία 8bit content. Δεν ξέρω γιατί έχουν λυσάξει με αυτή την εποχή. Αισθητικά (pixelated), παιχνίδια εντελώς άχρηστα, οθόνες crt. Η μουσική είχε χαβαλέ.
Για μένα η χρησιμότητα των 8bit είναι ότι λόγω απλότητας μπορείς να καταλάβεις πως λειτουργεί βασικά ένας υπολογιστής. Καμιά επαφή με σήμερα, αλλά γίνεται. Αντίστοιχα θεωρώ ότι θα ειχε νόημα και να δεις το λογισμικό.
Τώρα να πάρω μηχανάκια με δεν ξερω τι board να τρέχει emulator σε θήκη της εποχής να παίζει παιχνίδια και να γράφω κώδικά δεν το καταλαβαίνω.
Βλέπω των 8bit guy και όχι μόνο να έχουν αναπτύξει παίχνίδια για τα μηχανήματα της εποχής και μου κάνει τρομέρή εντύπωση τα λεφτά που ξοδευόνται και πως βγαίνει το εισόδημα τους.
Οταν έχεις ζήσει την εποχή όπου κάθε byte μετρούσε και τι σημαίνει Peek / poke, όταν έχεις γράψει σε assembler και έχεις ζήσει την εποχή των demo και την φιλοσοφία πίσω από αυτά (code efficiency) και γενικά όλη την εξέλιξη από τον Atari 2600 μέχρι τa smartphones που πλέον πρακτικά είναι computers (και μάλιστα κάποιοι από εμας έχουμε προβλέψει που πάει το πράγμα), όταν βλέπεις λοιπόν ένα κουτι με android ή ένα application σε PC να σηκώνει ένα emulator που μπορεί να τρέχει ΟΤΙ φαντάζεσαι απο spectrum, C64, Amstrad κλπ κλπ ως και PS2/P23 και έχει ο Θεός, είναι κάτι το λιγότερο όμορφο.
Οσο για τα "αχρηστα" CRT κλπ, αυτά κάποτε μόνο άχρηστα δεν ήταν. Οπως αντίστοιχα άχρηστα δεν είναι σήμερα κάτι vintage γενικά, αυτοκίνητα μηχανές ή ότι vintage γενικότερα.
Καλό θα ήταν να θυμόμαστε ότι κάποτε υπήρχαν και τα τανκσάκια στο Atari 2600.. το quest for tyres μιας εταιρίας που τη λέγαν Sierra κλπ κλπ ;)
Από το όνομα και μόνο υποθέτω ότι φαίνεται το έτος γέννησης μου. Παιδί ήμουν και κάποιοι από σας ήσασταν γυμνάσιο/λύκειο. Δεν ξέρω αν έχουμε πολλά μέλη εδώ γεννημένη πριν το 60 για να ήταν ενήλικες μέσα στα 80ς.
Λέγεται "νοσταλγία". Νοσταλγία μία μοναδικής και υπέροχης εποχής (για όσους την ζήσανε).
Συμφωνώ αλλά να προσθέσω κάτι. Για μένα ήταν μια υπεροχη εποχή γιατί δεν υπήρχε κάτι αντίστοιχο. Απλά ήταν από το τίποτα σε κάτι για τα δεδομένα τότε φανταστικός.
Μπορεί τα παιχνίδια να ήταν pixelated, αλλά έπαιρναν άριστα στο gameplay. Σε έκαναν να σκέφτεσαι και να κολλάς με το παιχνίδι ακόμα και τις ώρες που ήσουν εκτός και δεν το έπαιζες.
Όπως γράφω και πιο πάνω, πιστεύω ότι ο κυριότερος παράγοντας ήταν ο νεοτερισμός. Δεν υπήρχε κάτι αντίστοιχο. Καθαρά με βάση αυτό, υπήρχαν νέες ιδέες με το κιλό. Ήταν καλύτερα παιχνίδια γιατί κολάγαμε με κάθε τι καινούργιο καθώς δεν υπήρχε μέτρο σύγκρισης; Δεν ξέρω.
Υπάρχει μια σημαντική διαφορά που ειναι και λόγος που δεν παίζω σύγχρονα παιχνίδια τόσο πολύ. Ήταν απλά λόγο περιορισμών. Αλλά υπάρχουν και μοντέρνα απλά παιχνίδια.
Οταν έχεις ζήσει την εποχή όπου κάθε byte μετρούσε και τι σημαίνει Peek / poke, όταν έχεις γράψει σε assembler και έχεις ζήσει την εποχή των demo και την φιλοσοφία πίσω από αυτά (code efficiency) και γενικά όλη την εξέλιξη από τον Atari 2600 μέχρι τa smartphones που πλέον πρακτικά είναι computers (και μάλιστα κάποιοι από εμας έχουμε προβλέψει που πάει το πράγμα), όταν βλέπεις λοιπόν ένα κουτι με android ή ένα application σε PC να σηκώνει ένα emulator που μπορεί να τρέχει ΟΤΙ φαντάζεσαι απο spectrum, C64, Amstrad κλπ κλπ ως και PS2/P23 και έχει ο Θεός, είναι κάτι το λιγότερο όμορφο.
Οσο για τα "αχρηστα" CRT κλπ, αυτά κάποτε μόνο άχρηστα δεν ήταν. Οπως αντίστοιχα άχρηστα δεν είναι σήμερα κάτι vintage γενικά, αυτοκίνητα μηχανές ή ότι vintage γενικότερα.
Καλό θα ήταν να θυμόμαστε ότι κάποτε υπήρχαν και τα τανκσάκια στο Atari 2600.. το quest for tyres μιας εταιρίας που τη λέγαν Sierra κλπ κλπ ;)
Δεν είχα την τιμή για assembly αλλά έχω κάνει αρκετά malloc. Και ναι ήταν πολύ πιο δύσκολα αλλά αυτό δεν σημαίνει ότι πρέπει να πάμε πίσω εκεί.
Με εξαιρεση κάποια τεχνικά χαρακτηριστικά των crt δεν βρίσκω ακριβώς την αξία τους συγκριτικά. Μην ξεχνάμε ότι πολλά παιχνίδια είχαν γραφτεί με βάση τα χαρακτηριστικά των crt, composite και s-video που σε συγχρονα ψηφιακά πάνελ φαίνεται χάλια. Δεν έκανε την crt καλύτερη επειδή το content είχε γίνει optimize για αυτή και αλλού φαινεται χάλια.
Υπάρχει διαφορά μεταξύ της αξίας για τον συλλέκτη και της λειτουργικής αξίας. Η πρώτη έχει αποκλειστικά συναισθηματικά χαρακτηριστικά και η 2η λιγότερο καθώς όλοι τελικά με συναίσθημα αγοράζουμε.
Όμως δεν βρίσκω αξία στο να γράφονται παιχνίδια για τέτοιο εξοπλισμό. Ας γίνει όση συλλογή θέλουν τα λεφτά που ξοδεύονται σε ανάπτυξη νέου κώδικα και boards μου φαινεται σπατάλη.
Tzitziloni
29-04-24, 18:31
Από το όνομα και μόνο υποθέτω ότι φαίνεται το έτος γέννησης μου. Παιδί ήμουν και κάποιοι από σας ήσασταν γυμνάσιο/λύκειο. Δεν ξέρω αν έχουμε πολλά μέλη εδώ γεννημένη πριν το 60 για να ήταν ενήλικες μέσα στα 80ς.
Συμφωνώ αλλά να προσθέσω κάτι. Για μένα ήταν μια υπεροχη εποχή γιατί δεν υπήρχε κάτι αντίστοιχο. Απλά ήταν από το τίποτα σε κάτι για τα δεδομένα τότε φανταστικός.
Όπως γράφω και πιο πάνω, πιστεύω ότι ο κυριότερος παράγοντας ήταν ο νεοτερισμός. Δεν υπήρχε κάτι αντίστοιχο. Καθαρά με βάση αυτό, υπήρχαν νέες ιδέες με το κιλό. Ήταν καλύτερα παιχνίδια γιατί κολάγαμε με κάθε τι καινούργιο καθώς δεν υπήρχε μέτρο σύγκρισης; Δεν ξέρω.
Υπάρχει μια σημαντική διαφορά που ειναι και λόγος που δεν παίζω σύγχρονα παιχνίδια τόσο πολύ. Ήταν απλά λόγο περιορισμών. Αλλά υπάρχουν και μοντέρνα απλά παιχνίδια.
Δεν είχα την τιμή για assembly αλλά έχω κάνει αρκετά malloc. Και ναι ήταν πολύ πιο δύσκολα αλλά αυτό δεν σημαίνει ότι πρέπει να πάμε πίσω εκεί.
Με εξαιρεση κάποια τεχνικά χαρακτηριστικά των crt δεν βρίσκω ακριβώς την αξία τους συγκριτικά. Μην ξεχνάμε ότι πολλά παιχνίδια είχαν γραφτεί με βάση τα χαρακτηριστικά των crt, composite και s-video που σε συγχρονα ψηφιακά πάνελ φαίνεται χάλια. Δεν έκανε την crt καλύτερη επειδή το content είχε γίνει optimize για αυτή και αλλού φαινεται χάλια.
Υπάρχει διαφορά μεταξύ της αξίας για τον συλλέκτη και της λειτουργικής αξίας. Η πρώτη έχει αποκλειστικά συναισθηματικά χαρακτηριστικά και η 2η λιγότερο καθώς όλοι τελικά με συναίσθημα αγοράζουμε.
Όμως δεν βρίσκω αξία στο να γράφονται παιχνίδια για τέτοιο εξοπλισμό. Ας γίνει όση συλλογή θέλουν τα λεφτά που ξοδεύονται σε ανάπτυξη νέου κώδικα και boards μου φαινεται σπατάλη.
Καλά θα κάνουν οι σύγχρονοι coders & devs να μην σπαταλούν αλόγιστα τα resources, θα έλεγα εγώ.
Καλά θα κάνουν οι σύγχρονοι coders & devs να μην σπαταλούν αλόγιστα τα resources, θα έλεγα εγώ.
Παρά πολύ σωστά.
Καλά θα κάνουν οι σύγχρονοι coders & devs να μην σπαταλούν αλόγιστα τα resources, θα έλεγα εγώ.
Έχω πολλές διαφωνίες με τους μοντέρνους devs αλλά όχι αυτό. Επίσης η προτροπή αυτή, μου θυμίζει την διαφωνία μεταξύ managed και non managed runtime και σταματώ εδώ γιατί θα εμπλακούμε σε μεγάλο offtopic
Καλά θα κάνουν οι σύγχρονοι coders & devs να μην σπαταλούν αλόγιστα τα resources, θα έλεγα εγώ.
Πολύ γενικόλογο αυτό που αναφέρεις. Και στο γράφει αυτό, ένας που είναι το επαγγέλματος (software developer γαρ).
Το ισχυρότερο hardware, βγαίνει για να τρέχει σε αυτό σύγχρονο (και βαρύτερο) software. Το σύγχρονο software είναι βαρύτερο, γιατί προφανώς κάνει πολύ περισσότερα πράγματα από το software που είχε βγει λ.χ. πριν από 30 χρόνια. Αλλιώς, θα είμασταν όλοι, ακόμα με 386. ;)
Πολύ γενικόλογο αυτό που αναφέρεις. Και στο γράφει αυτό, ένας που είναι το επαγγέλματος (software developer γαρ).
Το ισχυρότερο hardware, βγαίνει για να τρέχει σε αυτό σύγχρονο (και βαρύτερο) software. Το σύγχρονο software είναι βαρύτερο, γιατί προφανώς κάνει πολύ περισσότερα πράγματα από το software που είχε βγει λ.χ. πριν από 30 χρόνια. Αλλιώς, θα είμασταν όλοι, ακόμα με 386. ;)
Το ένα δεν ακυρώνει το άλλο. Το efficiency δεν έχει να κάνει με το τι κάνει ο κώδικας αλλά πως είναι γραμμένος.
Το ένα δεν ακυρώνει το άλλο. Το efficiency δεν έχει να κάνει με το τι κάνει ο κώδικας αλλά πως είναι γραμμένος.
Efficiency ως προς τι; Ως προς την ταχύτητα εκτέλεσης, ως προς την μνήμη, ως προς το I/O;
Δεν είναι έτσι απλά τα πράγματα, καθώς όπως καταλαβαίνεις παίζουν πολλοί παράγοντες ρόλο. Άλλωστε, όσο πιο πολύπλοκος γίνεται ο κώδικας, τόσο δυσκολότερο είναι να γίνει και πιο efficient.
Επίσης, μην ξεχνάμε το maintainability του κώδικα. Αν είναι π.χ. να γίνει ο κώδικας υπερβολικά πολύπλοκος και στρυφνός (aka spaghetti), προκειμένου να τρέχει λ.χ. 5% πιο γρήγορα, ώστε να δουλεύει επαρκώς γρήγορα και σε παλιότερα συστήματα, τότε η συντριπτική πλειοψηφία των devs, μαζί και εγώ, απλά δεν πρόκειται να το κάνει.
Η δυνατότητα μελλοντικών αλλαγών και διορθώσεων σε ένα τέτοιο πρόγραμμα, είναι από εξαιρετικά δύσκολη έως αδύνατη θα έλεγα.
Efficiency ως προς τι; Ως προς την ταχύτητα εκτέλεσης, ως προς την μνήμη, ως προς το I/O;
Δεν είναι έτσι απλά τα πράγματα, καθώς όπως καταλαβαίνεις παίζουν πολλοί παράγοντες ρόλο. Άλλωστε, όσο πιο πολύπλοκος γίνεται ο κώδικας, τόσο δυσκολότερο είναι να γίνει και πιο efficient.
Επίσης, μην ξεχνάμε το maintainability του κώδικα. Αν είναι π.χ. να γίνει ο κώδικας υπερβολικά πολύπλοκος και στρυφνός (aka spaghetti), προκειμένου να τρέχει λ.χ. 5% πιο γρήγορα, ώστε να δουλεύει επαρκώς γρήγορα και σε παλιότερα συστήματα, τότε η συντριπτική πλειοψηφία των devs, μαζί και εγώ, απλά δεν πρόκειται να το κάνει.
Η δυνατότητα μελλοντικών αλλαγών και διορθώσεων σε ένα τέτοιο πρόγραμμα, είναι από εξαιρετικά δύσκολη έως αδύνατη θα έλεγα.
Δεν ήθελα να βγω offtopic αλλά σαν επαγγελματίας του χώρου, προτιμώ οτιδήποτε δεν θα σκοτώσει τον σέρβερ, ή το process γιατί πρώτα από όλα efficiency. Αν δεν είχαν υπάρξει τα managed runtimes και σε κάποιο βαθμό οι πιο εύκολες γλώσσες, internet δεν θα υπήρχε ποτέ και ούτε cloud. Δεδομένου του πως τα περισσότερα process γίνονται περιοδικά recycle και γενικά κλωνοποιουνται, το πρόβλημα δεν είναι τόσο η σπατάλη του developer όχι οι προσδοκίες που έχουν δημιουργήσει το λεγόμενο micro service architecture. Πάρε ένα k8s cluster που σηκώνει το runtime 500χιλ φορές για να τρέξει την πιο απλή εφαρμογή του κόσμου.
Και μιας και βγήκα offtopic το πρόβλημα που προσωπικά έχω είναι η σχεδόν παντελης άγνοια και αδιαφορία που καλλιεργείται για το που τρέχει ο κώδικας vm,os, process, thread και γενικά για το production και η γενικότερη προώθηση του λεγόμενου developer architecture.
Tzitziloni
01-05-24, 13:54
Πολύ γενικόλογο αυτό που αναφέρεις. Και στο γράφει αυτό, ένας που είναι το επαγγέλματος (software developer γαρ).
Το ισχυρότερο hardware, βγαίνει για να τρέχει σε αυτό σύγχρονο (και βαρύτερο) software. Το σύγχρονο software είναι βαρύτερο, γιατί προφανώς κάνει πολύ περισσότερα πράγματα από το software που είχε βγει λ.χ. πριν από 30 χρόνια. Αλλιώς, θα είμασταν όλοι, ακόμα με 386. ;)
Δεν κάνει πάντα περισσότερα ούτε αυτό πρέπει να αποτελεί δικαιολογία. Όπως και να έχει, πρέπει να είναι προσεκτικά γραμμένο. With great power comes great responsibility, δεν λένε; Ισχύει και σε αυτή την περίπτωση.
- - - Updated - - -
Efficiency ως προς τι; Ως προς την ταχύτητα εκτέλεσης, ως προς την μνήμη, ως προς το I/O;
Δεν είναι έτσι απλά τα πράγματα, καθώς όπως καταλαβαίνεις παίζουν πολλοί παράγοντες ρόλο. Άλλωστε, όσο πιο πολύπλοκος γίνεται ο κώδικας, τόσο δυσκολότερο είναι να γίνει και πιο efficient.
Επίσης, μην ξεχνάμε το maintainability του κώδικα. Αν είναι π.χ. να γίνει ο κώδικας υπερβολικά πολύπλοκος και στρυφνός (aka spaghetti), προκειμένου να τρέχει λ.χ. 5% πιο γρήγορα, ώστε να δουλεύει επαρκώς γρήγορα και σε παλιότερα συστήματα, τότε η συντριπτική πλειοψηφία των devs, μαζί και εγώ, απλά δεν πρόκειται να το κάνει.
Η δυνατότητα μελλοντικών αλλαγών και διορθώσεων σε ένα τέτοιο πρόγραμμα, είναι από εξαιρετικά δύσκολη έως αδύνατη θα έλεγα.
Η υπερβολική βελτιστοποίηση της απόδοσης είναι edge case -δεν αναφέρομαστε σ' αυτό, νομίζω. Ο κώδικας πρέπει να είναι απλός, καλογραμμένος και να μην "σπαταλάει" άδικα resources. Πολύ βασικό αλλά όχι εύκολο. Καταρχάς ο απλός κώδικας είναι κάτι δύσκολο από μόνο του και έρχεται μόνο με την εμπειρία. Ακολουθεί η "κακή" χρήση των frameworks τα οποία παρέχουν πολλά by default αλλά αν θες το αποτέλεσμα να είναι γρήγορο και scalable, πρέπει να ξέρεις τι σου γίνεται.
- - - Updated - - -
Και μιας και βγήκα offtopic το πρόβλημα που προσωπικά έχω είναι η σχεδόν παντελης άγνοια και αδιαφορία που καλλιεργείται για το που τρέχει ο κώδικας vm,os, process, thread και γενικά για το production και η γενικότερη προώθηση του λεγόμενου developer architecture.
Εφόσον το έχεις εντοπίσει, καλό είναι να το αντιμετωπίσεις γιατί όσο καλός και αν είναι ο devOps της παρέας, πάντα θα σε περιμένουν εκπλήξεις εκεί ακριβώς που νόμιζες οτι είχες ολοκληρώσει τη δουλειά ;)
Συμφωνώ με τον chat και τον Tzitziloni.
Το σημερινό software γίνεται ολοένα και περισσότερο pessimized (το αντίθετο του optimized) και υπερκαταναλώνει αδικαιολόγητα υπέρογκα resources. Ναι μεν δεν πρέπει να κάνεις premature optimization, αλλά προσπάθησε να μην κάνεις το αντίθετο, δηλαδή να μην το κάνεις πολύ αργό/μνημοβόρο/ioβορο χωρίς λόγο. Θα πρέπει καθώς γράφεις κώδικα να τηρείς το non-pessimization. Δηλαδή να γράφεις κώδικα που δεν καταναλώνει πολύ περισσότερα cpu/mem/io resources από όσα χρειάζεται (στο περίπου), έχοντας στο νου σου στο περίπου τι overhead μπορεί να έχει το κάθε τι που γράφεις. Αυτός είναι καλός κώδικας. Αλλα χρειάζεται να είσαι καλός προγραμματιστής για να έχεις αυτή την γνώση να τα αντιλαμβάνεσαι αυτά. Τα εξηγεί πολύ ωραία ο Casey Muratori στο:
https://www.youtube.com/watch?v=Ge3aKEmZcqY&t=8156s
Εφόσον το έχεις εντοπίσει, καλό είναι να το αντιμετωπίσεις γιατί όσο καλός και αν είναι ο devOps της παρέας, πάντα θα σε περιμένουν εκπλήξεις εκεί ακριβώς που νόμιζες οτι είχες ολοκληρώσει τη δουλειά ;)
Χρόνια τώρα, μόλις δούλεψα με άτομα που δεν είχαν εμπειρία εκτός on-premise και εφαρμογές που πουλιούνται στον πελάτη και τρέχουν για καιρό.
Αλλά αναρωτιέμαι μήπως γινομαι λίγο σαν τους C++σιστές της γενιάς μου όταν ξεκιναγα και το αστείο ήταν ότι και εγώ από εκεί ερχόμουν σνομπάροντας το managed runtime.
Μπορεί τα παιχνίδια να ήταν pixelated, αλλά έπαιρναν άριστα στο gameplay. Σε έκαναν να σκέφτεσαι και να κολλάς με το παιχνίδι ακόμα και τις ώρες που ήσουν εκτός και δεν το έπαιζες.
Επισης κατι που ειναι αδιανοητο σημερα: Αγοραζες ενα game ή εφαρμογη και ηταν το τελικο προϊον. Αν τυχον ειχε καποιο προβλημα θα το ειχε μαθει το συμπαν και θα εκραζαν την εταιρια οτι εβγαλε κατι προβληματικο. Σημερα δεν υφισταται η εννοια της εφαρμογης ή του game σε τελικη κατασταση. Ειναι λες και αγοραζεις alpha h beta προγραμματα και κανεις real-time debugging. Στην ουσια πρεπει να αποδεχτεις οτι αγορασες κατι ημιτελες με απειρα bugs που θελουν συνεχες patching εις το διηνεκες.
Επισης κατι που ειναι αδιανοητο σημερα: Αγοραζες ενα game ή εφαρμογη και ηταν το τελικο προϊον. Αν τυχον ειχε καποιο προβλημα θα το ειχε μαθει το συμπαν και θα εκραζαν την εταιρια οτι εβγαλε κατι προβληματικο.
Και παλιά υπήρχαν DLC σε παιχνίδια, φυσικά δεν ήταν τόσο διαδεδομένα όσο είναι σήμερα. Επίσης κυκλοφορούσαν και patch για διόρθωση τυχών bugs. Κάτι που θεωρώ ότι είναι πολύ διαφορετικό το παλιό σε σχέση με το καινούριο είναι ότι έπαιρνες το παιχνίδι σε CD/DVD, το έκανες εγκατάσταση και απλώς έπαιζες. Τώρα πολλά παιχνίδια δεν κυκλοφορούν καν σε δισκάκι, αλλά και να τα βρεις σε δισκάκι θα πρέπει να κάνεις λογαριασμό στο Steam και να το ενεργοποιήσεις πρώτα με τον σειριακό που θα είναι μέσα στο κουτί. Και το δισκάκι είναι απλώς backup του παιχνιδιού, το οποίο αν δεν είναι ενημερωμένο ενδεχομένως να κατεβάσει και κάποια patch που αναλόγως και το παιχνίδι δεν αποκλείεται να είναι από μερικά KB μέχρι και κάμποσα GB (στην ουσία μπορεί να χρειαστεί να ξανακατεβάσει το παιχνίδι από την αρχή οπότε το backup είναι άχρηστο). Επίσης από την στιγμή που το κλειδί το εισάγεις στον λογαριασμό σου στο Steam, η κόπια που έχεις χάνει οποιαδήποτε αξία μεταπώλησης μιας και το κλειδί δένεται με τον προσωπικό σου λογαριασμό και δεν μπορείς να το δώσεις σε άλλον, ενώ παλιά που ήταν σε δισκάκια, η ίδια κόπια μπορεί να άλλαζε και 50 χέρια, εγώ προσωπικά θυμάμαι είχα αγοράσει ένα παιχνίδι όταν ήμουν πρωτοετής στην σχολή μου και είχε γυρίσει όλο το τμήμα μου, το είχα δανείσει σε όλα τα παιδιά.
Επισης κατι που ειναι αδιανοητο σημερα: Αγοραζες ενα game ή εφαρμογη και ηταν το τελικο προϊον. Αν τυχον ειχε καποιο προβλημα θα το ειχε μαθει το συμπαν και θα εκραζαν την εταιρια οτι εβγαλε κατι προβληματικο. Σημερα δεν υφισταται η εννοια της εφαρμογης ή του game σε τελικη κατασταση. Ειναι λες και αγοραζεις alpha h beta προγραμματα και κανεις real-time debugging. Στην ουσια πρεπει να αποδεχτεις οτι αγορασες κατι ημιτελες με απειρα bugs που θελουν συνεχες patching εις το διηνεκες.
Δεν βλέπω όμως και τον αντίλογο, ότι δηλαδή πολύπλοκο προϊόν παραδίδεται σε χρόνο ρεκόρ για τους ανυπόμονους.
Η ανυπομονησια είναι δείγμα των καιρών
Προσωπικά δεν συμφωνώ όταν το ξεσκίζουν το θέμα, βλέπε r1 κτλ
Δεν βλέπω όμως και τον αντίλογο, ότι δηλαδή πολύπλοκο προϊόν παραδίδεται σε χρόνο ρεκόρ για τους ανυπόμονους.
Η ανυπομονησια είναι δείγμα των καιρών
Για το πιο πολυπλοκο προϊον ισχυει αλλα τα σημερινα release cycles ειναι πολυ πιο αργα, ειδικα στα λειτουργικα της MS. Μπορει να θελει 3-5 χρονια για νεα εκδοση windows αλλά με το καλημερα ειναι γεματη bugs και προβληματα.
Για το πιο πολυπλοκο προϊον ισχυει αλλα τα σημερινα release cycles ειναι πολυ πιο αργα, ειδικα στα λειτουργικα της MS. Μπορει να θελει 3-5 χρονια για νεα εκδοση windows αλλά με το καλημερα ειναι γεματη bugs και προβληματα.
Από την μία πλευρά έχεις το πολύ γρήγορο internet, που κάνει εύκολο και γρήγορο το distribution των patches και από την άλλη πλευρά, έχεις τους διάφορους μανατζαρέους που θέλουν πάση θυσία να πιάνουν τα milestones (και να καρπώνονται τα bonuses βεβαίως-βεβαίως), βγάζοντας releases εμφανώς μη επαρκώς τεσταρισμένες και τίγκα στα issues.
Και οι 2 παράγοντες, προφανώς οδηγούν σε μια FUBAR κατάσταση.
Για το πιο πολυπλοκο προϊον ισχυει αλλα τα σημερινα release cycles ειναι πολυ πιο αργα, ειδικα στα λειτουργικα της MS. Μπορει να θελει 3-5 χρονια για νεα εκδοση windows αλλά με το καλημερα ειναι γεματη bugs και προβληματα.
Δεν θα συμφωνήσω και εξαρτάται τι θεωρείται πραγματικά new version. Και ποια κομμάτια αντιλαμβάνεσαι εσύ ως νέα.
Πχ στα Vista έγινε refactor όλο το graphics subsystem χωρίς όμως να δει κάτι ο χρήστης.
Χωρίς να το ψάχνω τόσο πολύ πια, για μένα βγάζει σοβαρό service pack κάθε 6 ή 12 μήνες. Στα xp ή στα vista θυμάσαι; Πόσο καιρό πήρε να σταθεροποιηθεί το core μαζί με τους drivers. Τότε δεν είχανε και όλοι broadband να κατεβάζουμε windows update με τα τσουβαλια.
Τώρα τα 11 με τα 10 με το latest release λίγη διαφορά είχαν με εξαίρεση το αισθητικό. Μαρκετινγκ ήταν. Συνεπώς δεν μετράω χρόνια διαφοράς.
Τώρα αν θες να μείνεις στην Wikipedia και στα official release dates τότε θα έχεις δίκιο αλλά για μένα θα συγκρίνεις ανόμοια πράγματα που είναι και λίγο χαρακτηριστικό αυτής της επιχειρηματολογίας.
@ ADSLgr.com All rights reserved.