Αυτό το commit περιλαμβάνεται σε:
infl00p 2022-03-23 20:14:33 +02:00
commit 8ec8e9bee2
451 αρχεία άλλαξαν με 46736 προσθήκες και 0 διαγραφές

45
content/articles/19/01_editorial.md Κανονικό αρχείο

@ -0,0 +1,45 @@
+++
title = 'Editorial'
date = '1999-11-01T00:00:00Z'
description = ''
author = 'Μιχάλης Καμπριάνης(mailto:kabrianis@hellug.gr)'
issue = ['Magaz 19']
issue_weight = 1
+++
----------------------------------------------------------------------------------------------------------------------------------------------------------------
*Καλώς ορίσατε στο **Magaz** Νοεμβρίου \...*
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Το προτελευταίο αυτό τεύχος του έτους, μαζεύουμε εντυπώσεις από την αλλαγή που κάναμε. Η εξαγωγή και ανάλυση συμπερασμάτων ποτέ δεν ήταν εύκολη δουλειά, (και
σίγουρα όχι τεχνική) αλλά φαντάζομαι οι περισσότεροι το ξέρετε αυτό, άρα δεν θα σας κάνει εντύπωση αν ερμηνεύουμε διαφορετικά τα ίδια στοιχεία.
Περίπου 170 άτομα μέσα στον Οκτώβριο χρησιμοποίησαν το search. Καλό νούμερο (αν και δεν ξέρουμε πόσα από αυτά είναι δικές μας δοκιμές και πόσα είναι δικές σας
αναζητήσεις). Επίσης, γύρω στα 100 άτομα είδαν την δημοσκόπηση, αλλά ψηφίσανε μόνο 25. Λιγότερα από 60 άτομα κατέβασαν το τεύχος για να το διαβάσουν offline,
ενώ γύρω στα 70 ζητήσαν το προηγούμενο τεύχος (17). Τέλος, όπως αναμενόταν, τα πιο περιζήτητα άρθρα ήταν αυτά του τεύχους 18 (πιο πρόσφατο) με πολλά όμως hits
σε άρθρα των τευχών 17, 16 και 15. Αυτό εμείς το θεωρούμε καλό, γιατί σημαίνει ότι ο κόσμος ανατρέχει σε παλαιότερα άρθρα μας.
Σε αυτό το τεύχος έχουμε [εντυπώσεις από την Infosystem 99](02_infosystem.html), μία [ανάλυση του CVS](03_cvs.html), μία [επεξήγηση του boot
process](04_boot.html) και μία [ανάλυση για τα benchmarks](05_benchmarks.html) που βλέπουν τελευταία το φως της δημοσιότητας.
Μετά την αλλαγή, επικοινώνησαν και άλλοι μαζί μας ρωτώντας τι άρθρα να συνεισφέρουν, συνεπώς θα ξανααναφέρουμε τις προτάσεις μας (αν παρατηρήσετε ότι είναι πολύ
λιγότερες από την τελευταία φορά, αυτό είναι επειδή κάποια άρθρα έχουν ήδη γραφτεί, και κάποια άλλα είναι αυτή τη στιγμή σε εξέλιξη).
- Κατηγορία Howto
- Callback στο Linux
- Προγραμματισμός σε QT, GNOME
- Infrared communication
- SGML και LINUXDOC tutorial
- Κατηγορία αναλύσεις
- Linux και POSIX
- Το Linux σαν router
- Κατηγορία παρουσιάσεις
- Παρουσίαση του Koffice
- Παρουσίαση του Mozilla
- Παρουσιάσεις νέων Distributions
- Κατηγορία updates παλαιότερων άρθρων
- Update για Samba v2 και kernel 2.2
- Update για IP Masq σε kernel 2.2 και ipchains
Σας ευχόμαστε καλή ανάγνωση\....

104
content/articles/19/02_infosystem.md Κανονικό αρχείο

