Σχόλια για Bernstein (was: Re: Linux Stability)
Giorgos Keramidas
keramida at ceid.upatras.gr
Tue May 28 17:01:01 EEST 2002
------------------------------------------------------------------
Προσοχή, ακολουθεί ΠΟΛΥ μεγάλο γράμμα.
------------------------------------------------------------------
Διαβάστε μόνο αν δεν βαριέστε να δείτε γιατί -δεν- πιστεύω
πως ο Dan Bernstein είναι η αφρόκρεμα των προγραμματιστών.
On 2002-05-23 04:31, Panagiotis Vossos wrote:
> Giorgos Keramidas <keramida at ceid.upatras.gr> writes:
> > On 2002-05-23 03:11, Panagiotis Vossos wrote:
> > > Vlepe http://groups.yahoo.com/group/djb-qmail/message/38191 gia
> > > perissoteres plirofories.
> >
> > To mono reply pou phra htan:
> > "Aren't you supposed to be somewhere else?"
>
> To idio mou vgazei kai mena me to links. Me mozilla kai lynx pantos,
> ama kaneis accept ena prosorino cookie sto vgazei kanonika.
Με w3m και links που χρησιμοποιώ συνήθως (έχοντας απενεργοποιημένα τα
περίεργα cookies) βλέπω το εξής:
Redirection loop detected
(http://groups.yahoo.com/group/djb-qmail/auth?check=G&done=%2Fgroup%2Fdjb-qmail%2Fmessage%2F38191)
Δοκίμασα και με lynx, με ενεργοποιημένα όλα τα cookies πάλι σε w3m και
links, με Netscape, τέλος πάντων κάπως το κατέβασα το mail :)
Διαβάζοντας όσα λέει, βλέπω ότι δεν είναι κι άσχημα. Πολλά από αυτά
είναι μάλλον αστήριχτες γνώμες μάλλον. Είναι κάτι που έχω ξαναδεί, να
λέει κάποιος "άκουσα ότι το να προγραμματίζεις έτσι είναι ασφαλές,
οπότε ο Bernstein που προγραμματίζει έτσι, γράφει ασφαλή προγράμματα."
Υπάρχουν διάφορα flaws σε αυτό το επιχείρημα, με κυριότερο το "άκουσα
ότι..." που δεν συνεπάγεται αυτόματα αλήθεια.
Ας τα πάρουμε ένα ένα όμως.
> From: craig at j...
> Date: Fri Jan 14, 2000 4:35 pm
> Subject: Crispin v. Bernstein (was Re: Maildir format)
> From my (very limited) perspective, both Mark and Dan eschew some of
> the "common wisdom" about Unix and related matters, and both have
> some good, or at least plausible, reasons.
[Σημείωση: eschew == avoid, shun.]
Ναι, τουλάχιστον ο Bernstein αποφεύγει μετά μανίας να γράψει κώδικα
που χρησιμοποιεί το στυλ ή τις δυνατότητες ενός UNIX συστήματος. Για
παράδειγμα, δεν γράφει Makefiles παρά μόνο για ελάχιστα πράγματα.
Δεν χρησιμοποιεί τις μεταβλητές περιβάλλοντος CC και CFLAGS που είναι
πλέον όχι απλά παράδοση αλλά κάτι hardwired στο μυαλό κάθε UNIX
προγραμματιστή. Το να μην χρησιμοποιείς `standard' εργαλεία όταν
προγραμματίζεις είναι καταφανής παράβαση του POLA (principle of least
astonishment). Κάποιος που βλέπει ένα tarball με πηγαίο κώδικα για το
πρόγραμμα X που τρέχει σε UNIX, ενστικτωδώς ψάχνει να βρει κάπου εκεί
μέσα ένα Makefile για να δει πως θα το κάνει compile. Το να έχεις ένα
Makefile που το install: target του λέει μόνο τα εξής:
install: \
load install.o fifo.o hier.o auto_qmail.o auto_split.o auto_uids.o \
strerr.a substdio.a open.a error.a str.a fs.a
./load install fifo.o hier.o auto_qmail.o auto_split.o \
auto_uids.o strerr.a substdio.a open.a error.a str.a fs.a
έχει πάρα πολλά μειονεκτήματα. Χαρακτηριστικά στυλ, που κάνουν τον
κώδικα δυσανάγνωστο. Μη-standard εντολές. Κι άλλα διάφορα. Ο
Bernstein δεν χρησιμοποιεί το make(1) για να γράψει Makefiles, αλλά
σαν ένα εύκολο τρόπο να δηλώσει fixed dependencies στα κομμάτια του
προγράμματός του. Ποια είναι η διαφορά με κάτι σαν το εξής;
# Name of the executable program.
PROG= qmail
# Static libraries.
SLIBS= fifo.a hier.a auto_qmail.a auto_split.a auto_uids.a \
strerr.a substdio.a open.a error.a str.a fs.a
install: ${PROG}
${PROG}: ${SLIBS} ${OBJS}
${CC} -o ${CFLAGS} ${PROG} ${OBJS} ${SLIBS} ${LDFLAGS}
Πόσο εύκολο είναι να προσθέσει κάποιος ένα καινούριο κομμάτι σε ένα
Makefile γραμμένο με τον πρώτο τρόπο και πόσο εύκολο είναι με τον
δεύτερο; Μήπως στο πρώτο Makefile θά πρεπε να υπάρχουν και κάποια
σχόλια που και που; Το qmail είναι ένα μεγάλο πρόγραμμα. Το source
έχει ελάχιστα έως μηδαμινά σχόλια. Το μόνο σχόλιο που έχει το
Makefile είναι το εξής:
hades+charon:/tmp/qmail-1.03$ grep '^[[:space:]]*#' Makefile
# Don't edit Makefile! Use conf-* for configuration.
hades+charon:/tmp/qmail-1.03$ _
Παράβαλε αυτό με το src/Makefile.inc1 του FreeBSD που σχεδόν το 23%
των γραμμών είναι σχόλια:
hades+charon:/usr/src$ grep '^[[:space:]]*#' Makefile.inc1 | wc -l
171
hades+charon:/usr/src$ wc -l Makefile.inc1
757 Makefile.inc1
hades+charon:/usr/src$ echo 'scale=3;17100/757' | bc
22.589
Θα μου πει κάποιος τα σχόλια σε πείραξαν τώρα; Ναι, φυσικά. Ένα
καλογραμμένο πρόγραμμα κάνει διακριτική και σοφή χρήση των σχολίων.
Δεν έχει παντελή έλλειψη σχολίων!
Επίσης, στο Makefile του qmail (από όπου πήρα το παραπάνω παράδειγμα),
τι κάνει η εντολή `load'; Είναι κάποια εντολή που θα την δει κάποιος
και αυτόματα θα καταλάβει τι κάνει; Μετά από λίγο ψάξιμο ανακαλύπτει
κανείς ότι είναι κάποιο build-time πρόγραμμα που χρησιμοποιεί το
qmail. Φαίνεται από το παρακάτω κομμάτι:
load: \
make-load warn-auto.sh systype
( cat warn-auto.sh; ./make-load "`cat systype`" ) > load
chmod 755 load
Πανέμορφα. Και τώρα μπορεί κάποιος να μου πει τι κάνει το make-load?
Καλά είναι προφανές από το όνομα, αλλά δεν καταλαβαίνω γιατί όλη αυτή
η φασαρία για να μην χρησιμοποιήσει κάποιος το ${CC} που είναι γνωστή
και portable μεταβλητή για να αναφέρεται κανείς στον system-compiler.
Και το γέλιο συνεχίζεται όταν παρακάτω στο Makefile ανακαλύψει κανείς:
make-load: \
make-load.sh auto-ccld.sh
cat auto-ccld.sh make-load.sh
Δηλαδή, ο πιο `καλός τρόπος' που σκέφτηκε αυτός ο τρομερά έξυπνος
προγραμματιστής για να κάνει το πρόγραμμα να είναι εύκολο να το
καταλάβει κανείς, συνοψίζεται στα εξής:
* Για κάποιο λόγο, δεν χρησιμοποιεί το ${CC} στο Makefile του.
Πουθενά. Είναι κάτι που είναι παράδοση πλέον στο UNIX,
οπότε δεν είναι καλό να το χρησιμοποιούμε.
* Όταν κάνει link το τελικό του πρόγραμμα χρησιμοποιεί το δικό
του πρόγραμμα, που λέγεται load. Έτσι, δεν έχει σημασία αν
έχει γίνει audit ο κώδικας του system linker, αφού πρέπει
κάποιος να διαβάσει και να σιγουρευτεί ότι και το load δεν
έχει εισάγει κάποια bugs ή security προβλήματα στο στάδιο
του linking.
* Το load φτιάχνεται από το make-load. Έτσι. Επειδή ένα
έξτρα στάδιο στο auditing ενός προγράμματος δεν είναι ποτέ
αρκετό.
* Φυσικά, όπου υπάρχουν δύο, κάποια στιγμή πρέπει να έρθει και
τρίτος μαζί με κάποιον τέταρτο. Οπότε το make-load είναι
κάτι που δημιουργείται από το make-load.sh με βάση το
auto-ccld.sh
Και η αλυσίδα συνεχίζεται, με το auto-ccld.sh και τα αρχεία που
διαβάζει αυτό για να κάνει τις ρυθμίσεις του. Φυσικά ούτε κουβέντα
για τον standard τρόπο να γραφτεί ένα Makefile, που χρησιμοποιεί τα
CC, LD, CFLAGS, CXXFLAGS, LDFLAGS, και όλα αυτά τα χαζά πράγματα που
κάθονται και μαθαίνουν οι UNIX προγραμματιστές. Είναι πιο καλά να
μάθουν όλοι από πέντε νέα εργαλεία για κάθε πρόγραμμα που
χρησιμοποιούν. Έτσι θα γράφουν πιο γρήγορα και πιο καλά κώδικα.
NOT.
Οι συμβάσεις υπάρχουν εκεί για να ξέρει ο καθένας όταν βλέπει ένα
Makefile τι είναι το κάθε κομμάτι του. Τα πρότυπα υπάρχουν εκεί γιατί
έτσι έχουμε όλοι οι προγραμματιστές μια κοινή βάση από γνώσεις, που
δεν χρειάζεται να "ξανα-μαθαίνουμε" πάλι και πάλι, κάθε φορά που
βλέπουμε τον πηγαίο κώδικα ενός νέου προγράμματος.
Φάουλ για τον κύριο Bernstein η εμμονή του να μην ακολουθεί τον
standard τρόπο, ούτε καν και στο στυλ του κώδικα.
> For example, I recall Mark explaining to me various reasons why
> MIT's ITS operating system was superior to DEC's TOPS-10 back around
> 1975 -- he claimed the dispatch method of ITS'
> kernel-call-from-user-program (to use a bit of recognizable modern
> lingo; back then, it was "UUO", IIRC) was actually *faster* than
> TOPS-10, despite the fact that its API was (sixchar-)name-based vs.
> TOPS-10's number-(aka-offset-into-what-one-
> would-assume-was-a-table-of-jump-targets-)based, making the
> advantage of ITS' early version of dynamic linking even more useful.
Εμπειρικά δεδομένα από τρίτους, για συστήματα που δεν ξέρω καν αν
είναι πλέον σε χρήση. Κατ' αρχήν η αξία της πληροφορίας που δίνει ο
`Mark' είναι μηδενική για σημερινά συστήματα. Αν κάποιος πει σήμερα
"το DOS ήταν πιο γρήγορο από τα Windows 2000, γιατί δεν είχε access
lists, χρήστες και άδειες χρηστών" πες μου ποιος δεν θα του γελάσει
κατάμουτρα.
> More recently, ISTR seeing Mark complain about Unix reliability and
> scalability, especially vis-a-vis NFS (locking and all that),
> perhaps on USENET.
Κάποια στιγμή παραπονέθηκε ο Mark επειδή κάποια υλοποίηση του NFS που
είδε σε UNIX έχει προβλήματα με locking. Ναι, και; Αυτό με ποιο
ακριβώς τρόπο κάνει τον Mark καλό προγραμματιστή; Η με ποιο τρόπο
μειώνει την αξία του UNIX application programming interface; Προσοχή,
δεν μιλώ για το NFS. Για το UNIX API μιλώ. Τα system calls, τα
library functions και τα userland εργαλεία που έχει ένα σύστημα που
ακολουθεί πιστά τα πρότυπα SUSv2 και SUSv3 (Single Unix Specification,
βλ. παλιότερα posts μου στη λίστα).
Δηλαδή αν κάποιος αποδείξει ότι η Samba έχει πρόβλημα με τα large
files (όπου large, ένα λογικό νούμερο) ενώ το λειτουργικό που την
στηρίζει δεν έχει, φταίει το λειτουργικό;
Φάουλ 2.
> So, while I can accept that Mark and Dan don't like each other (and
> won't comment on why I don't find that surprising on either side of
> the equation, since lots of people don't like me either ;-), and
> while I wouldn't be surprised to find that they have fundamental
> disagreements about what's right or wrong about the predominant
> Unix-etc. software- development model, it seems to me they might
> well have points of strong *and* important agreement, which I'd
> someday like to explore.
Κάτσε μας μπέρδεψες. Να το κάνουμε πιο απλό το πράγμα. Ο Den
και ο Mark πιστεύουν και οι δυο πως κάποια πράγματα με το UNIX είναι
καλά, και άλλα είναι άσχημα. Λογικό μέχρι εδώ. Διαφωνούν όμως σε
βασικά πράγματα για το τί είναι καλό και τι όχι. Φαίνεται όμως πως
συμφωνούν σε πολλά πράγματα. ΟΚ, καλό κι αυτό. Υπάρχουν δυο άτομα
δηλαδή που έχουν ο καθένας την δική του προσωπική άποψη για το τι
είναι καλό και τι κακό στο UNIX. Και εμείς πρέπει αυτά τα δυο άτομα,
μεμονωμένα, να τα θεωρήσουμε τις απόλυτες πηγές σοφίας και σε ότι
αυτοί οι δυο συμφωνούν να υποκλιθούμε. Όλοι οι άλλοι είναι μούφες και
μόνο ότι συμφωνεί τόσο ο Dan και ο Mark είναι η Μια Αλήθεια(ΤΜ).
Φάουλ 3.
Υπάρχουν πάρα πολλά άτομα που οι γνώσεις τους ξεπερνούν τις γνώσεις
που έχει ο μέσος χρήστης ή προγραμματιστής υπολογιστών. Το ότι δυο
από αυτούς έχουν συμφωνήσει ως τώρα σε κάποια πράγματα δεν λέει
τίποτα. Η πλειοψηφία τι λέει;
> This has become more important to me since I "discovered" qmail and
> then went to Linux Expo and learned about things like the IBM Jikes
> compiler.
Τι κοινό έχει το jikes και το qmail;
> The upshot has been that I've pretty much decided to learn to write
> (useful) software *correctly*, or not at all (maybe do music or
> other stuff instead).
Το ίδιο πράγμα έχει πει κι ο Donald Knuth πριν από χρόνια. Τα
προγράμματα πρέπει να γράφονται με το "σωστό" τρόπο, και να είναι
χρήσιμα. Δεν έχει νόημα να γράφεις λογισμικό που δεν είναι σωστά
γραμμένο. Η μαγική λέξη εδώ είναι το "σωστά", κι όποιος καταφέρει και
την ορίσει παίρνει γλιφιτζούρι. Το να είσαι ασαφής δεν θεωρείται
νίκη. Κι εγώ μπορώ να πω πράγματα όπως:
Τα λειτουργικά συστήματα πρέπει να παρέχουν στους χρήστες τους
τον σωστό τρόπο για να διαχειρίζονται τις συσκευές τους.
Ναι, προφανώς όλοι συμφωνούμε με την γενική ιδέα μιας τόσο ασαφούς
πρότασης. Και;
> That's the thrust behind my recent decision to stop working on g77
> or GCC for that matter -- there are plenty of people (as I
> discovered at Linux Expo) very willing and enthusiastic to step in
> and contribute to the GNU/Linux pool of software, for which
> fundamental
> (vs. distribute/collect-bug-reports/debug/fix/repeat) correctness is
> barely in the top five of goals, much less #1.
Σταμάτησε να βγάζει το g77 γιατί δεν του αρέσει το GNU development
model. Μάλιστα. Δεν κατάλαβα γιατί αυτό κάνει το g77 να είναι "μη
σωστό" πρόγραμμα όμως. Κάνει τη δουλειά του; Αν ναι, είναι χρήσιμο.
Το σωστό ή λάθος ακόμα το ψάχνουμε. Δεν μας είπε κανείς τι είναι
λάθος, δεν μας είπε τι είναι σωστό. Οπότε πάμε παρακάτω.
Μπαρούφα 1.
Τι σχέση έχει το g77 και το μη ευέλικτο development model της FSF με
το Bernstein; Το ότι η FSF δεν έχει κάποιο release/test/debug/fix
κύκλο που να βοηθάει στην ομαλή εξέλιξη των προγραμμάτων της, γιατί
σημαίνει πως ο Bernstein ξέρει τι κάνει; Μπορεί κάλλιστα και οι δυο
να είναι σε (δικό του ο καθένας) "λάθος μονοπάτι".
> So the lack of *willing* developers of open-source software is no
> longer the problem (if it ever was) -- it's the lack of developers
> of *high- quality* open-source software, or, more precisely, the
> acceptability of low-quality solutions, that seems to be the
> problem.
Ίσως. Πως μπορεί κάποιος να δει ότι όντως υπάρχει έλλειψη
προγραμματιστών που ενδιαφέρονται να φτιάξουν "προγράμματα υψηλής
ποιότητας";
> I've had a thorough code-review done of one of my products by two
> more seasoned professionals. It was a great experience, but, after
> all their concerns were addressed, there were still bugs. Sure, not
> "too many" according to management, but too many that I'm sure could
> have been designed out of existence up front if I'd known how.)
Κι αυτό σημαίνει πως οι reviewers ήταν χαζοί; Ή ότι ο σχεδιασμός ήταν
από την αρχή λάθος; Οι reviewers είχαν το ελεύθερο να κάνουν
σχεδιαστικές αλλαγές; Μόνο δυο reviewers σε σχέση με τους χιλιάδες
reviewers που έχει ένα open source λειτουργικό; Μήπως αυτό
αποδεικνύει μόνο την ανάγκη για περισσότερους reviewers και είναι
απόδειξη του γιατί ένα πρόγραμμα δεν πρέπει να είναι closed source?
Φάουλ 4.
Το ότι οι δυο συγκεκριμένοι reviewers δεν "είδαν" τα bugs δεν σημαίνει
πως όσοι και να κοιτούσαν τον κώδικα δεν θα τα έβλεπαν ποτέ.
> I'd like to be able to write something, e.g., an optimizing
> compiler, meeting qmail's performance in this area as compared to
> GCC meeting sendmail's.
Εγώ αντίθετα θέλω κάποιος να μου δείξει τουλάχιστον δύο test που έχουν
γίνει από ανθρώπους που ξέρουν τόσο το qmail όσο και το Sendmail, όπου
φαίνεται καθαρά ότι το qmail είναι performance-wise πιο καλό.
Ύστερα θέλω να μου δείξει κάποιος πόσα και ποια standards σχετικά με
το email ακολουθεί το Sendmail και πόσα το qmail. Και τέλος, πόσα και
ποια RFC είναι πρότυπα πλέον, αλλά δεν ισχύουν για το Sendmail και
πόσα δεν ισχύουν για το qmail.
Έτσι θα έχω δεδομένα να αποφασίσω πως θα στήσω ένα SMTP mailer που θα
είναι και γρήγορος και interoperable με οτιδήποτε ακολουθεί τα πρότυπα
του Internet ;)
> Imagine an open- source compiler with the #1 goal of never
> generating incorrect code, #2 of never crashing, #3 of making the
> code run fast, or similar, with stuff like supporting whatever
> extension Linux programmers want today further down the list than
> those three.)
Μπαρούφα 2.
Κάποιος μεταγλωττιστής που βγάζει "λάθος κώδικα" (για κάποιο ορισμό
του "λάθος") έχει bug και πρέπει να διορθωθεί. Είμαι σίγουρος ότι
αυτόν τον μεταγλωττιστή δεν τον χρησιμοποιεί κανείς λογικός άνθρωπος
για σοβαρή δουλειά.
Το #2 είναι πολύ σωστό. Απαιτώ όλα τα προγράμματα που τρέχω σε
περιβάλλοντα που γίνεται παραγωγική δουλειά να μην κρασάρουν. ΠΟΤΕ!
Το #3 είναι κάτι που οι optimizers προσπαθούν να κάνουν. Δεν είμαι ο
ειδικός στην τεχνολογία των μεταγλωττιστών, που θα πει ποιος είναι ο
καλός ή όχι. Αλλά ήδη γίνονται προσπάθειες προς αυτή την κατεύθυνση.
Δεν βλέπω κάτι καινούριο εδώ.
> Though I've sometimes disagreed with, or doubted, claims by various
> "enthusiasts" like Mark and Dan over the years, I've usually kept
> their claims, or at least the salient points as I've seen them, in
> mind while observing how I've done my software (also tech-writing)
> work to see if they had a point after all. Often enough, I've gained
> new insight on an old claim while working on a program, especially
> when fixing a bug (maybe the Nth bug of its "class", a class
> distinction some enthusiast's "old" point helped me to make), and
> realized that they *did* have a valid point. (My perspective on good
> language design, for example, has changed vastly. What people say
> makes C++ and Perl such good languages today is exactly the sort of
> stuff I said was important back in the late '70s. Now I know how
> wrong it is, when it comes to writing correct software.)
Γενικολογίες. Ακριβώς με το ίδιο στυλ που απαντάει ο Dan Bernstein,
όταν λέει "ξέρω αν το τάδε ισχύει, απλά περιμένω την απάντησή σου"
(βλ. παρακάτω post):
From: Dan Bernstein (dan.bernstein at usa.net)
Subject: Re: Built-In Defrag Tools?
Newsgroups: comp.sys.mac.system
Date: 2001-03-20 01:42:39 PST
in article B6DC4BD396683BAF1 at 10.0.1.2, Simon Slavin at
slavins at hearsay.demon.co.uk@localhost wrote on 20/3/01 1:50 AM:
> X doesn't need any defragging. The disc format used by Unix
> doesn't lead to degradation when files are fragmented.
OS X can use (in fact, by default or by Apple recommendation, it uses) HFS+,
in which case the question remians (which I'm not going to answer) whether
HFS+ needs defragging or not.
> The upshot is, I have a lot more to learn than I ever believed I did
> back when I took my first full-time job programming in 1978, and I
> see in products like qmail and people like Dan some indication of
> the sort of stuff I have to learn, understand, and be able to either
> put into practice or recognize people who can (in case I want to
> hire them).
Βασικά "θέλω να γράψω κάτι σαν το qmail".
> Especially if I undertake some long-cherished plans to research and
> design (from scratch if necessary) a new OS that could actually be
> useful for more than just 10 years and more than just a few million
> people, I had better understand some of the fundamental aspects of
> OS design that contribute to, or perhaps hinder, the development
> and deployment of quality applications.
Τώρα άλλαξε το σενάριο.
"Θέλω να γράψω ένα δικό μου λειτουργικό σύστημα."
Ω θεοί. Τι να πω. Μόνο "καλή επιτυχία" μπορώ να ευχηθώ.
> Some salient summaries of the issues Dan and others, like Mark, have
> wrestled with, like reliability,
Ναι, σωστό αυτό. Το software engineering έχει τις δικές του αξίες.
Μια από αυτές είναι η "αξιοπιστία". ΟΚ, καλά ως εδώ.
> scalability,
Καλός στόχος επίσης.
> portability,
Είναι ενδιαφέρον να κάτσει κάποιος να αναρωτηθεί πως ακριβώς θα
πετύχει κανείς να είναι portable το πρόγραμμά του, χωρίς να
ακολουθήσει καμία από τις γνωστές συμβάσεις των προγραμματιστών. Δεν
ξέρω ο Mark αλλά ο Bernstein είναι περίφημος για την αηδία που δείχνει
να νιώθει όταν βλέπει κάτι "πρότυπο". Φαίνεται κι από τα προγράμματά
του που δεν ακολουθούν σχεδόν κανένα πρότυπο, αν μπορεί αυτό με κάποιο
τρόπο να παραβιαστεί.
Είμαι περίεργος πως κάποιος μπορεί να είναι portable και εντελώς μη
συμβατικός. Η μόνη λύση που μπορώ να σκεφτώ είναι να χρησιμοποιήσει
τα ελάχιστα κοινά χαρακτηριστικά των UNIX συστημάτων, και να μην
βασιστεί σε μη-μεταφέρσιμα χαρακτηριστικά. Αλλά ακριβώς αυτό τον
σκοπό εξυπηρετούν πρότυπα όπως της ANSI C, του POSIX και του ISO.
Με μια μεγάλη προϊστορία καταπάτησης και αφού έχει επιδεικτικά
αγνοήσει όλα τα πρότυπα που είναι δυνατόν να αγνοήσει κάποιος και να
εξακολουθήσει να κάνει compile τα προγράμματά του, ο Bernstein δεν
είναι ακριβώς portable.
> security,
Αρκετά γενική έννοια. Καλή ιδέα. Καμία αντίρρηση.
> and so on, could be valuable resources to someone like myself, who'd
> like to at least "take a breather" (in the midst of what seems like
> pell-mell writing of marginally acceptable code worldwide) and
> figure out how it *should* be done before we resume adding to the
> problem(s). (Yes, I'm likely to collect pointers to such documents
> on my own web page, if I don't find such a resource on someone
> else's first, or until I do find such a site.)
Μετάφραση:
"Κάνω διάλλειμα από τον προγραμματισμό και πάω να διαβάσω."
Σεβαστή απόφαση. Όλοι έχουμε ανάγκη από διάβασμα που και που.
> P.S. Just so it's clear, I'm focusing on writing correct
> *open-source* software. That's at least plausibly a very different
> task than writing some sorts of closed-source, especially one-shot,
> software.
> It requires writing software that is difficult for newcomers to the
> *source code* to misunderstand sufficiently that they think they
> know what they're doing when they change it, and in doing so
> inadvertently break it.
Καλός στόχος.
> But I want to stress that I'm not talking about building
> conceptually wonderful, crystalline monoliths that shatter the first
> time someone else comes along and modifies them. In fact, I'm
> talking about building software in such a way that the "crystalline"
> portions of it are nearly as small as possible, though exactly what
> that means, I still don't entirely know.
Modularity. Ξέχασες το modularity. Δεν είναι απαραίτητο ένα
πρόγραμμα να είναι σπασμένο σε εκατό daemons και τριάντα services για
να είναι εύκολο στην κατανόηση. Μπορεί άνετα να είναι καλογραμμένο,
σε μικρά, εύκολα στην κατανόηση κομμάτια, και να είναι μονολιθικό.
Κλασσικό παράδειγμα. Η βιβλιοθήκη C των UNIX. Στο FreeBSD είναι
σπασμένη σε 26 διαφορετικούς βασικούς καταλόγους, σε 60
υποκαταλόγους, μια library function σε κάθε αρχείο (γενικά, υπάρχουν
κι εξαιρέσεις), σε ένα σύνολο από 1368 αρχεία κάτω από τον βασικό
κατάλογο της libc, τον /usr/src/lib/libc.
Για να προσθέσει κανείς ένα καινούριο library function αρκεί να
φτιάξει στον κατάλληλο υποκατάλογο του src/libc/ τα εξής πράγματα:
* Ένα αρχείο με την υλοποίηση της function.
* Μια γραμμή στο Makefile.
* Προαιρετικά ένα manpage.
Για να αλλάξει κάποιος ένα κομμάτι του qmail πρέπει να αλλάξει πολύ
περισσότερα πράγματα. Ας δοκιμάσει όποιος δεν με πιστεύει να αλλάξει
το default πρόγραμμα που χρησιμοποιεί το qmail για logging
(splogger.c), με ένα πρόγραμμα που θα στέλνει στο syslog αντί για όλα
τα lines που διαβάζει από stdin, μόνο κάποιες γραμμές από όλες αυτές
που στέλνει το qmail.
Το έχω κάνει, και έχω τον κώδικα για όποιον τον ζητήσει, από πρόγραμμα
που δουλεύει όπως το splogger ακριβώς αλλά κάνει log μόνο τις γραμμές
που κάνουν match με κάποιο regular expression. Η λίστα με τα regexps
φορτώνεται από το αρχείο /var/qmail/control/logregexp και το
πειραγμένο splogger ξαναφορτώνει τη λίστα όταν του στείλει κάποιος
το SIGHUP signal. Επειδή το qmail όμως είναι ΠΟΛΥ καλογραμμένο, για
να το κάνω αυτό έφαγα ένα απόγευμα ολόκληρο.
Καμία σχέση με το πόσο πιο εύκολο είναι στην "μολολιθική" libc να
προσθέσει κανείς ένα καινούριο χαρακτηριστικό!
Το συμπέρασμα δείχνει να είναι ότι δεν έχει σημασία το μονολιθικό ή
βασισμένο-σε-components design, αρκεί να είναι ο κώδικας γραμμένος με
τέτοιο τρόπο που να είναι ΔΥΣΚΟΛΟ να ΜΗΝ τον καταλάβεις.
for (;;) {
if (substdio_get(subfdin,&ch,1) < 1) _exit(0);
if (ch == '\n') { flush(); flagcont = 0; continue; }
if (bufpos == sizeof(buf) - 1) flush();
if ((ch < 32) || (ch > 126)) ch = '?'; /* logger truncates at 0; GPACIC */
buf[bufpos++] = ch;
}
Αυτό εγώ δεν το θεωρώ κώδικα που είναι ευανάγνωστος, εύκολος να τον
καταλάβει κάποιος, καθαρογραμμένος, σαφής... Ίσως κάτι σαν το
παρακάτω να ήταν λίγο καλύτερο:
/*
* We never get out of the main logger loop,
* unless a SIGPIPE signal kills us (since we expect our input
* to come from STDIN), or we receive EOF in stdin.
*/
for (;;) {
if (substdio_get(subfdin, &ch, 1) < 1)
_exit(0); /* EOF on stdin */
if (ch == '\n') {
flush();
flagcont = 0;
continue;
}
if (bufpos == sizeof(buf) - 1)
flush();
if ((ch < 32) || (ch > 126))
ch = '?'; /* logger truncates at 0; GPACIC */
buf[bufpos++] = ch;
}
Ναι, θα μου πείτε "Ω μα, κι εσύ, κολλάς τώρα σε κάτι λεπτομέρειες. Το
στυλ του κώδικα σε πείραξε τώρα..." Φυσικά και ναι. Όταν εγώ θέλω
μισή ώρα να καταλάβω τι στο διάολο κάνει μια γραμμή που έχει ούτε ένα,
ούτε δυο, αλλα ΤΡΙΑ παρακαλώ statements στη σειρά
if (ch == '\n') { flush(); flagcont = 0; continue; }
ναι φυσικά και με πειράζει το στυλ. Δεν ανέχομαι να μου λέει κάποιος
ότι είναι καλός προγραμματιστής όποιος γράφει κώδικα με read-only
στυλ, λες και δεν θα τον ξαναδιαβάσει κανείς, ποτέ.
> As a trivial example, which only approximates a real-world one, I'll
> "pick on" qmail. Assuming it was open-source (guess it isn't, but
> nevermind).
Μετάφραση:
Αν το qmail ήταν open source, που δεν είναι, αλλά σκοτιστήκαμε,
τότε... ω ξέχασα, δεν είπα τίποτα για το open source ή όχι. Όπως
και να χει, δεν έχει σημασία. Πάμε παρακάτω...
Κάποιος έχει πετάξει ένα κάρο άσχετα, μαζί με ένα κάρο αηδίες, ένα
φορτηγό ολόκληρο από λογικά λάθη, και κάμποσα σκουπίδια και γνώμες
τρίτων στο ίδιο μπλέντερ και ότι βγήκε το έστειλε σε email.
> I see discussions of the bounce message -- "can I change it?" In my
> view, the code that *produces* the bounce message should be distinct
> from a *description* of an acceptable bounce message. Part of
> building qmail should include checking the bounce message that'll be
> produced against that description, and rejecting (just as if there
> was a compile-time error) the code if there's a mismatch. Maybe
> that's even how it's designed, I don't know, and, in isolation, it's
> probably not tremendously important. (Commentary in the code is a
> simple, if not 100% reliable, way to address such problems. It's
> reliability can still exceed that of mechanical solutions such as
> I've proposed, especially if the code-development infrastructure
> doesn't directly support and endorse their use.)
Μετάφραση:
Μια καλή ιδέα θα ήταν να ... Το qmail μάλλον το κάνει έτσι, γιατί
είναι καλογραμμένο πρόγραμμα. Δεν ξέρω όμως, δεν έχω διαβάσει τον
κώδικα. Και μάλλον δεν έχει σημασία. Το να δείχνεις κώδικα είναι
ένας απλός και αξιόπιστος τρόπος να υποστηρίζεις τέτοια πράγματα.
Απλά εγώ δεν θα το κάνω.
Αηδίες. Δείξε μας τον κώδικα αγόρι. Αν δεν τον έχεις διαβάσει καν,
βούλωσέ το και πάμε για ψάρεμα όλοι μαζί. Καλύτερα ψάρια θα πιάσουμε.
> But I've noticed that when I take such issues more seriously in
> designing software, then, when other people work on it, the results
> of their failure to completely grasp what I was doing and, say,
> forget to change all three source files to reflect something new
> they're adding, is more and more likely to be up-front, rather than
> way-down-stream, failure.
Μετάφραση:
Έχω γράψει κώδικα που απαιτεί να γίνουν αλλαγές σε πενήντα σημεία
για να κάνεις μια προσθήκη. Είναι καλοσχεδιασμένος όμως, και
φταίνε φυσικά οι άλλοι που δεν μπορούν να κατανοήσουν το μεγαλείο
και την ανωτερότητα του design μου.
Αηδίες. Πάντα φταίνε οι άλλοι. Ποτέ ο κακός αρχικός σχεδιασμός.
Ναι καλά... μας τα είπαν κι άλλοι. Neeeeext.
> (BTW, "other people" include myself, an hour, a day, a week, even
> years, later. I no longer take any enjoyment writing software with
> any unique architectural concepts that I have to memorize to
> continue working on it.)
Μετάφραση:
Πολλές φορές όταν ξαναδιαβάζω τον κώδικά μου μετά από καιρό δεν
καταλαβαίνω το Χριστό μου.
> And that saves not only lots of time for
> developers, it can save end users the trouble of tracking down
> apparent bugs on their end only to find they're "upstream" bugs.
Γενικά είναι καλό να μπορεί να καταλάβει κάποιος τον κώδικα εύκολα.
Ακόμα και οι χρήστες που δεν είναι hot-shot προγραμματιστές, μπορούν
τότε να διαβάσουν τον κώδικα και να βοηθήσουν στο debugging.
Φάουλ.
Και τότε γιατί παραπάνω ακριβώς είπε ότι ο ίδιος έχει πολλές φορές
πρόβλημα να διαβάσει τον κώδικά του μετά από καιρό; Γιατί δεν ξέρει
να γράψει ευανάγνωστο, εύκολο στην κατανόηση κώδικα; Παρόλ' αυτά
ξέρει πως μόνο ο Bernstein και ο άλλος τύπος ξέρουν να γράφουν καλό
κώδικα. Και όλοι οι άλλοι είναι άχρηστοι.
Αηδίες πάλι.
> What I have in mind, though, is much more comprehensive than such
> cross-checking. That's just an illustration of what I mean by
> "crystalline" -- you change one thing and not another, and the
> system (as a whole, through deployment) breaks or even shatters. If
> the system doesn't even let you *deploy* the (errant) change in the
> first place, and especially if it appropriately leads you to better
> understand what you're doing, the system as a whole should, at least
> in theory, end up being more robust.
Ναι, ναι, ΟΚ. Πώς; Α και, καλό θα ήταν να είναι ξεχωριστή η
"πολιτική" που θα επιβάλλει ένα εργαλείο ανάπτυξης λογισμικού από το
"πως εφαρμόζεται" αυτή η πολιτική και από το πως "υλοποιείται" στο
εργαλείο. Για παράδειγμα, μπορεί εγώ να θεωρώ πως είναι κακή ιδέα το
configuration ενός προγράμματος να είναι σκόρπιο σε πενήντα
διαφορετικά αρχεία, και να θέλω να μην με αφήνει το περιβάλλον
προγραμματισμού να ανοίξω παραπάνω από ένα configuration αρχείο.
Κάποιος άλλος μπορεί να θέλει να επιβάλλει το σπάσιμο των
configuration αρχείων σε πολλά, μικρά, ανεξάρτητα κομμάτια.
Θα πρέπει η πολιτική που εφαρμόζει ο καθένας από τους δυο μας να του
δίνει της εξής δυνατότητες:
* Compile & link time ελέγχους.
* Run time ελέγχους.
* Boot time ελέγχους (αν είναι service).
* Shutdown time ελέγχους (πάλι για service μόνο).
Δεν βλέπω κανέναν να έχει καμιά ιδέα προς τα εκεί όμως. Αντίθετα,
βλέπω τον κόσμο να παραπονιέται πως οι προγραμματιστές είναι δύσκολο
να επεκτείνουν ένα πρόγραμμα όταν αυτό είναι σκόρπιο σε πεντακόσια
μέρη, και την ίδια στιγμή να εκθειάζουν το qmail γιατί "είναι εύκολο
στην ρύθμιση του" επειδή έχει το configuration σε πενήντα αρχεία!
Παραλογισμοί!
- Giorgos
More information about the Linux-greek-users
mailing list