@ -0,0 +1,104 @@
+++
title = 'Με το HELLUG στην Infosystem 99'
date = '1999-10-01T00:00:00Z'
description = ''
author = 'Παναγιώτης Βρυώνης'
issue = ['Magaz 19']
issue_weight = 2
+++
----------------------------------------------------------------------------------------------------------------------------------------------------------------
*Η φετινή Infosystem είχε μία ασυνήθιστη παρουσία. Τι θέλουν οι τύποι με τους πιγκουίνους στο κεφάλι σε μία έκθεση πληροφορικής; Ένα από τα μέλη του hellug
περιγράφει την εμπειρία.*
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Η Infosystem που γίνεται στην Θεσσαλονίκη κάθε χρόνο είναι μία από τις σημαντικότερες εκθέσεις πληροφορικής στην Ελλάδα. Εκθέτες από όλη την χώρα παρουσιάζουν
τα προϊόντα και τα επιτεύγματά τους. Η Infosystem99 ήταν η πρώτη έκθεση πληροφορικής στην Ελλάδα στην οποία παρουσιάστηκε επίσημα το Linux ως προϊόν και ώς
εναλλακτική λύση. Κατά κύριο λόγο (αλλά όχι και μοναδικό όπως θα δούμε παρακάτω) αυτό οφείλονταν στην παρουσία του Hellug (Hellenic Linux Users Group) σε αυτή.
Η παρουσία του HELLUG στην φετινή Infosystem σίγουρα τράβηξε το μάτι χιλιάδων ανθρώπων που πέρασαν από την έκθεση. Όσοι στάθηκαν στο περίπτερό μας, σίγουρα
κατάλαβαν ότι κάτι διαφορετικό γίνόταν σε αυτό τον χώρο. Στην πραγματικότητα, τα πάντα ήταν διαφορετικά σε σχέση με τους υπόλοιπους εκθέτες!
Για να μπορέσει να έχει αυτή την αξιοπρόσεκτη παρουσία, το HELLUG χρειάστηκε να ξεπεράσει πολλά εμπόδια και σε επίπεδο συλλόγου αλλά και σε επίπεδο προσωπικό
για τα μέλη του. Τα προβλήματα ήταν κυρίως οικονομικά: τα μέλη χρειάστηκε να δώσουν μία έκτακτη εισφορά για να συγκεντρωθούν τα χρήματα που απαιτούνταν για την
ενοικίαση του περιπτέρου στον χώρο της έκθεσης, αλλά και να πληρώσουν το καθένα από την τσέπη του τα έξοδα μετάβασης και διαμονής στην Θεσσαλονίκη. Χάρη στο
μεράκι και την όρεξη του διακρίνει τους λινουξάδες, τα προβλήματα αυτά ξεπεράστηκαν και τελικά γύρω στα 15 μέλη του συλλόγου κατάφεραν να βρίσκονται όλες ή
μερικές μέρες στον χώρο του περιπτέρου και να βοηθούν.
Σημαντική ήταν και η αρωγή που είχε ο σύλλογος από αρκετές εταιρείες. Η διαφημιστική Modus Vivendi προσφέρθηκε να μας σχεδιάσει και να εκτυπώσει τις τεράστιες
αφίσες που κάλυψαν τους τοίχους καθώς και τα 13.000 ενημερωτικά φυλλάδια που είχαμε για διάθεση στους επισκέπτες του περιπτέρου. Τα Μακεδονικά Περιφερειακά
δάνεισαν για όλες τις ημέρες της έκθεσης 2 μηχανήματα στα οποία τρέχαμε linux. Οι εταιρείες Caldera, RedHat και Mandrake έστειλαν CDs και μπλουζάκια. Τέλος,
πρέπει να πούμε ότι σημαντική ήταν και η βοήθεια που είχαμε από τους δύο έλληνες αντιπροσώπους της SuSE, τις εταιρείες ΥΕΠ (www.suse.gr) και Step (www.step.gr)
που μας έδωσαν αμέτρητα CDs\...
Πέρα από τις εταιρείες που βοήθησαν όμως, το κύριο βάρος το σήκωσαν τα μέλη του συλλόγου. Μερικοί έφεραν τα laptop τους, άλλος μία κάρτα για video grabbing μαζί
με μία μικρή καμερούλα, άλλος ολόκληρο PC!!!
Ξέρω ότι πολλοί επαγγελματίες που διαβάζουν τα παραπάνω θα χαμογελάνε ήδη. Ας μην βαστείτε όμως να κρίνετε. Είναι γεγονός ότι η οργάνωση του HELLUG δείχνει έναν
ερασιτεχνισμό (και γιατί όχι στο κάτω, κάτω, αφού είναι το χόμπι μας\...). Το αποτέλεσμα όμως ήταν εντυπωσιακό: ένα πολύ όμορφο περίπτερο, με τη φρεσκάδα και
την ζωντάνια που χαρακτηρίζει κάθετί που γίνεται εθελοντικά, γεμάτο επισκέπτες ακόμη και σε ώρες που τα άλλα, οργανωμένα περίπτερα ήταν άδεια!
Οι επισκέπτες που πέρασαν από το περίπτερο 15 stand 12 (αυτός ήταν ο χώρος μας) παρατήρησαν ότι οι υπολογιστές που βρίσκονταν εκεί δεν ήταν απλώς διακοσμητικοί.
Σχεδόν πάντα, κάποιος έκανε κάτι σε αυτούς. Την μία γινόταν recompile του πηρήνα για να αναγνωρίσει τον video grabber, την άλλη στηνόταν το firewall, την τρίτη
κάποιος προσπαθούσε να αναπαράγει το πρόβλημα που είχε ένας λινουξάς επισκέπτης στο γραφείο του για να δωθεί η σωστή λύση. Πολλοί που δεν είχαν παλαιότερη
εμπειρία με το linux θέλησαν να δουν πως συμπεριφέρεται στην πράξη και υπήρχαν και μερικοί που βρήκαν την ευκαιρία να μας δείξουν πως χρησιμοποιούν το linux
στην δουλειά τους. Από το Σάββατο, οι φωτογραφίες που είχε τραβήξει κάποιος με μία ψηφιακή κάμερα είχαν μεταφερθεί στα μηχανήματα που είχαμε στην έκθεση και
στην συνέχεια μπήκαν στον server του συλλόγου, στην διεύθυνση <http://www.hellug.gr/infosystem> (προσθέθηκαν και άλλες αργότερα). Υπήρχε και η σκέψη να στηθεί
ένας Real Server για να μεταδίδουμε στο internet την εικόνα από την κάμερα που βρισκόταν συνδεδεμένη σε ένα από τα μηχανήματά μας, αλλά την τελευταία στιγμή
εγκαταλήφθηκε (αν και ο server είχε ήδη στηθεί) γιατί μάλλον θα καταναλώναμε όλο το bandwidth της έκθεσης.
Ένα άλλο ενδιαφέρον χαρακτηριστικό ήταν ότι στο περίπτερο του HELLUG ο κόσμος σταματούσε για να συζητήσει. Έγιναν ατελείωτες συζητήσεις, άλλες με καθαρά τεχνικό
ενδιαφέρον (σχετικά με web servers, δίκτυα κ.λ.) και άλλες με θεωρητικό (ποιό είναι το μέλλον του linux, που πάει η αγορά πληροφορικής και ό,τι άλλο μπορέιτε να
φανταστείτε). Νομίζω ότι αυτό ήταν και ένα από τα πιο σημαντικά στοιχεία του περιπτέρου μας. Ότι δηλαδή οι άνθρωποι που βρισκόντουσαν μαζεμένοι σε αυτό ήταν
άνθρωποι με τεχνογνωσία, πρόθυμοι να την μοιραστούν με τους υπόλοιπους. Δεν υπήρχε το άγχος της \"σωστής\" παρουσίας ή της πώλησης, αλλά η όρεξη για κουβέντα
και ανταλλαγή απόψεων. Σιγά σιγά χάθηκε και ο διαχωρισμός μεταξύ \"εκθετών\" και \"επισκεπτών\": λινουξάδες που δεν ήταν μέλη του hellug παρασυρμένοι από το
γενικό κλίμα, έδιναν συμβουλές και βοήθεια σε επισκέπτες!
Η εμπειρία από το προηγούμενο happening που είχε οργανώσει ο σύλλογος έλεγε ότι ενώ είχαμε ένα πολύ σημαντικό αριθμό CDs με linux για να μοιράσουμε στον κόσμο,
αν δεν τα δίναμε με μέτρο γρήγορα θα εξαντλούνταν. Έτσι, δεν διαφημίσαμε ότι θα δίναμε τζάμπα CDs και προσπαθούσαμε να δώσουμε μόνο στους επισκέπτες που
έδειχναν πραγματικό ενδιαφέρον και να μην τα σκορπίζουμε ανεξέλενκτα. Αυτό μπορεί να κακοφάνηκε σε μερικούς, ο μόνος λόγος όμως ήταν ότι δεν θέλαμε να
καταλήξουν τα περιορισμένα κομάτια που είχαμε (και που σε μερικές περιπτώσεις είχαν γραφτεί με προσωπικά έξοδα μελών) στα σκουπίδια, μαζί με τα διαφημιστικά
φυλλάδια που μάζευαν οι επισκέπτες από κάθε περίπτερο. Τελικά, όση φειδώ και αν δείξαμε, την Κυριακή το βράδυ (τελευταία μέρα της έκθεσης) δεν είχαμε άλλα CDs
να δώσουμε. Οι υπολογισμοί δείχνουν ότι μοιράστηκαν με αυτό τον τρόπο γύρω στα 800 CDs (πλήρως λειτουργικά).
Από τα πράγματα που τράβηξαν περισσότερο το ενδιαφέρον των επισκεπτών μας ήταν σίγουρα το bb, το VMWare και τα γραφικά του enlightenment. Το bb είναι ένα demo
που δείχνει τις δυνατότητες της βιβλιοθήκης aalib (ASCII Art Libraty) που επιτρέπει να σχεδιάζουμε γραφικά σε text mode χρησιμοποιώντας μόνο χαρακτήρες (ούτε
κάν γραφικούς χαρακτήρες όπως έκαναν κάποτε οι προγραμματιστές στα παιχνίδια για DOS). Η aalib δεν θα μπορούσε να αντικαταστήσει βέβαια την υπέροχη κάρτα
γραφικών σας με μία οθόνη κειμένου 80x24, αλλά είναι σίγουρα εντυπωσιακό να βλέπει κανείς φράκταλς, φωτογραφίες, dithering, antialising και error diffusion να
γίνονται μόνο με γράμματα και αριθμούς διαφορετικής φωτινότητας. Το bb ήταν από τα πράγματα που έκαναν πολλούς να αναλογιστούν τί μπορέι να κάνει ένας
ταλαντούχος προγραμματιστής όταν έχει όρεξη, ανεξάρτητα από τις δυνατότητες του hardware. Από την άλλη, το VMWare τραβούσε εύκολα τα βλέματα, αφού δεν είναι και
τόσο συνηθισμένο να βλέπει κανείς ένα μέσης κατηγορίας μηχάνημα να τρέχει το KDE, σε ένα παράθυρο να τρέχει Windows NT και σε ένα άλλο να κάνει εγκατάσταση
Windows 98!!!
Κάτι που μας ενθουσίασε ως σύλλογο ήταν ότι μερικοί από τους επισκέπτες του περιπτέρου ήρθαν να μας δουν για να λύσουν ειδικά προβλήματα για τα οποία η αγορά
δεν μπορούσε να τους δώσει λύση. Χαρακτηριστικά, ένας από τους επισκέπτες μας είπε ότι ένας φίλος του τον συμβούλευσε \"αν δεν βρεις άκρη \[με το πρόβλημά σου\]
πήγαινε στους λινουξάδες, αυτοί κάτι θα κάνουν\"!!! Αυτό δείχνει κατά την γνώμη μου, ότι σιγά σιγά ο κόσμος αντιλαμβάνεται τις δυνατότητες του ελεύθερου
λογισμικού και ότι αυτό εδραιώνεται ως μια σημαντική εναλλακτική λύση στην συνείδηση των ανθρώπων της πληροφορικής. (Πληροφοριακά, το συγκεκριμένο πρόβλημα είχε
να κάνει με την υποστήριξη πολυτονικών γραμματοσειρών και πληκτρολογίου και η λύση δεν είναι μακριά.)
Η παρουσία μας στην έκθεση δεν είχε σαν στόχο μόνο την επικοινωνία με το \"ευρύ κοινό\", αλλά και με τους υπόλοιπους εκθέτες. Καταρχήν, έγινε φανερό στους
ανθρώπους που στελέχωναν τα γύρω περίπτερα ότι υπάρχει ένα μεγάλο ενδιαφέρον από το κοινό για το linux. Απόδειξη για αυτό ήταν τα (καλοπροαίρετα) σχόλια της
μορφής \"πώς πάτε, χωράτε στο περίπτερο ή θα εκραγεί;\" για τον κόσμο που συνωστιζόταν γύρω από τα μηχανήματα με linux. Ενδεικτικό είναι και το γεγονός ότι οι
δύο τηλεοπτικές εκπομπές με αντικείμενο την πληροφορική που είχαν περίπτερα στην Infosystem99, το PCTV της ΕΤ3 και το five on-line του Alter 5 φιλοξένησαν
συνεντεύξεις μελών του HELLUG και παρουσίασαν το περίπτερό μας.
Αρκετές μικρές και μεγάλες εταιρείες (μερικές είναι και στο χρηματιστήριο) μας πλησίασαν και μας είπαν ότι ενδιαφέρονται να πουλήσουν μηχανήματα με linux, και
ρώτησαν ή ζήτησαν βοήθεια για τον τρόπο που θα μπορούσαν να παρέχουν υποστήριξη στους λινουξάδες πελάτες τους. Το ενδιαφέρον ήταν γνωστό (ή έστω πολλοί από εμάς
το αναμέναμε να εκδηλωθεί αργά ή γρήγορα), αλλά η ζήτηση σε επαγγελματικό επιπεδο για ανθρώπους που να γνωρίζουν καλά το linux ήταν μία ευχάριστη έκπληξη.
Υπήρξαν ακόμη και εταιρείες που αναπτύσουν λογισμικό που ενδιαφέρθηκαν για το linux ως πλατφόρμα και συζήτησαν εκτενώς μαζί μας. Ενδιαφέρον ήταν ακόμη, ότι ένα
πρόχειρο \"σκανάρισμα\" στο δίκτυο της έκθεσης αποκάλυψε ότι εκτός από τα μηχανήματα με linux στο περίπτερο του HELLUG και στα Μακεδονικά Περιφερειακά υπήρχε
και ένα στο περίπτερο της Canon!!! (Και μιας και μιλάμε για σκανάρισμα, είναι απίστευτο το πόσο απροστάτευτα από άποψη δικτυακής ασφάλειας ήταν τα μηχανήματα
στα περισσότερα περίπτερα\...)
Βέβαια, δεν επισκέφθηκαν μόνο οι άλλοι το περίπτερο του HELLUG, αλλά και οι λινουξάδες τα γειτονικά περίπτερα. Γενικά, τα μέλη του HELLUG που γύριζαν ήταν
μάλλον ενας μικρός μπελάς για τους υπόλοιπους εκθέτες, αφού οι ερωτήσεις τους ήταν κατά κανόνα \"δύσκολες\"\... Ε, και όπου υπήρχε πρόκληση, οι ενθουσιώδεις
λινουξάδες δεν την άφηναν. Όπως για παράδειγμα ένα PC (με Windows στην αρχή) που είχε την προκλητική ταμπέλα \"ΣΒΗΣΕ ΜΟΥ ΤΟΝ ΔΙΣΚΟ - ΔΕΝ ΠΑΘΑΙΝΩ ΤΙΠΟΤΑ\" που
μετά από μερικές ώρες είχε φορμαριστεί και στην θέση των Windows κάποιοι είχαν εγκαταστήσει Debian Linux! (Την επόμενη μέρα ο εκθέτης είχε εγκαταστήσει πάλι
Windows, αλλά η ταμπέλα είχε εξαφανιστεί\...). Όλα αυτά όμως έγιναν με καλή διάθεση και νομίζω ότι το αποτέλεσμα είναι να ανεβαίνει ο \"πήχης\" όσον αφορά στο
επίπεδο των παρεχόμενων υπηρεσιών και πληροφοριών προς το κοινό.
Οι εντυπώσεις που αποκόμησαν τα μέλη του συλλόγου από την παρουσία τους στην Infosystem99 νομίζω ότι είναι στο σύνολό τους θετικές: βρεθήκαμε για μία ακόμη φορά
όλοι (έστω αρκετοί) μαζί, γνωρίσαμε ανθρώπους που ασχολούνται με το linux αλλά μέχρι τώρα δεν είχαν επικοινωνήσει μαζί μας και προσφέραμε σε πάρα πολλούς άλλους
την ευκαιρία να γνωρίσουν το linux και την φιλοσοφία του. Είχαμε ακόμη την ευκαιρία να δείξουμε στις εταιρείες πληροφορικής ότι το linux είναι ένας χώρος που
έχει ενδιαφέρον από άποψη αγοράς αλλά και ως πλατφορμα ανάπτυξης λογισμικού. Και τέλος, περάσαμε καλά στην πανέμορφη Θεσσαλονίκη!

331
content/articles/19/03_cvs.md Κανονικό αρχείο

@ -0,0 +1,331 @@
+++
title = 'CVS: Concurrent Versions System (\...)'
date = '1999-10-01T00:00:00Z'
description = ''
author = 'Παπαδογιαννάκης Βαγγέλης για το Magaz ( magaz.hellug.gr(http://magaz.hellug.gr) )'
issue = ['Magaz 19']
issue_weight = 3
+++
----------------------------------------------------------------------------------------------------------------------------------------------------------------
*Το CVS (Concurrent Versions System) είναι ένα σύστημα που έχει αναπτυχθεί από προγραμματιστές για προγραμματιστές. Δηλαδή, θα μου πείτε; Ε, λοιπόν, είναι
φτιαγμένο για \`\`προγραμματιστικούς\'\' σκοπούς. Ας δούμε όμως αναλυτικά τι κάνει, πώς λειτουργεί, και πώς μπορεί να μας φανεί χρήσιμο.*
----------------------------------------------------------------------------------------------------------------------------------------------------------------
**1. ΕΙΣΑΓΩΓΗ**
-------------------------------------
- [1.1 ΤΙ ΚΑΝΕΙ ΤΟ CVS](#ss1.1)
- [1.2 ΠΩΣ ΛΕΙΤΟΥΡΓΕΙ ΤΟ CVS.](#ss1.2)
**2. ΣΤΗΣΙΜΟ CVS ΣΤΟΝ ΥΠΟΛΟΓΙΣΤΗ ΣΑΣ**
------------------------------------------------------------
- [2.1 LOGIN ΚΑΙ ΕΡΓΑΣΙΑ ΣΕ ΕΝΑ CVS SERVER](#ss2.1)
- [2.2 ΑΝΑΝΕΩΣΗ ΤΟΥ ΚΩΔΙΚΑ](#ss2.2)
**3. CVS FOR DEVELOPERS**
-----------------------------------------------
- [3.1 Αλλαγές στον κώδικα και πώς να τις ενσωματώσουμε στο Repository του Project.](#ss3.1)
- [3.2 CONFLICTS](#ss3.2)
- [3.3 ΠΑΡΑΚΟΛΟΥΘΗΣΗ ΑΛΛΑΓΩΝ](#ss3.3)
- [3.4 ΠΡΟΣΘΕΣΗ - ΑΦΑΙΡΕΣΗ ΑΡΧΕΙΩΝ](#ss3.4)
**4. ΕΠΙΛΟΓΟΣ**
-------------------------------------
### [1. ΕΙΣΑΓΩΓΗ]{#s1}
### [1.1 ΤΙ ΚΑΝΕΙ ΤΟ CVS]{#ss1.1}
Το cvs θα λέγαμε ότι χρησιμοποιείται για την διατήρηση και ανάπτυξη ενός προγραμματιστικού έργου (module) μεγάλης εμβέλειας, όπου πολλοί προγραμματιστές μπορούν
να εργάζονται ταυτόχρονα - ή σχεδόν ταυτόχρονα όπως θα δούμε και παρακάτω - για την ολοκλήρωση του. Διατηρεί μια δομή με αρχεία, καταλόγους αρχείων και κώδικα
που είναι προσπελάσιμα από κάθε προγραμματιστή που έχει τη διάθεση να συνεισφέρει. Φυσικά, ο καθένας μπορεί να κάνει αλλαγές που πιστεύει ότι είναι σωστές για
την καλύτερη λειτουργία του υπό αν άπτυξη προγράμματος.
### [1.2 ΠΩΣ ΛΕΙΤΟΥΡΓΕΙ ΤΟ CVS.]{#ss1.2}
Η αρχή λειτουργίας του είναι πολύ απλή. Σε κάποιο server κάπου στο παγκόσμιο δίκτυο, είναι συγκεντρωμένος ο κώδικας ενός προγράμματος. Όταν κάποιος από την
ομάδα των προγραμματιστών που έχουν αναλάβει το project θέλει να κάνει μια αλλαγή στον κώδικα, αρκεί να συνδεθεί με τον εν λόγω server και να κατεβάσει το
αρχείο στο οποίο θέλει να κάνει την αλλαγή.
Κάνει την αλλαγή και μετά το ανεβάζει\... Φυσικά, οι λέξεις \"ανεβάσει\" και \"κατεβάσει\" δεν είναι οι καλύτερες για την περιγραφή της εργασίας που γίνεται,
μια και το CVS αναλαμβάνει να \`\`ενημερώσει\'\' όλα τα αρχεία που έχουν αλλάξει. Αυτό σημαίνει, ότι ο χρήστης στον τοπικό του δίσκο έχει όλα τα αρχεία του
project (ακόμα και το README) ακόμα και αν το μόνο που κάνει είναι\... ορθογραφική διόρθωση.
Μόλις γίνει μια ενημέρωση, το CVS \`\`μαρκάρει\'\' την νέα έκδοση με ένα minor αριθμό παραπάνω. Αυτό σημαίνει ότι από 1.3 το κάνει 1.4 (Φυσικά αυτή η αλλαγή
μπορεί να είναι και από 1.5.3.4.2 σε 1.5.3.4.3). Την ίδια στιγμή, ο χρήστης που έκανε την αλλαγή, είναι υποχρεωμένος να γράψει και μια μικρή παρατήρηση. Επίσης
μαρκάρεται η ώρα της αλλαγής και το όνομα αυτού που την έκανε. Κάτι τέτοιο βοηθάει τους άλλους προγραμματιστές να μπορούν με ευκολία να απαντήσουν σε ερωτήματα
του τύπου
- Ποιός έκανε την αλλαγή;
- Πότε έγινε;
- Γιατί έγινε;
- Τι προσφέρει στον κώδικα αυτή η αλλαγή;
Αλλά πριν συνεχίσουμε, ας δούμε πώς μπορούμε να στήσουμε το δικό μας δέντρο CVS με απλές εντολές.
### [2. ΣΤΗΣΙΜΟ CVS ΣΤΟΝ ΥΠΟΛΟΓΙΣΤΗ ΣΑΣ]{#s2}
Πριν να μπορέσουμε να τρέξουμε και να κάνουμε την ενημέρωση, πρέπει να έχουμε δηλώσει μια μεταβλητή συστήματος, την CVSROOT. Αυτή είναι η διαδρομή στον
απομακρυσμένο server που βρίσκονται τα προς λήψη αρχεία.
Αν και λογικά για να διαβάζετε αυτό το άρθρο ξέρετε πως να θέσετε μια μεταβλητή συστήματος, θυμίζω για τους νέους: Ο τρόπος είναι ανάλογος του shell που
χρησιμοποιεί ο καθένας.
Η πλειοψηφία έχει bash (CVSROOT=\':pserver:anonymous\@cvs.enlightenment.org:/cvs/enlightenment\' ; export CVSROOT) και υπάρχουν και λίγοι (αλλά δυνατοί!) με csh
ή κάτι αντίστοιχο (setenv CVSROOT = \':pserver:anonymous\@cvs.enlightenment.org:/cvs/enlightenment\')
### [2.1 LOGIN ΚΑΙ ΕΡΓΑΣΙΑ ΣΕ ΕΝΑ CVS SERVER]{#ss2.1}
Επόμενο βήμα είναι να κάνουμε login σε ένα CVS server, στην παραπάνω περίπτωση θα κάνουμε Login στον CVS server που περιέχει τον enlightenment.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs login
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Σε αυτό το σημείο θα σας ζητήσει ένα password, πατήστε απλά ENTER. Δεν θα χρειαστεί να ξανακάνουμε αυτό το βήμα, εκτός αν κόψουμε πλέον τη σύνδεση!
Από αυτό το σημείο και πέρα, θα πάρουμε όλη τη δομή καταλόγου του project στο δίσκο μας.
**ΣΗΜΕΙΩΣΗ: Αν και για να μπορέσουμε να κάνουμε τον enlightenment να δουλεύει, πρέπει να κατεβάσουμε πολλά modules, εδώ θα αναφερόμαστε σε ένα για συντομία
χρόνου και χώρου.**
Ο enlightenment αποτελείται από πολλά modules. Αυτά είναι:
- e
- Eterm
- imlib
- fnlib
- esound
- audiofile
Εμείς θα ασχοληθούμε με το module της imlib, μιας βιβλιοθήκης διαχείρισης γραφικών (μπορείτε φυσικά να διαλέξετε ένα άλλο module)
Την κατεβάζουμε λοιπόν τοπικά με την εντολή:
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs -z3 checkout imlib
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Φυσικά, μπορούμε να πάρουμε και πάνω από ένα module με μια εντολή:
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs -z3 checkout imlib fnlib ...
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Σε αυτό το σημείο έχουμε κατεβάσει όλο τον κώδικα του module, και είμαστε έτοιμοι να κάνουμε τις αλλαγές που θα κρίνουμε απαραίτητες ή αν δεν είμαστε στο
development team απλά να κάνουμε compile τον νέο μας κώδικα!
**ΠΡΟΣΟΧΗ: Δεν είναι ανάγκη να κάνουμε καμμία αλλαγή, οι άνθρωποι που γράφουν τον κώδικα ξέρουν τι κάνουν.** Αν και εσείς ξέρετε τι κάνετε, δεν το βρίσκω πρέπoν
να τους αλλάξουμε των κώδικά τους!! (εκτός και αν ανήκετε στο development team).
Ας δούμε το directory structure που δημιουργήθηκε στο δίσκο μας. Έχει δημιουργηθεί ο κατάλογος `imlib/` που περιέχει όλον τον κώδικα, και ένας κατάλογος `CVS/`,
στον οποίο το cvs έχει καταγεγραμμένες πληροφορίες για καθένα από τα αρχεία ώστε να μπορεί να καταλάβει τι αλλαγές κάναμε από τότε που το κατεβάσαμε (Αυτό
χρειάζεται για την περίπτωση που θέλουμε να το ανεβάσουμε με δικές μας αλλαγές, ώστε να ξέρει τι log file να δημιουργήσει).
Έχουμε πλέον την πιο νέα έκδοση του πακέτου αυτού!
Φυσικά, αυτό δεν είναι πάντα καλό, μια και πολλές φορές το πακέτο που μόλις κατεβάσαμε δεν κάνει compile καν! Φυσικό, όπως αντιλαμβάνεστε, μια και μιλάμε για
ΧΟΝΤΡΟ development, όπου συνήθως ενσωματώνονται νέα χαρακτηριστικά. Είναι λοιπόν πιθανότατο ακόμα και αν κάνει compile να μας \`\`κολλάει\'\' συνεχώς (core
dumped κ.λπ.). Σε αυτή την περίπτωση ή προσπαθούμε να το φτιάξουμε μόνοι μας, ή\... περιμένουμε να βγει νεότερη έκδοση. Σε καμία περίπτωση μη στείλετε mail
στους developers να τους πείτε \`\`δεν δουλεύει αυ τό\'\'. Πιστέψτε με, το ξέρουν καλύτερα από εμάς!!
### [2.2 ΑΝΑΝΕΩΣΗ ΤΟΥ ΚΩΔΙΚΑ]{#ss2.2}
Την επόμενη φορά που θα πάμε στο CVS server για ανανέωση, δεν θα κάνουμε checkout, αλλά update. Κάτι τέτοιο σημαίνει ότι θα μας έρθουν μόνο τα πακέτα που έχουν
αλλάξει, και όχι όλα από την αρχή. Αυτό μπορεί να γίνει με την εντολή:
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs -z3 update -Pd imlib
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Φυσικά, κάνουμε την προσευχή μας να κάνει compile. Αν και πιστεύω ότι δεν θα εισακουστεί (μιλάω εκ πείρας), πάντα υπάρχουν οι εξαιρέσεις, και πάντα γίνονται
θαύματα.
Οι απλοί χρήστες που θέλουν να έχουν την πιο νέα έκδοση του λογισμικού στο δίσκο τους, και όχι να γράφουν κώδικα, **μόλις τελείωσαν το διάβασμα αυτού του
άρθρου**. Στη συνέχεια, αυτό που εξηγείται είναι το πως το cvs καταφέρνει να τα βγάζει πέρα με τυχόν conflicts (π.χ.: δύο developers την ίδια στιγμή έκαναν
revisions στο ίδιο αρχείο), το πως μπορούμε να δημιουργήσουμε νέα αρχεία ή και ολόκληρα directories και να τα συμπεριλάβουμε στο repository του module.
Όσοι δεν ασχολείστε με προγραμματισμό, μην συνεχίσετε το διάβασμα, εκτός αν θέλετε να μάθετε εγκυκλοπαιδικά πως δουλεύει το CVS. Δεν είναι τίποτα δυσνόητο, αλλά
κατά πάσα πιθανότητα δε θα σας ενδιαφέρει.
### [3. CVS FOR DEVELOPERS]{#s3}
### [3.1 Αλλαγές στον κώδικα και πώς να τις ενσωματώσουμε στο Repository του Project.]{#ss3.1}
Οι αλλαγές που τυχόν θα γίνουν θα γραφούν τοπικά στο δικό σας δίσκο, και όχι στο server. Αυτό πάει να πει ότι οι άλλοι developers δεν θα δουν τις αλλαγές σας,
μέχρι να σιγουρευτείτε ότι αυτό που κάνατε δουλεύει και μόνο αν του το πείτε θα τα ανεβάσει. Αυτό γίνεται με την εντολή **`/cvs commit`**
Πριν γίνει όμως το γράψιμο στο server, πρέπει πάνω του να υπάρχει η έκδοση των αρχείων που είχατε κατεβάσει ώστε τυχόν αλλαγές που έκαναν άλλοι developers να
μην χαθούν (αυτός είναι ο σκοπός του directory CVS/ που έχει δημιουργηθεί στην ιεραρχία καταλόγων στο δίσκο σας). Κάνουμε λοιπόν ένα
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs update imlib
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Έστω ότι κάναμε αλλαγές στο αρχείο README, αλλά άλλος ένας έχει κάνει αλλαγές τόσο στο ίδιο αρχείο όσο και στο αρχείο Makefile στο μεσοδιάστημα. Μετά την εντολή
update, βλέπουμε την έξοδο:
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs update: Updating .
> U Makefile
> RCS file: /imlib/README
> retrieving revision 1.5
> retrieving revision 1.6
> Merging differences between 1.5 and 1.6 into README
> M README
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Όλα αυτά σημαίνουν:
> U Makefile
Οι αλλαγές που έκανε ο άλλος κατέβηκαν στο δίσκο μας.
> RCS file: /imlib/README
> retrieving revision 1.5
> retrieving revision 1.6
> Merging differences between 1.5 and 1.6 into README
Αυτό μας δείχνει ότι οι δύο revisions 1.5 και 1.6 του αρχείου README συγχωνεύτηκαν σε ένα αρχείο, το README, τοπικά, στο δίσκο μας.
> M README
Το γράμμα Μ, φανερώνει ότι το αρχείο έχει αλλαχθεί από εμάς, και ότι οι αλλάγες δεν ανέβηκαν ακόμα (φυσικό αυτό, ένα update κάναμε.
Ας μην ξεχνάμε ότι τώρα το αρχείο README περιλαμβάνει και τις αλλαγές του άλλου!!! Καλό (απαραίτητο για να είμαι ακριβής) θα είναι να κάνουμε έναν έλεγχο να
δούμε αν δουλεύει ακόμα ο κώδικας. Φυσικά, στην περίπτωσή μας, δεν είναι ανάγκη, γιατί είναι ένα text κείμενο, που δεν επηρεάζει τη λειτουργικότητα του όλου
project (αυτό δεν σημαίνει ότι δεν θα ήταν καλό να ελέγξουμε τί αλλαγές έκανε ο άλλος).
Καλό θα είναι πριν κάνουμε commit, να ξανακάνουμε update, ώστε στο διάστημα που κάναμε τον έλεγχο να μην έγινε καμμία άλλη αλλαγή (πράγμα σπάνιο). Η έξοδος,
καλώς εχόντων των πραγμάτων, θα είναι:
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs update: Updating .
> M README
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
\`Αρα, οι μόνες αλλαγές είναι στο δίσκο μας. Πάμε για commit.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> $ cvs commit
> README
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Τώρα θα μας ζητηθεί να γράψουμε ένα μικρό κείμενο που θα εξηγεί στους άλλους τι αλλαγές κάναμε και γιατί. Μόλις τελειώσουμε, θα πάρουμε από το CVS:
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Checking in README;
> /imlib/README,v <-- README
> new revision: 1.7; previous revision: 1.6
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Τώρα, οι αλλαγές μας θα είναι πάνω στο server, και οι άλλοι προγραμματιστές όταν θα κάνουν cvs update θα τις πάρουν στο δίσκο τους.
### [3.2 CONFLICTS]{#ss3.2}
Κάτι τέτοιο είναι εφικτό στην περίπτωση που οι γραμμές που αλλάζουν οι δύο developers δεν είναι ίδιες. Αν όμως τύχει και αλλάζουν και οι δύο την ίδια γραμμή;
Σε αυτή την περίπτωση έχουμε conflict, και το cvs μας αφήνει να βρούμε μόνοι μας τη λύση. Μας αφήνει με ένα αρχείο, στο οποίο φαίνεται η περιοχή που έγινε το
conflict, περιέχει και τις δύο απόψεις (τη δική μας και αυτή που έρχεται σε αντίθεση με τη δική μας, του άλλου προγραμματιστή) και είμαστε αναγκασμένοι να το
ελέγξουμε, να κάνουμε τυχόν αλλαγές και να ξανακάνουμε commit. Αυτό, αν και ακούγεται δύσκολο, είναι πολύ εύκολο (και φυσικά απαραίτητο) γιατί ο τρόπος που μας
έχει φτιάξει το αρχείο βοηθάει στην κ ατανόηση του προβλήματος που έχει δημιουργηθεί. Από εκεί και πέρα, είναι απαραίτητο να έχουμε σωστή κρίση ώστε να αφήσουμε
στον κώδικα την καλύτερη λύση από τις δύο προτεινόμενες (ακόμα και αν αυτή δεν είναι η δική μας!)
### [3.3 ΠΑΡΑΚΟΛΟΥΘΗΣΗ ΑΛΛΑΓΩΝ]{#ss3.3}
Για να μπορέσουμε να δούμε τις αλλαγές που έχουν γίνει σε ένα αρχείο του project, θα χρησιμοποιήσουμε την εντολή **`cvs log`**
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs log README
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Θα μας παρουσιαστεί ένα κατεβατό με μια περιγραφή του αρχείου, τον τρέχοντα αριθμό αναθεώρησης, καθώς και όλες τις αναθεωρήσεις που του έχουν γίνει, καθώς και
το log για κάθε μια από αυτές.
### [3.4 ΠΡΟΣΘΕΣΗ - ΑΦΑΙΡΕΣΗ ΑΡΧΕΙΩΝ]{#ss3.4}
Η πρόσθεση και η αφαίρεση αρχείων γίνεται όπως και με τις αλλαγές σε αρχεία, αφού πρώτα καταγραφούν οι αλλαγές στο cvs directory που έχει δημιουργήσει. Με αυτό
τον τρόπο (και μόνο) μπορεί το cvs να ξεχωρίσει τι αλλαγές έχουν γίνει.
#### ΠΡΟΣΘΕΣΗ
Το να προσθέσουμε απλά ένα αρχείο στο directory structure του δίσκου μας, δεν είναι αρκετό. Σε αυτή την περίπτωση, το cvs θα μας πει με πολύ κομψό τρόπο ότι δεν
έχει ακουστά αυτό το αρχείο ακόμα (CVS doesn\'t know about this file yet) στο επόμενο update.
Για να το προσθέσουμε, πρέπει να κάνουμε cvs add. Έστω ότι δημιουργήσαμε το αρχείο colors.c. Για να ολοκληρωθεί η διαδικασία πρόσθεσης του αρχείου, κάνουμε τα
εξής βήματα (με \$ αρχίζουν οι εντολές που δίνουμε, τα άλλα είναι η έξοδος του cvs).
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> $ cvs add colors.c
> cvs add: scheduling file `colors.c' for addition
> cvs add: use 'cvs commit' to add this file permanently
> $ cvs update
> cvs update: Updating .
> A colors.c --- The file is marked for addition.
> $ cvs commit colors.c
> (...Το cvs θα μας ζητήσει να δώσουμε εδώ ένα κείμενο για το log...)
> RCS file: /imlib/colors.c
> done
> Checking in colors.c;
> /imlib/colors.c,v <-- colors.c
> initial revision: 1.1
> done
> $
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Παρατηρούμε και την αρχική αρίθμηση, που είναι από το 1.1. Από αυτή τη στιγμή το αρχείο που προσθέσαμε βρίσκεται στο repository του project, και οι χρήστες που
θα κάνουν update, θα το πάρουν μαζί με όλα τα άλλα του project.
#### ΑΦΑΙΡΕΣΗ
Αν απλά αφαιρέσουμε ένα αρχείο από το directory structure του σκληρού μας, φυσικά και δεν φεύγει από το server. Μάλιστα, όταν κάνουμε cvs update, το αρχείο θα
επαναδημιουργηθεί. Αυτό βοηθάει πολύ σε περιπτώσεις που έχουμε κάνει πολλές αλλαγές σε ένα αρχείο και αποφασίσουμε ότι κάναμε λάθος και τελικά δεν έπρεπε να
γίνουν αλλαγές. Σε αυτή την περίπτωση απλά σβήνουμε το αρχείο και κάνουμε ένα update.
Είναι κατανοητό ότι η αφαίρεση ενός αρχείου είναι επικίνδυνο παιχνίδι, και γιαυτό το cvs δεν αφήνει πλήρη ελευθερία στον χρήστη. Φυσικά, μπορεί να δημιουργηθεί
μια \`\`αφαίρεση\'\', η οποία όμως θα είναι πλασματική. Δηλαδή: Για να διαγράφεί ένα αρχείο, πρέπει πρώτα να το σβήσουμε από το δίσκο μας, και να γράψουμε την
εντολή
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> cvs rm `filename'
> cvs commit `filename'
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Πάντως, αυτό δεν το καταστρέφει από το server. Απλά φτιάχνει μια νέα \`\`αναθεώρηση\'\' στην οποία χαρακτηρίζεται ως \`\`ανύπαρκτο\'\'. Υπάρχει ακόμα όμως, και
μπορεί να ανακληθεί π.χ. με την εντολή cvs log.
### [4. ΕΠΙΛΟΓΟΣ]{#s4}

112
content/articles/19/04_boot.md Κανονικό αρχείο

@ -0,0 +1,112 @@
+++
title = 'Διαδικασία εκκίνησης του Υπολογιστή.'
date = '1999-11-01T00:00:00Z'
description = ''
author = 'DJ Art(mailto:djart@freemail.gr)'
issue = ['Magaz 19']
issue_weight = 4
+++
----------------------------------------------------------------------------------------------------------------------------------------------------------------
*Το άρθρο αυτό αποτελεί συνέχεια του αντίστοιχου άρθρου του τεύχους 13. Έχει σκοπό να εμβαθύνει περισσότερο στο εσωτερικό και στη λειτουργία του αρχείου
/etc/inittab και του καταλόγου /etc/rc.d/*
----------------------------------------------------------------------------------------------------------------------------------------------------------------
**1. init και /etc/inittab**
---------------------------------------------------
**2. Τα αρχεία /etc/inittab και /etc/rc.d/rc.sysinit**
-----------------------------------------------------------------------------
**3. Το αρχείο /etc/rc.d/rc.local**
----------------------------------------------------------
**4. Οι κατάλογοι rcX.d**
------------------------------------------------
### [1. init και /etc/inittab]{#s1}
Η man page του init αναφέρει: \"Το init είναι ο πατέρας όλων των processes\". Ο πρωταρχικός του ρόλος είναι να δημιουργήσει processes από τις οδηγίες που του
δίνει το /etc/inittab. Ο τρόπος με τον οποίο το Linux εκκινεί τα processes μετά από το boot του kernel, προέρχεται από μία άλλη έκδοση του UNIX, την System V.
Στην πραγματικότητα η εντολή init είναι συμβατή με την System V init εντολή. Παρόλο που η init χαρακτηρίζεται ως το τελευταίο βήμα της διαδικασίας του boot του
kernel, είναι η πρώτη εντολή που ρυ θμίζει και προετοιμάζει το σύστημά σας για χρήση. Η init δουλεύει διαβάζοντας το /etc/inittab και τρέχοντας τα scripts του
καταλόγου /etc/rc.d σύμφωνα βέβαια με το επιθυμητό runlevel. Κάθε script μπορεί να σταματήσει ή να ξεκινήσει μια υπηρεσία, όπως π.χ. την υπηρεσία για το mail,
τα news ή το Web.
Αυτή είναι μιά άποψη του καταλόγου /etc/rc.d (προσέξτε ότι από διανομή σε διανομή, τα runlevels δεν είναι ίδια):
init.d/
rc*
rc.local*
rc.sysinit*
rc0.d/
rc1.d/
rc2.d/
rc3.d/
rc4.d/
rc5.d/
rc6.d/
Στον κατάλογο /etc/rc.d/init.d θα βρείτε έναν αριθμό από scripts που χρησιμεύουν στο να σταματούν ή να ξεκινούν τις διάφορες υπηρεσίες.
### [2. Τα αρχεία /etc/inittab και /etc/rc.d/rc.sysinit]{#s2}
Το σπουδαιότερο script είναι το rc.sysinit, καθώς είναι το πρώτο script που εκτελείται στο Linux. Οι λειτουργίες του script αυτού είναι οι εξής:
- Ορίζει το PATH (κάνει export τη μεταβλητή PATH)
- Ρυθμίζει το networking
- Ξεκινάει το swapping για τη virtual memory
- Ορίζει το hostname του συστήματος
- Ελέγχει το root partition για πιθανές επιδιορθώσεις (fsck)
- Ελέγχει τα quotas του root filesystem
- Ενεργοποιεί τα user και group quotas για το root filesystem
- Ξανακάνει mount το root filesystem, αλλά αυτήν την φορά read/write
- Ελέγχει τον πίνακα των mounted filesystems, τον /etc/mtab
- Ετοιμάζει το σύστημα για το φόρτωμα των modules
- Βρίσκει τα modules dependencies
- Ελέγχει τα υπόλοιπα filesystems για πιθανές επιδιορθώσεις
- Κάνει mount όλα τα υπόλοιπα filesystems
- Σβήνει πολλά /etc αρχεία, όπως π.χ. το /etc/fastboot
- Σβήνει τα UUCP lock αρχεία
- Ρυθμίζει την ώρα του συστήματος
- Ξεκινάει το swap partition
- Ετοιμάζει τις serial ports
- Φορτώνει τα modules
Το rc.sysinit script εκτελείται από την init δια μέσου του /etc/inittab. Το inittab περιέχει την εξής γραμμή:
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
### [3. Το αρχείο /etc/rc.d/rc.local]{#s3}
Μέχρι τώρα είδαμε ότι μετά το boot του kernel, η εντολή τρέχει το script rc.sysinit. Στη συνέχεια, η εντολή init εκτελεί το script rc.local. Αν κοιτάξετε το
περιεχόμενο του rc.local, θα διαπιστώσετε ότι αυτό το script μαζεύει πληροφορίες για το όνομα της διανομής σας και για την αρχιτεκτονική του υπολογιστή σας και
τοποθετεί αυτές τις πληροφορίες στο αρχείο /etc/issue. Το περιεχόμενο του αρχείου αυτού αναδεικνύεται κατά τη διαδικασία του login από το χρήστη.
Αναλυτικότερα, σε ένα RedHat σύστημα, το rc.local διαβάζει το αρχείο /etc/redhat-release, που περιέχει την έκδοση της διανομής, και στη συνέχεια εκτελεί τις
εντολές **uname -r**, που εμφανίζει την έκδοση του kernel, και **uname -m**, που εμφανίζει τον τύπο του επεξεργαστή (π.χ. 686). Στο τέλος, τοποθετεί όλες αυτές
τις πληροφορίες στο αρχείο /etc/issue (με echo \>\> ).
**Σημείωση:** Ο σκοπός του rc.local δεν είναι να αποτελεί ένα μέρος για να βάζει κανείς εντολές για τη ρύθμιση (initialization) του συστήματος, παρόλο που
μερικοί το κάνουν. Στο BSD UNIX, το rc.local χρησιμοποιείται για τον έλεγχο των δικτυακών υπηρεσιών. Το Linux δεν χρησιμοποιούσε πάντα τα ίδια initialization
scripts, οπότε μπορεί να βρείτε διαφορές μεταξύ των RedHat, SuSE, Slackware και των άλλων διανομών.
### [4. Οι κατάλογοι rcX.d]{#s4}
Η επόμενη εργασία που κάνει η εντολή init είναι η εκτέλεση των ειδικών scripts για κάθε runlevel. Μέσα στον κατάλογο /etc/rc.d, όπως είδαμε, υπάρχουν οι
κατάλογοι rcX.d, όπου X είναι ο αριθμός του αντίστοιχου runlevel (από 0 έως 6). Αν κοιτάξετε τα περιεχόμενα ενός από αυτούς του καταλόγους, θα δείτε οτι
περιέχουν links στα διάφορα scripts του καταλόγου /etc/rc.d/init.d. Η μορφή των links είναι κάπως έτσι:
S10network ή
K10network
Το γράμμα S ή K αντιστοιχεί στην εκκίνηση ή στον τερματισμό μιάς υπηρεσίας (S από το Start και K από το Kill). Ο αριθμός δίπλα από το γράμμα χρησιμεύει για να
τρέχουν τα scripts στη σωστή σειρά (για παράδειγμα να μην κάνει unmount τα partitions πριν κλείσει το network file-sharing).

181
content/articles/19/05_benchmarks.md Κανονικό αρχείο

@ -0,0 +1,181 @@
+++
title = 'Benchmark(et)ing\...'
date = '1999-11-01T00:00:00Z'
description = ''
author = 'Κυριάκος Κ. Σκαφάς(mailto:kskafas@usa.net)'
issue = ['Magaz 19']
issue_weight = 5
+++
----------------------------------------------------------------------------------------------------------------------------------------------------------------
*Κάποια σχόλια σχετικά με τα benchmarks - συγκριτικά μεταξύ NT και Linux που είδαν πρόσφατα το φως της δημοσιότητας.*
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Υπόσχομαι οτι δεν θα μου γίνει συνήθεια, αλλά, τουλάχιστον αυτή τη πρώτη φορά, θα πρέπει να επεκταθώ σε κάτι που δεν έχει παρά ελάχιστη μόνο σχέση με το θέμα
που θα πραγματευθώ παρακάτω. Την αγωνία που βιώνει ο αρθρογράφος πριν, αλλά και κατά την αναζήτηση και ανάπτυξη του θέματος. Ποιό ύφος θα πρέπει να υιοθετήσω,
να γράψω σε πρώτο ή τρίτο πρόσωπο, να φαίνομαι απόμακρος ή προσιτός; Επέλεξα να παραμείνω απλώς ο εαυτός μου. Για να είμαι ειλικρινής, όμως, δεν ήταν αυτό το
κύριο πρόβλημα που αντιμετώπισα. Πιό θέμα να διαλέξω; Πόσο να το αναπτύξω; Η απάντηση ήταν σχεδόν αυτονόητη: αφού αυτό θα είναι το πρώτο άρθρο, το περιεχόμενο
θα πρέπει να έχει πανηγυρικό ύφος. Θα πρέπει να γράψω για την ανωτερότητα του Linux έναντι άλλων λειτουργικών συστημάτων, όπως αυτών της Microsoft. Και τι θα
αποτελούσε την καλύτερη απόδειξη παρά μια παράθεση αποτελεσμάτων γνωστών έγκυρων και έγκριτων συγκριτικών benchmarks; Και ενώ είχα αποφασίσει για τα πάντα,
προέκυψαν τα λεγόμενα Mindcraft Benchmarks.
Η [Mindcraft](http://www.mindcraft.com) είναι μια εταιρία η οποία αναλαμβάνει για λογαριασμό των εκάστοτε πελατών της να φέρει σε πέρας μελέτες που τους αφορούν
και να δημοσιεύσει τα αποτελέσματα μετά από άδεια τους ( <http://www.mindcraft.com/company/>). Η παραπάνω εταιρία ανέλαβε για λογαριασμό της Microsoft να φέρει
σε πέρας τρεις μελέτες που αφορούν στις επιδόσεις του επαγγελματικού λειτουργικού συστήματος της Microsoft, Windows NT 4.0 αναβαθμισμένα με το Service Pack 4 σε
σχέση με αυτό της [Sun](http://www.sun.com/), Solaris 2.6. ( <http://www.mindcraft.com/whitepapers/nts4sol26web.html>), σε σχέση με αυτό της
[Novell](http://www.novell.com/), Netware 5.0 ( <http://www.mindcraft.com/whitepapers/nts4nw5filesvr.html>) και τέλος σε σχέση με το
[Linux](http://www.linux.com) και συγκεκριμμένα με το [RedHat](http://www.redhat.com/) Linux 5.2 (έκδοση πυρήνα 2.0.36) αναβαθμισμένο στον πυρήνα (kernel) 2.2.2
( <http://www.mindcraft.com/whitepapers/first-nts4rhlinux.html>), σε αντίστοιχο, παρόμοιο ή και όμοιο υλικό (hardware), των οποίων τα αποτελέσματα δημοσιεύθηκαν
με διαφορά δύο εβδομάδων μεταξύ τους.
Ευνόητο είναι ο,τι αφού δημοσιεύθηκαν τα αποτελέσματα αυτά ήταν ευνοϊκά για τον πελάτη. Όπως ήταν άλλωστε αναμενόμενο, και στις τρεις περιπτώσεις αντέδρασαν οι
ηττημένοι ( [Novell](http://www.novell.com/advantage/nw5/nw5-mindcraftcheck.html)). Στη πρώτη περίπτωση, η ήττα της Sun εξέπληξε. Το Solaris είναι ένα αυθεντικό
και με μακρά ιστορία Unix, βασισμένο στο AT&T Unix System V με διάφορα στοιχεία από BSD Unix, με αρχιτεκτονική 64bit, με σύστημα αρχειοθέτησης ικανό για γρήγορη
ανάκαμψη από βλάβες (Journalling FileSystem - JFS), με συμμετρική πολυδιεργασία (Symmetrical MultiProcessing - SMP) για ταυτόχρονη χρήση μέχρι 128 επεξεργαστων,
ιδιότητα τέτοια ωστέ πολλοί δικτυωμένοι υπολογιστές να συμπεριφέρονται σαν ένας (clustering) και πολλά άλλα, αναρίθμητα, χαρακτηριστικά τα οποία βελτιώνουν την
ταχύτητα, καθώς και άλλα που δεν την επηρεάζουν. Αντίθετα, στη δεύτερη περίπτωση, η ήττα της Novell ήταν αναμενόμενη, επειδή παρά το γεγονός ο,τι το Netware
έχει την δυνατότητα της πλήρους διαχείρισης από έναν υπολογιστή και όλων των άλλων σε ένα δίκτυο (Novell Directory Services - NDS) και μία από τις καλύτερες
εικονικές μηχανές για την γλώσσα προγραμματισμού Java (Java Virtual Machine - JVM), δεν είχαν καταβληθεί ιδιαίτερες προσπάθειες για την βελτίωση της ταχύτητας
του. Και ενώ αντέδρασαν επίσημα οι παραπάνω εταιρίες δεν δημιουργήθηκε ποτέ θέμα, επειδή δεν αντέδρασαν οι χρήστες και οι χρήστες δεν αντέδρασαν είτε επειδή
ήταν, απλώς, λίγοι, είτε επειδή είχαν ήδη επενδύσει σε ένα από τα παραπάνω λειτουργικά συστήματα, ήταν ευχαριστημένοι και ανεξάρτητα από τα δημοσιεύματα, δεν
ήταν διατεθιμένοι να τα αλλάξουν. Στη τρίτη, όμως, περίπτωση, σχεδόν κυριολεκτικά, αναταράχθηκε το Διαδίκτυο.
Σύμφωνα με τη μελέτη αυτή, τα Windows NT [αποδείχθηκαν](http://www.mindcraft.com/whitepapers/first-nts4rhlinux.html#exec_summary) κατά 3,7 φορές ταχύτερα του
Linux στον τομέα εξυπηρέτησης στατικών δεδομένων HTTP και κατά 2,5 φορές στον τομέα εξυπηρέτησης SMB. HTTP και SMB ονομάζονται τα προτόκολλα διαμεταγωγής
δεδομένων, όπως ιστοσελίδων και εικόνων, στον παγκόσμιο ιστό (World-Wide Web - WWW) και αρχείων στα δίκτυα Windows, αντίστοιχα. Το λογισμικό (software) για τα
Windows NT αποτελούσαν ο Microsoft Internet Information Server 4.0 και οι ενσωματωμένες υπηρεσίες SMB και για το Linux ο Apache 1.3.4 και η Samba 2.0.1.
Το υλικό ήταν κοινό, ένας εξυπηρετητής (server) της Dell, ο PowerEdge 6300/400, ο οποίος διαθέτει τέσσερεις επξεργαστες Pentium II Xeon 400MHz, 1 MByte Cache, 1
GByte RAM, έναν σκληρό δίσκο 9 GBytes και σε συστειχία (Redundant Array of Inexpensive Disks - RAID) οκτώ σκληρούς δίσκους 4 GBytes, τέσσερεις κάρτες δικτύου
Ethernet 100 MBit, και ο οποίος [κοστίζει \$50.000](http://www.mindcraft.com/whitepapers/first-nts4rhlinux.html#products).
Στο Διαδίκτυο, ο Apache, απολαμβάνει ένα ποσοστό περίπου 54%, το μεγαλύτερο, ακόμη μεγαλύτερο από το άθροισμα των ποσοστών των Netscape και Microsoft, και
υπερδιπλάσιο από του καθενός ξεχωριστά. Ο μεγαλύτερος από τους υποστηρικτές του Apache είναι η International Business Machines (IBM), η οποία δεν χρειάζεται
συστασεις και η οποία τον ενσωμάτωσε στην WebShere, στην λύση της για ηλεκτρονικό εμπόριο (e-commerce). Η Samba αποτελεί τη μοναδική εναλλακτική λύση στη θέση
ενός αυθεντικού εξυπηρετητή SMB και απολαμβάνει, μεταξύ άλλων, της υποστήριξης της Silicon Graphics (πρόσφατα μετoνομάσθηκε σε SGI), της οποίας τα μηχανήματα
χρησιμοποιούνται στην κατασκευή οπτικών F/X σε ταινίες, όπως Terminator 2 και Jurassic Park και η οποία με αυτό συνοδεύει το λειτουργικό σύστημα της. Πρέπει να
σημειωθεί οτι η Microsoft δε δημοσίευσε ποτέ κάποια περιγραφή των χαρακτηριστικών και των λειτουργειών του SMB με αποτέλεσμα οι προγραμματιστές της Samba να
αναγκασθούν να παρακολουθήσουν με ιδιαίτερη προσοχή τα πακέτα δεδομένων που πηγαινοέρχονταν σε δίκτυα που χρησιμοποιούσαν SMB για να καταφέρουν να αναπαράγουν
τη συμπεριφορά του SMB με τη Samba.
Επίσης, υπάρχουν διάσπαρτες στο Διαδίκτυο πολλές άλλες μελέτες πρόσφατες και παλαιότερες, οι οποίες συνίστανται ή, απλώς, υποστηρίζονται από benchmarks, των
οποίον [τα πορίσματα](http://www.unix-vs-nt.org/kirch/) συγκρούονται με αυτά των Mindcraft Benchmarks.
Έτσι, πολλοί ήταν αυτοί που έσπευσαν να καταδικάσουν την Mindcraft. Η Mindcaft επιτέλεσε θαυμαστό έργο στην παραμετροποίηση των Windows NT, ενώ αποδείχθηκε
παντελώς ανίκανη στην παραμετροποίηση του Linux, του Apache και της Samba, αφού σε πολλές περιπτώσεις άλλαξε τις προεπιλεγμένες παραμέτους σε άλλες οι οποίες
μείωναν τις επιδόσεις. Το Linux δεν διέθετε \"ώριμο\" οδηγό του ελεγκτή της συστοιχίας των δίσκων της AMI. Θα μπορούσε κάλλιστα στη θέση αυτού του ελεγκτή να
τοποθετηθεί κάποιος άλλος, που υποστηρίζεται πλήρως, όπως αυτοί της Mylex και της Vortex. Στα Windows ΝΤ διατέθηκε όλη, ενώ στο Linux διατέθηκε μόνο το 96% της
μνήμης του συστήματος. Σε ένα τέτοιο μηχάνημα, αυτό αντιστοιχεί σε μείωση κατά 4% των επιδόσεων. Στο Linux διατέθηκε μόνο το 60% της μνήμης για προσωρινή
αποθήκευση κάποιων δεδομένων των σκληρών δίσκων (buffering). Ο πυρήνας 2.2.2, στον οποίο αναβαθμίστηκε το Linux, παρουσίαζε προβλήματα στην εξυπηρέτηση πελατών
Windows. Όλοι οι πελάτες ήταν Windows 95. Και ο Apache και η Samba μεταγλωττίστηκαν από τη Mindcraft διαφορετικά από ο,τι από την RedHat. Αυτό είχε σαν
επακόλουθο μειώση των επιδόσεων. Και στον Apache προσδιορίστηκε λάθος ο αριθμός των αρχικών και των διαθέσιμων εξυπηρετητών (οι StartServers θα έπρεπε να είναι
τουλαχιστον 150 και οι SpareServers μέχρι και άλλοι τόσοι) και στη Samba απενεργοποιήθηκε μια επιλογή που μείωσε καταλυτικά τις επιδόσεις (\"widelinks=no\").
Στα μάτια των περισσοτέρων πεπειραμένων χρηστών Linux, η ενέργεια αυτή χαρακτηρίσθηκε εσκεμμένη και διαβολική. Η Mindcraft διαμαρτηρήθηκε, λέγοντας πως το
προσωπικό της ζήτησε τη γνώμη των χρηστών Linux σχετικά, σε news groups και mailing lists, και οτι αυτοί δεν απάντησαν, κάτι το οποίο έρχεται σε αντίθεση με την
εδραιωμένη από παλιά, ακόμη, φήμη τους που τους θέλει πάντα πρόθυμους να προσφέρουν βοήθεια (http://www.infoworld.com/cgi-bin/displayTC.pl?/97poy.supp.htm). Οι
χρήστες Linux αντεπιτέθηκαν, λέγοντας πως οι ερωτήσεις οι οποίες ετέθησαν δεν ήταν παρά γενικολογίες, ενώ παράλληλα δημιουργήθηκαν σχεδόν μισή δωδεκάδα sites με
οδηγίες για τη καλύτερη δυνατή παραμετροποίηση ενός Linux συστήματος, ανάλογα με τη χρήση (http://www.linux.com/tuneup/). Στην διαδρομή προέκυψαν και άλλα
στοιχεία. Το προσωπικό της Mindcraft επικοινωνούσε με τον υπόλοιπο κόσμο από τις εγκαστάσεις της Microsoft, και γρήγορα έγινε αντιληπτό ο,τι και τα Mindcraft
Benchmarks πραγματοποιήθηκαν στις εγκαταστάσεις της Microsoft.
Ακόμα και η Microsoft, δια του αντιπροσώπου της Ian Hatton, [παραδέχθηκε την μη εγκυρότητα των
Benchmarks](http://www.itweb.co.za/sections/enterprise/1999/9904221410.asp).
Έτσι η Mindcraft επανέλαβε τα Benchmarks με την βοήθεια γνωστών προσωπικοτήτων της κοινότητας χρηστών Linux, όπως του Linus Torvalds, αρχικού δημιουργού και
μετέπειτα συντονιστή της ανάπτυξης του πυρήνα, και το Jeremy Allison, κύριου προγραμματιστή της Samba, αλλά δεν δημοσίευσε τα αποτελέσματα, επειδή ήταν πολλοί
εκείνοι που την κατηγόρουσαν για αδιαφάνεια.
Η Mindcraft έπρεπε να υπερασπίσει το κύρος της, άλλωστε αυτό είναι το είδος το οποίο εμπορεύεται. Έμμεσα παραδεχόμενη την προφανή και πρωτοφανή της ανικανότητα
να φέρει σε πέρας την μελέτη που τις ανατέθηκε, πρότεινε την επανάληψη των benchmarks, από τον ανεξάρτητο εκδοτικό οργανισμό [Ziff-Davis](http://www.zdnet.com/)
και πιο συγκεκριμμένα από το περιοδικό [PC Week](http://www.zdnet.com/pcweek/), παρουσία αντιπροσώπων της Microsoft, της RedHat και της
[Mindcraft](http://www.mindcraft.com/openbenchmark.html). Αν επιβεβαιωνόταν η Mindcraft το κύρος της θα αποκαθίστατο και η Microsoft θα είχε στα χέρια της μια
σχετικά αξιόπιστη απόδειξη της ανωτερότητας του δικού της λειτουργικού συστήματος, στη θέση μιας παρωδίας.
Πράγματι, τα benchmarks επαναλήφθηκαν, δικαίωσαν την Mindcraft ως προς την ορθότητα των αποτελεσμάτων με την συγκεκριμμένη παραμετροποίηση, απέδειξαν οτι το
Linux θα μπορούσε να είχε αποδώσει καλύτερα, όπως επίσης οτι σε καμμία περίπτωση δεν θα μπορούσε να αποδώσει καλύτερα από τα Windows NT στο ίδιο υλικό. Βαθύτερη
μελέτη των αποτελεσματων αποκάλυψε τους λόγους. Ο κυριότερος λόγος είναι ο,τι το Linux δεν υποστηρίζει πολυνηματική δικτύωση (multithreaded TCP/IP stack),
δηλαδή δεν μπορεί να διαβιβάσει σε μία ορισμένη στιγμή δεδομένα παρά μόνο μέσω μίας δικτυακής σύνδεσης (
<http://www.zdnet.com/pcweek/stories/news/0,4153,1015266,00.html>). Ένας δευτερεύων λόγος είναι ο,τι το Linux δεν διαθέτει αρκετά καλή συμμετρική πολυδιεργασία,
δηλαδή δεν μπορεί να εκμεταλλευθεί στο έπακρο κανέναν επεξεργαστή μετά τον πρώτο, αλλά αντίστοιχο πρόβλημα αντιμετωπίζουν και τα Windows NT.
Κανένας δεν απελπίστηκε στον χώρο του Linux. Ανάμεσα σε αυτούς υπήρξαν κάποιοι που [διακομώδησαν το όλο
συμβάν](http://segfault.org/story.phtml?mode=2&id=377c4f9f-039ab200) και αρκετοί που από τη πρώτη στιγμή καλωσόρισαν τα Mindcraft Benchmarks ως ευεργετικά για
την βελτίωση του Linux, όπως άλλα παρόμοια [benchmarks του παρελθόντος](http://members.tripod.com/~e_l_green/mindcraft.html). Το πρόβλημα της δικτύωσης ήταν ήδη
γνωστό και διορθωνεται πρόχειρα στη τρέχουσα σειρά σταθερών πυρήνων (2.2.x), αλλά και αποφασιστικά στην πειραματική σειρά των πυρήνων (2.3.x). Το πρόβλημα της
συμμετρικής πολυδιεργασίας έχει αντιμετωπιστεί στη τρέχουσα σειρά σταθερών πυρήνων και σε άκρως ικανοποιητικό βαθμό στις εκδόσεις μετά την 2.2.10 (
<http://www.kegel.com/mindcraft_redux.html>, <http://www.cpureview.com/art_smp_f.html> και <http://linuxtoday.com/stories/10091.html>). Στην επόμενη σειρά
σταθερών πυρήνων (2.4.x), η οποία θα κυκλοφορίσει μέχρι το τέλος του τρέχοντος έτους, θα περιλαμβάνονται αρκετές ακόμη βελτιώσεις και προσθήκες.
Ποιά είναι λοιπόν τα συμπεράσματα;
Μέχρι να εμφανιστεί η επόμενη σειρά σταθερών πυρήνων και πρίν απο την κυκλοφορία των Windows 2000 (των μέχρι πρόσφατα αποκαλούμενων Windows NT 5.0), το Linux θα
υστερεί σε σχέση με τα Windows NT στο συγκεκριμμένο και εξωπραγματικό μηχάνημα που κοστίζει εκπληκτικά πολύ.
Είναι παραδεκτό ο,τι πιο συμφέρουσα και από άποψη απόδοσης, αλλά και από άποψη τιμής είναι μια λύση που συνίσταται σε ένα σύνολο σημαντικά φθηνότερων
δικτυομένων μηχανημάτων, τα οποία επωμίζονται εξίσου τον φόρτο εργασίας (computer farm). Με το ίδιο κόστος τη θέση του εξωπραγματικού αυτού μηχανήματος θα
μπορούσαν να αναλάβουν 20 συνηθισμένα μηχανήματα. Στη περίπτωση βλάβης ή αναβάθμισης του εξωπραγματικού μηχανήματος θα παρουσιάζονταν διακοπή παροχής
υπηρεσειών, ενώ αντίθετα στη περίπτωση ενός μηχανήματος από ένα σύνολο, τα άλλα θα συνέχιζαν κανονικά.
Επιπλέον, τέσσερεις κάρτες δικτύου των 100 MBits αποδίδουν συνολικά 400 MBits. Τα περισσότερα τοπικά δίκτυα (Local Area Networks - LANs) περιορίζονται σε έναν
δίαυλο των 100 ή 10 Mbits (Fast ή απλό Ethernet), οι περισσότεροι παροχείς υπηρεσιών Διαδικτύου (Internet Services Providers - ISPs) περιορίζονται σε λιγότερα
από 2 MBits (συνήθως E1/T1 1,544 MBits), οι επικοινωνίες μέσω του ψηφιακού δικτύου υπηρεσιών (Intergraded Services Digital Network - ISDN) περιορίζονται σε
0,128 ή 0,064 MBits (128 και 64 KBit αντίστοιχα) και τα τηλεφωνικά modems, των οποίων η ταχύτητα αποκλείεται να αυξηθεί λόγω των περιρισμών που επιβάλει το
τηλεφωνικό δίκτυο, περιορίζονται σε περίπου 0,0576 MBits (57,6 KBits που αντιστοιχούν σε περίπου 57,6 Kbps).
Στα παραπάνω πρέπει να προστεθεί ο,τι η συστοιχία δίσκων του μηχανήματος ήταν τύπου 0 (RAID 0), η οποία δίνει ιδιαίτερη έμφαση στη ταχύτητα και όχι στη
αξιοπιστία. Σε ένα επιχειρισιακό περιβάλλον προτεραιότητα έχει η αξιοπιστία και όχι η ταχύτητα και για αυτόν τον λόγο πιθανότατα θα χρησιμοποιούταν συστοιχία
δίσκων είτε τύπου 5 (RAID 5) είτε συνδιασμός τύπων 0 και 5 (RAID 0,5).
Στα παραπάνω πρέπει να προστεθεί οτι σε ένα επιχειρισιακό περιβάλλον τα δεδομένα δεν είναι στατικά, δηλαδή το περιεχόμενο των ιστοσελίδων δεν είναι σταθερό και
δεδομένο εκ των προτέρων, αλλά δυναμικά, δηλαδή το περιεχόμενο συνεχώς αλλάζει και είναι μέλημα του εξυπηρετητή - πιθανότατα με τη βοήθεια μιας γλώσσας δέσμης
εντολών (batch ή scripting language) - να αντλεί τα δεδομένα από μια βάση δεδομένων (database) ή να τα συλλέγει άμεσα από τις εκάστοτε πηγές, να τα μετατρέπει
και να τα παρουσιάζει ανάλογα, σαν ιστοσελίδες ή εικόνες. Η επιδόσεις του Apache είναι μέτριες σε στατικά και εκπληκτικές σε δυναμικά δεδομένα. Συνεπώς, δεν θα
έπρεπε να χρησιμοποποιηθεί ο Apache στα Mindcraft Benchmarks, αλλά κάποιος άλλος εξυπηρετητής, όπως ο ZHTTPd.
Οι συνεργάτες του γερμανικού περιοδικού c\'t αντιλαμβάνόμενοι κάποια από τα παραπάνω διεξήγαγαν μία [παρόμοια
μελέτη](http://www.heise.de/ct/english//99/13/186-1/).
Σύμφωνα με τη μελέτη αυτή, το Linux αποδείχθηκε κατάτι ταχύτερο στον τομέα εξυπηρέτησης στατικών και κατά πολύ ταχύτερο στον τομέα εξυπηρέτησης δυναμικών
δεδομένων από τα Windows NT. Το λογισμικό για το Linux ο Apache 1.3.6 και για τα Windows NT αποτελούσαν ο Microsoft Internet Information Server 4.0.
Πάλι το υλικό ήταν κοινό, ένας εξυπηρετητής της Siemens, ο Primergy 870, ο οποίος διαθέτει τέσσερεις επεξεργαστές Pentium II Xeon 450MHz, 512 ΚByte Cache, 2
GBytes RAM, σε συστοιχία τέσσερεις σκληρούς δίσκους και δύο κάρτες δικτύου Ethernet 100 MBit και ο οποίος κοστίζει 100.000,- DM.
Αρχικά στο μηχάνημα ήταν προεγκατεστημένα τα Windows NT 4.0 αναβαθμισμένα με το Service Pack 3 και το SuSE Linux 6.1 (έκδοση πυρήνα 2.2.5). Τα πρώτα
αποτελέσματα ήταν αποκαρδιωτικά, ειδικά για το Linux, και έτσι και τα δύο λειτουργικά συστήματα αναβαθμίστηκαν εκ νέου. Τα Windows NT με το Service Pack 4 και
το Linux στον πυρήνα 2.2.9.
Η μελέτη του εν λόγω περιοδικού δεν είναι μόνο ανατρεπτική, αλλά αποκαλύπτει την ταχύτητα με την οποία εξελίσεται και βελτιώνεται ο πυρήνας του Linux. Η
Mindcraft χρησιμοποίησε την έκδοση 2.2.2 και όταν το c\'t αντίκρισε την έκδοση 2.2.5 την βρήκε εξαιρετικά αργή και έτσι χρησιμοποίησε την 2.2.9. Οι τρεις
εκδόσεις διαφέρουν μεταξύ τους μόνο ως προς το τρίτο δεκαδικό ψηφίο και το μέγιστο διάστημα που μεσολάβησε ανάμεσα στην εμφάνιση τους δεν υπερβαίνει τον μήνα
(!). Δεν υφίσταται σύγκριση με άλλα προγράμματα (και όχι αποκλειστικά με άλλα λειτουργικά συστήματα) τα οποία διατίθενται χωρίς τον πηγαίο κώδικα (closed
source), τα οποία συχνά κοστίζουν υπερβολικά, των οποίων αργούν να κυκλοφορήσουν οι νέες εκδόσεις και όταν κυκλοφορούν είναι σχεδόν ίδιες με τις προηγούμενες.
Επιπλέον, η Mindcraft παρέληψε τη σύγκριση στους τομείς της διαθεσιμότητας, της ασφάλειας, της αξιοπιστίας, της σταθερότητας, της επεκτασιμότητας και του
κόστους, [τομείς στους οποίους τα Windows NT υστερούν](http://www.zdnet.com/sr/stories/news/0,4538,2309474,00.html). Το Linux και ειδικά οι εφαρμογές του,
πολλές από τις οποίες προηγήθηκαν του ίδιου, είναι διαθέσιμες για πολλές πλατφόρμες, δοκιμάστηκαν εξαντλητικά και κάθε φορά όταν εντοπίζεται ένα πρόβλημα, μια
παράλειψη, μια δυσλειτουργία, αμέσως διορθώνεται, παρακάμπτεται, \"μπαλώνεται\", από τους ίδιους τους προγραμματιστές ή και από τους χρήστες και είναι απολύτως
δωρεάν για απεριόριστο αριθμό χρηστών και μηχανημάτων. Κάτι τέτοιο είναι δυνατό επειδή οι προγραμματιστές είναι γνωστοί και άμεσα προσιτοι από τους χρήστες,
αλλά και επειδή ο πηγαίος κώδικας είναι διαθέσιμος.
Μετά την παράθεση όλων αυτών των λόγιων επιχειρημάτων θα έπρεπε (ευχαριστημένος) να τελειώσω συνοψίζοντας. Όμως, αλίμονο, δε φθάνει, απλώς, να διαφωτίσω
κάποιους από τους αναγνώστες για αυτήν την μελέτη και για αυτά τα αποτελέσματα, θα πρέπει να τους προετοιμάσω για τα μελλούμενα.
Η Microsoft, η IBM, ο προκάτοχος της στην κυριαρχία του χώρου της πληροφορικής, και κάθε άλλη μεγάλη εταιρία μεταχειρίζεται με ιδιαίτερη δεξιοτεχνία τα μέσα
μαζικής ενημέρωσης για να πετύχει του σκοπούς της. Στη περίπτωση των Mindcraft Benchmarks διέδωσε φόβο, αβεβαιότητα και αμφιβολία (Fear, Uncertainty and Doubt -
FUD). Επιχείρησε να προβάλει την κατωτερότητα του Linux έναντι των Windows NT βασιζόμενη σε ένα μόνο πρόβλημα του Linux το οποίο παρουσιαζόταν σε εξαιρετικά
απίθανες περιπτώσεις. Και τα κατάφερε. Η Mindcraft μεταχειρίστηκε για χάρη της Microsoft, του εργοδότη της, [κάθε διαθέσιμη μέθοδο
FUD](http://linuxtoday.com/stories/7972.html).
Για παράδειγμα τα Benchmarks δεν είχαν καμμία σχέση με τα γενικευμένα πορίσματα, τα οποία δεν ίσχυουν παρά μόνο για μηχανήματα με περισσότερες από δύο δικτυακές
συνδέσεις των 100 MBits.
Αγνοήθηκαν τυχόν άλλοι ανταγωνιστές των Windows NT, όπως τα παρόμοια με το Linux, δωρεάν Unices, δηλαδή τα FreeBSD, OpenBSD και NetBSD, τα οποία είχαν καλύτερη
δικτυακή συμπεριφορά, στο παρελθόν τουλάχιστον ( <http://www.daemonnews.org/199908/d-advocate.html>).
Συμπερασματικά, το Linux, παρά τα πρόσφατα αρνητικά αποτελέσματα, παραμένει μια εξαίσια επιλογή και στην συντριπτική πλειονότητα των περιπτώσεων παραμένει μια
επιλογή καλύτερη από τα Windows NT. Έχει ανακτήσει το χαμένο έδαφος και σύντομα θα ξεπεράσει τα Windows NT σε κάθε τομέα. [Αυτό το γνωρίζει η
Microsoft](http://www.opensource.org/halloween/) και για αυτό διαδίδει FUD. Όμως, το FUD δεν αντέχει σε μια προσεκτικότερη ματία.
Προσέξτε τι \... FUD σας ταϊζουνε!