Αναζήτηση:

Πριν απο λιγο διαβαζα οτι παει για Q3 2012 το τελικο release. Αρα λογικα το beta stage κλπ, ισως αργησει λιγο ακομα.

Ως διευκρινιση, δεν "παει" για Q3 2012 το τελικο release. Οπως εχει συζητηθει και παλαιοτερα εδω στο forum, αντιθετα με τις προβλεψεις διαφορων ...μαντειων του web που μιλουσαν για εξωφρενικα πραγματα του τυπου "RTM μεσα στο 2011" και αλλα τετοια φαιδρα, το 2012.Q3 ηταν εξ' αρχης το release scheduled date το οποιο και μεχρι στιγμης δεν εχει διαφοροποιηθει στο παραμικρο. Σε καθε περιπτωση δεσμευτικο timeframe δεν υπαρχει μεχρις οτου υπαρξει επισημη ανακοινωση.

Οσο για το επισημο beta stage, υπομονη μεχρι τον ερχομενο Οκτωβριο. :)

Υπεροχα, φτιαχνουν οι μηχανικοι τα νεα πραγματα και μετα πιανουν την κουβεντα με το νομικο τμημα ωστε να μην του κυνηγανε τα νομικα ζομπυ.
Θα ηταν εντιμοτερο, οικονομικοτερο για τους ιδιους και σαφως χρησιμοτερο για την περαιτερω εξελιξη της βιομηχανιας και της αγορας, αν αντι αυθαιρετα να χρησιμοποιουν προιοντα εργασιας αλλων εταιρειων, ειτε σχεδιαζαν οι ιδιοι πρωτογενως δικα τους, ειτε αποκτουσαν νομιμως αδεια χρησης των συγκεκριμενων, ειτε εστω αν υιοθετουσαν καποια απο τα υπαρχοντα εναλλακτικα ελευθερης χρησης.

Εννοεις την πατεντα που ανηκει στο Stanford γιατι ο Larry Page (Chief Executive Officer and Co-Founder of Google Inc.) εκανε την διατριβη του εκει?
Δεν ειναι μονο η πατεντα του Stanford φιλε c4lex αλλα και οι εκατονταδες αλλες πατεντες που δικαιωματικα ανηκουν στην Google. Και για να ειμαι ειλικρινης, αντιθετα με τις αποψεις του ευρυτερου "κοινωνικου" ρευματος δεν βρισκω κατι μεμπτο σε αυτες. Ανοητες οι πατεντες σε πρωτη αναγνωση, σιγουρα ναι, οπως αλλωστε και οι περισσοτερες δικαιοπρακτικες νομολογιες οταν ερμηνευονται επιδερμικα.

Περαν ομως της πρωτης αναγνωσης και της απλοικης ερμηνιας που εμεις δινουμε, μια ολοκληρη underground βιομηχανια παραποιησης και λαθροχρησιας, συχνα υποστηριζομενη απο κρατικα, πολιτικα και φυσικα οικονομικα συμφεροντα, παραφυλαει σε καθε βημα τον εκαστοτε δημιουργο, καθιστωντας αυτες τις πατεντες απαραιτητες στο να καλυψουν τα νομικα κενα που αφηνει το δικαιο των copyrights.

Σιγουρα δεν αναφερομαι σε δικομανεις κερδοσκοπους οι οποιοι οπως καποιος φιλος πολυ σωστα προαναφερε, το μονο που κατασκευαζουν ειναι απιθανες και τις περισσοτερες φορες ανυπαρκτων προιοντων πατεντες με σκοπο την πιθανη μελλοντικα εκβιαστικη εκμεταλευση τους. Αλλο ομως αυτο, και αλλο το να χρησιμοποιει καποια κερδοσκοπικη εταιρεια για παραδειγμα το FAT file system, το οποιο ειναι εμπορικα διαθεσιμο προιον προς licensing απο τριτους, να το χρησιμοποιει λοιπον εντελως αυθαιρετα μη θελοντας να πληρωσει τη νομιμη χρηση του η εστω να την αποφυγει εντελως διαλεγοντας ενα απο τα πολλα εναλλακτικα και συχνα δωρεαν file systems.

Και σε καμια περιπτωση δεν αναφερομαι ειδικα στην Microsoft. Την ιδια αποψη εχω και για τις πατεντες της Google, η της οποιασδηποτε αλλης δημιουργου εταιρειας. Αλλα δυστυχως, οπως παντοτε και παντου ισχυει ενας κανονας. Οι πατεντες ειναι το "μεγαλο κακο" γι'αυτον που δεν τις εχει αλλα γινονται "απαραιτητο ασφαλιστικο μετρο" μολις ο ιδιος εχει λογο για τον οποιο μπορει να τις αποκτησει.

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

Το ribbon δεν ειναι της microsoft, το εξαγορασε απο αλλη εταιρεια.
Αν και πιστευω πως ελαχιστους ενδιαφερουν τετοιες λεπτομερειες, ωστοσο απλως ενημερωτικα θα μου επιτρεψεις αγαπητε φιλε Thuglife μια διορθωση.

Το ribbon interface οχι μονο δεν αγοραστηκε απο καποιον τριτο, αλλα αντιθετα ως επιμερους ενος συνολικοτερου user interface reconstruction του Office, σχεδιαστηκε εξ'ολοκληρου απο την ομαδα των Julie Larson-Green (MS CVP - Windows Experience) και Jensen Harris, τοτε program managers του Microsoft User Experience Team στους οποιους ειχε ανατεθει απο το 2002 η αναβαθμιση του MS Office UI.

Να υποθεσω λοιπον πως μιλωντας για "εξαγορα" μαλλον αναφεροσουν στο MFC Feature Pack ribbon control (BCGSoft) που μαζι με αλλα πολλα UI controls διενειμε αρχικα η Microsoft στους χρηστες MFC που ηθελαν να προσθεσουν αμεσα ribbon interface στα projects τους αλλα δεν επιθυμουσαν να "βρεξουν το ποδια τους" στα inners του Fluent UI SDK και του native ribbon. Αλλο ομως ενα δωρο third party ribbon-emulation component και αλλο το ποιος δημιουργησε το ribbon.

Αυτα, και συγχωρηστε μου την offtopic παρεμβαση.

Δεν ξερω γιατι αλλα η εκκαθαριση των Windows δεν καθαριζει τα αρχεια απο το C:\users\username\AppData\Local\Temp
και δεν μπορεσα να βρω μια ρυθμιση για να το κανω.

Ο λογος ειναι πως αντιθετα με τα διαφορα thirdparty cleaners, το cleanmgr των Windows οφειλει οχι μονο να ελεγχει τι τυπου αρχεια (η directories) επιλεγει να διαγραψει, αλλα ταυτοχρονα και ποτε αυτα εχουν δημιουργηθει. Ετσι για παραδειγμα, το ccleaner (η οποιο αλλο) θεωρει οτιδηποτε βρισκεται στο system και στο user temp folder ως "αχρηστο". Ο μονος τροπος να γλυτωσει καποιο αρχειο την διαγραφη ειναι αυτα που ειναι ηδη locked απο καποιο running process.

Τι γινεται ομως με τα installation και τα hotfix temporary files, με τα pending actions files και ολα αυτα τα αρχεια που βρισκονται μεν σε temp - cache folders αλλα οχι απλα δεν ειναι "αχρηστα" αλλα ειναι απαραιτητα στο επομενο system boot? Τι θα γινει οταν για παραδειγμα ενα hotfix η ενα running (de)installation εχει pending copies σε αναμονη στο system temp folder και εν τω μεταξυ ο χρηστης τρεξει το cleaner του και τα διαγραψει;

Τι προκειται να γινει παλι οταν profiler temp logs του %windir%\temp διαγραφουν αφθαιρετα πριν το profiling ολοκληρωσει τον κυκλο των δυο, τριων η και περισσοτερων startups κατα την εγκατασταση device filters? Η πως προκειται το WU background intelligent transfer service να αντιδρασει αν δεν βρει τα distribution temp caches στην φαση των delayed hotfixes?

Ολα αυτα (και πολλα ακομα) οδηγησαν στην χρηση παραμετρικων disk cleanup handlers που χρησιμοποιει ο disk clean manager του συστηματος (cleanmgr). Μπορει καποιος ευκολα να δει τις δηλωσεις των default volume caches cleanup handlers μεσα στην registry και συγκεκριμενα στο key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches

Το καθε subkey κατω απο το παραπανω εχει ως ονομασια την αντιστοιχη cleanup κατηγορια του cleanmgr και περιεχει ενα πληθος απο values που οριζουν την συμπεριφορα του εκαστοτε handler, οσον αφορα για παραδειγμα το disk directory (η
CSIDL pointer), τους τυπους των αρχειων που μπορει να διαγραφουν, την περιγραφη τους, καθως και εναν μεγαλο αριθμο flags που οριζουν το ποτε η μετα την παρελευση ποσου χρονου μπορουν να θεωρηθουν τα συγκεκριμενα αρχεια ως ασφαλη για διαγραφη.

Για παραδειγμα κατω απο το key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches βρισκουμε το subkey Temporary Files μεσα στο οποιο βρισκονται οι παρακατω τιμες.

1. @="{C0E13E61-0CC6-11d1-BBB6-0060978B2AE6}"
2. "PropertyBag"="{60F6E465-4DEF-11d2-B2D9-00C04F8EEC8C}"
3. "Flags"=dword:00000041
4. "Folder"=hex(2):25,00,54,00,45,00,4d,00,50,00,25,00,00,00
5. "LastAccess"=dword:00000007
6. "FileList"="*.*"
7. "StateFlags0000"=dword:00000002
8. "StateFlags"=dword:00000001

Στο συγκεκριμενο παραδειγμα, εκτος του αναγνωριστικου CSIDL του system temp folder, υπαρχει επισης το file mask των αρχειων που προκειται να διαγραφουν (FileList="*.*"), το bitOR value "Flags" που αποτελειται απο bit flags τα οποια περιεχουν οδηγιες οπως το αν θα διαγραφουν system files, readonly files, recursive subdirectories, καθως και το αν ο εν λογω cleanup handler θα τρεξει μια φορα, η θα τρεχει σε καθε εκτελεση του cleanmgr. Περιεχονται ακομα flags οπως της εκκαθαρισης των parent directories, καθως και flags που αντιστρεφουν (opt-in/out) την λειτουργια του καθε handler.

Ενα πολυ σημαντικο reg value ειναι αυτο στη σειρα 5 στο παραπανω παραδειγμα. Αυτο φερει την χαρακτηριστικη ονομασια "LastAccess" και περιεχει μια αριθμητικη τιμη (7 στο παραδειγμα) που ειναι ο αριθμος των ημερων που πρεπει να εχουν παρελθει απο τοτε που χρησιμοποιηθηκαν τελευταια φορα τα συγκεκριμενα αρχεια, ωστε να θεωρηθουν ασφαλη πλεον για διαγραφη απο τον cleanmgr.

Με απλα λογια, στο συγκεκριμενο παραδειγμα, αν δεν περασουν 7 ημερες απο την τελευταια προσπελαση καποιων εκ των temporary files (η folders) αυτα θα παραβλεπονται απο τον disk cleanup manager, με αποτελεσμα να δινεται η εντυπωση στον χρηστη πως το cleanmgr δεν μπορει να τα διαγραψει. Μπορει, αλλα οπως βλεπεις το συστημα εχει φτιαχτει και ρυθμιστει ετσι ωστε να μην κινδυνευει να υποπεσει σε βιαστικη και συνεπως ανασφαλη διαγραφη χρησιμων ακομα προσωρινων αρχειων. Εννοειται βεβαια πως μετα την παρελευση των 7 ημερων (παντοτε στο συγκεκριμενο παραδειγμα), εαν τα αρχεια δεν εχουν προσπελαστει προσφατα θα διαγραφουν στην επομενη εκτελεση του cleanmgr.

Ολα τα παραπανω δεν ειναι παρα ενα ελαχιστο δειγμα των παραμετρικων δυνατοτητων των volumecache cleanup handlers. Στην πραγματικοτητα, υπαρχει προρυθμισμενος ενας μεγαλος αριθμος τετοιων system handlers, οι οποιοι οχι απλα μπορουν να επαναρυθμιστουν (μεσω admin scripting, system policies, templates και registry), αλλα εξισου ευκολα ειναι δυνατον να προστεθουν στο συστημα νεοι (user configurable) για διαφορετικα system η user disk caches.

Τελειωνοντας να προσθεσω, πως ναι ειναι ευκολο για παραδειγμα στα system tempdir (οπως το παραπανω παραδειγμα), να αλλαξουμε μεσω registry το LastAccess value απο 7 σε 1 η και μηδεν, με αποτελεσμα ολα τα περιεχομενα στο directory αρχεια να θεωρουνται safe-to-remove συνεπως διαγραψιμα απο την πρωτη στιγμη. Καποιος θα μπορουσε ακομα και να ενεργοποιησει το recursive flags σβηνονται και ολα τα nested (η και parent) folders.

Σε καμια ομως περιπτωση κατι τετοιο δεν ειναι η ενδεδειγμενη πρακτικη για τον μεσο χρηστη, καθως εγκυμονουν ολοι οι προαναφερθεντες κινδυνοι, οι οποιοι με μαθηματικη ακριβεια θα οδηγησουν αργα η γρηγορα σε προβληματα. Προυποθεσεις, ενδεχομενα προβληματα, κινδυνοι και MS guidelines που δυστυχως αλλα δηθεν "καλυτερα" third party tools (π.χ. ccleaner), δεν λαμβανουν καθολου υποψιν σβηνοντας οτι βρισκουν μπροστα τους, αδιαφορωντας για τις συνεπειες και φυσικα συχνα με τα γνωστα δυσαρεστα αποτελεσματα.

Ελπιζω να ημουν αρκετα σαφης... :)

...γιατι το προγραμμα defrag στα windows 7 δεν ειναι οπως ηταν στα ΧΡ και δεν εχει το χρωματιστο πινακα να βλεπεις την διαδικασια
Υπαρχουν αρκετοι λογοι αυτης της επιλογης, με σημαντικοτερο το γεγονος πως οι αλγοριθμοι υπολογισμου και επανασχεδιασης του fragments map ειναι χρονικα και υπολογιστικα "βαρυτεροι" και "αργοτεροι" ακομα και αυτου του ουσιαστικου defragmentation process, χωρις ταυτοχρονα να προσφερει τιποτα το πρακτικα χρησιμο.

Χωρις παρεξηγηση, ομως γιατι τοτε αυτες οι εταιρειες λογισμικου, συγκεκριμενα, οι εμπορικες, ειναι Golden Partners με την MS?

Το Gold partnership δεν σημαινει τιποτα περισσοτερο απο το οτι οι εν λογω εταιρειες κατοπιν επιθυμιας τους συμμετεχουν ως certified members στο MS Partners program, ως επι πληρωμη συνδρομητες στις υπηρεσιες του (MSDN, TechNet κλπ), και ως επαγγελματιες η εταιρειες που χρησιμοποιουν και προωθουν προιοντα της Microsoft.

Ενημερωτικα, gold η certified partner μπορει να γινει οποιοσδηποτε ιδιωτης, ελευθερος επαγγελματιας η εταιρεια παρεχει η χρησιμοποιει MS-based υπηρεσιες και προιοντα. Αυτο σε καμμια απολυτως περιπτωση δεν σημαινει πως η Microsoft γνωριζει, εγκρινει η αποριπτει το εκαστοτε προιον η υπηρεσια που παρεχει ο καθε partner. Οπως σε καθε τομεα της καταναλωτικης βιομηχανιας, ο μονος υπευθυνος της επιλογης των καταλληλων εργαλειων τριτου κατασκευαστη, η της αποριψης των ακαταλληλων, ειναι ο τελικος χρηστης και αγοραστης τους.

Τελος δεν θα πρεπει ποτε να ξεχνουμε, πως ακομα και το πλεον χρησιμο software tool μπορει να αποβει επικινδυνο η ακομα και μοιραιο για το συστημα, αν ο χρηστης του δεν γνωριζει πως, ποτε και υπο ποιες προυποθεσεις το χρησιμοποιει. Ακομα και bundled system utilities οπως το ιδιο το registry editor, τα διαφορα CLI tools, ακομα και αυτος ο windows explorer μπορει στα χερια ενος αδαους χρηστη να γινουν εργαλεια "καταστροφης" του συστηματος του.

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


Αληθευει οτι θα υπαρξει τεστ preview η beta εκδοση τον Σεπτεμβριο;
Θα υπαρξει και νωριτερα ακομα, αν και οπως ξαναειπα δεν θα ειναι feature locked. Υπαρχουν πολλα επιμερους ακομα να υλοποιηθουν η να ολοκληρωθουν πριν τελικως ενσωματωθουν σε καποιο tech preview η public beta.

To διαβασα σαν νεο για τα 8αρια αλλα αργοτερα η Microsoft εβγαλε ανακοινωση που δια ψευδει τον Ballmer. Αντιγραφω απο εδω
Η επισημη Microsoft λεει οτι η δηλωση του Ballmer δεν ειναι αυτη που ακουστηκε
Δεν υπαρχει λογος να αναλισκομαστε σε ανακοινωσεις, διαψευσεις και φημολογιες. Οπως εχει ειπωθει αρκετες φορες μεχρι σημερα, το μεχρι στιγμης επισημο schedule των Windows 8 προβλεπει, παντοτε εκτος απροοπτου, RTM των Windows 8 το Φθινοπωρο του 2012, εναρξη προπωλησεων μερικες εβδομαδες αργοτερα, και self stock τελη του 2012 αρχες 2013. Και παλι ομως, ειναι ακομη πολυ νωρις για απολυτα χρονοδιαγραμματα.

...συμφωνω με την αποψη του SSB - που εχει και καιρο να γραψει - ...
Αν και οχι τοσο συχνα, ωστοσο στον ελευθερο χρονο μου επισκεπτομαι το forum φιλε μου hellenicsun, διαβαζω τα ενδιαφεροντα νεα posts, και ενιοτε απαντω οταν βεβαια υπαρχει καποιο σχετικο θεμα. :)

δλδ με λιγα λογια να μην χρησιμοποιω το ccleaner??
Απο τη στιγμη που υπαρχει το cleanmgr του συστηματος που γνωριζει πολυ καλυτερα απο το οποιοδηποτε cleaner τι αρχεια μπορει να διαγραψει με ασφαλεια και ποτε, δεν υπαρχει λογος αγαπητε φιλε dava για καποιο third party utility. Ειδικα μαλιστα οταν εκτος των temporary files, τετοια utilitites παρεμβαινουν στα registry keys διαγραφοντας η τροποποιωντας αυτα που "θεωρουν" ως περιττα.

Εκει βλεπεις μπαινει ο ασταθμητος παραγοντας το κατα ποσον αυτα που "θεωρουν" τετοιες εφαρμογες ως περιττα ειναι οντως και στην πραγματικοτητα. Και πιστεψε με, στην συντριπτικη πλειοψηφια των περιπτωσεων δεν ειναι, με αποτελεσμα η συχνα αυθαιρετη διαγραφη η τροποποιηση τους να εχει ιδιαιτερα δυσαρεστες μετεπειτα συνεπειες για το συστημα και την σταθεροτητα του. Και για να μην επαναλαμβανομαι, αν θελεις μπορεις να ριξεις μια ματια σε παλαιοτερες σχετικες συζητησεις μου με φιλους εδω στο forum, οπου αναλυεται διεξοδικοτερα και με τεχνικες λεπτομερειες το πως ακριβως λειτουργουν τετοιες εφαρμογες και το κατα ποσο επικινδυνες τελικως ειναι.

Αναφορικα με την ακριβεια και την αξιοπιστια των ειδησεων φιλε μου PiXel, νομιζω πως ειναι περιττο να επαναλαβω την αποψη μου σχετικα με την αξιπιστια της συντριπτικης πλειοψηφιας των γραφομενων στο web...

Οσο για την "beta φαση" των w8, οχι δεν αρχισε ακομη ουτε και αναμενεται να αρχισει στο αμεσως προσεχες διαστημα. Δεν θα μπορουσε αλλωστε καθως το μεγαλυτερο μερος των επιμερους υποσυστηματων οχι απλως ειναι σε alpha stage αλλα απεχει πολυ απο το feature lock milepost το οποιο και επισημως αποτελει την απαρχη του beta phase.

Το οτι οι ομαδες ειναι σε ολο τον κοσμο, αφου το λες κι εσυ, ειναι λαθος, αλλα πιθανον μπερδευτηκα απο ονομασιες οπως "x86fre", νομιζοντας πως το "fre" παει στο "French"... Δυστυχως δε μπορω να βρω το αρθρο...
Σχετικα με το οτι καποια build numbers υπερπηδουνται, αυτο προφανως δε το ειπα απο την αποψη του οτι γινεται πανακεια, αλλα οτι εαν η συγγραφη της Beta ολοκληρωθει στην π.χ. 8091, η Beta θα ειναι Build 8100, για προφανεις λογους. Αλλωστε, δε μπορω να εξηγησω στην περιπτωση των 7 -εαν δεν παραλειπονται αριθμοι- πως η Beta, η RC και η RTM "συνεπεσαν" στην 7000, 7100 και 7600
Φιλε μου PiXel, η συντριπτικη πλειοψηφια θετικων η αρνητικων αρθρων η δημοσιευματων αναφορικα με την Microsoft (και πληθος αλλων εταιρειων), τις εσωτερικες δομες οργανωσης, την πορεια της αναπτυξης των προιοντων, τα μελλοντικα τεχνικα τους χαρακτηριστικα κλπ, δεν ειναι τιποτα αλλο παρα ανοητα αποκυηματα της ζωηρης φαντασιας καποιων εκ των πολλων ψευδοπροφητων και δημοσιογραφισκων του web.

Τωρα σχετικα με τα build suffixes, το FRE σιγουρα σε καμμια περιπτωση δεν σημαινει "French". Εντος MS χρησιμοποιουνται διαφορετικα suffix που δηλωνουν την φυση και το targeting καθε build. Ετσι για παραδειγμα υπαρχει το CHK που σημαινει "Checked" και χαρακτηριζει builds με debug code & symbols απευθυνομενα σε developers η programmers - beta testers, υπαρχει το CCK που αναφερεται στα cross-linked builds (για testing σε ανομοιογενη architectures), το FRE (Free) που δηλωνει stripped (free of dbg code) builds, και καποια αλλα λιγοτερο γνωστα εσωτερικης κυριως χρησης οπως PNT, RBK κλπ.

Τελος οσον αφορα το build numbering, η συνηθως (γιατι υπαρχουν πολλες εξαιρεσεις) "λογικη" αριθμηση συγκεκριμενων milestones οπως των RC, RTM κλπ δεν ειναι κατι τυχαιο, ουτε ομως αποτελει αυστηρα ζητουμενο που θα οδηγουσε σε παραλειψη ενδιαμεσων. Χωρις να υπεισελθω σε βαρετες λεπτομερειες του εξαιρετικα πολυπλοκου versioning strategy, καποια στιγμη στην φαση ολοκληρωσης ενος σταδιου αναπτυξης και ελλειψει show-stopper reports της τελευταιας στιγμης, κλειδωνει οριστικα το source point (η εκδοση του source tree που θα χρησιμοποιηθει στο συγκεκριμενο release).

Απο αυτη τη στιγμη και καθως πλεον δεν ενσωματωνονται οι οποιες αλλαγες συνεχιζουν να γινονται στο source tree, ο αριθμος των προ public release testing builds μπορει να προαποφασιστει και ισως (ξαναλεω "ισως", διοτι δεν υπαρχει καποιος κανονας) ισως λοιπον να κλειδωσει ο μεγιστος αριθμος τους στην πλησιεστερη δεκαδα η εκατονταδα. Σε αυτη την φαση κατι τετοιο ειναι δυνατον, διοτι ζητουμενο πλεον απο τα συγκεκριμενα ακολουθα builds δεν ειναι η runtime δοκιμασια αλλα η ολοκληρωμενη δοκιμη καθως και οι επιμερους διορθωσεις και ο ελεγχος του release strategy. Και παλι ομως το κλειδωμα του μεγιστου αριθμου δεν σημαινει σε καμμια περιπτωση πως θα υπαρξει παραλλειψη των ενδιαμεσων, εστω και αν σε αυτα το μονο που ενδεχομενως αλλαζει να ειναι καποια licence typos, η η προσθηκη καποιων release addendums.

Θα υπαρξουν σημαντικες εμφανεις αλλαγες στο UI τοσο πριν τα πρωτα official betas οσο και μετα. Οπως ειχε συζητηθει εδω στο topic πολυ πριν κυκλοφορησουν τα πρωτα leaks, ο σημαντικοτερος λογος των περιορισμενων οπτικων (και οχι μονο) αλλαγων στα πρωτα σταδια, ειναι πως αντιθετα με παλαιοτερες εκδοσεις του συστηματος, μεγαλο μερος του απαιτουμενου foundation underlay επανεγγραφεται και δεν εχει ακομα ολοκληρωθει. Γι'αυτο και ειχα πει τοτε πως ειναι εξαιρετικα νωρις να ασχοληθει καποιος με τα πρωτα test previews.

Τωρα σχετικα με το ποτε ακριβως θα ενσωματωθουν οι εσωτερικες, κατα συνεπεια και οι εμφανεις αλλαγες, αυτο κανεις δεν μπορει να το πει στην παρουσα φαση. Οντας πρακτικα σε alpha-stage και με ανοιχτο το χρονικο οριζοντα του CTP, καταλαβαινεις πως ειναι πολυ νωρις. Αυτο που μπορω εστω προς ωρας να πω ειναι πως περαν των λειτουργικων αλλαγων στο UI που επονται, ουτε καν το theme δεν εχει ακομα αποφασιστει (ναι δεν θα ειναι ιδιο) καθως ακομα και αυτο εξαρταται αμεσα απο την πορεια αναπτυξης του graphics layer αλλα και απο επιμερους υποσυστηματα (οπως WMP, WMC) και τα οποια "παραδοσιακα" αποτελουν το UI concept στην διαρκεια της αναπτυξης.

Υπομονη λοιπον, εχουμε δρομο ακομα... :)

Απ' ο,τι εχω διαβασει, εχουν χωρισει διαφορα στοιχεια σε ομαδες και αυτες τα αναπτυσσουν παραλληλα ωστε να τελειωνουν πιο γρηγορα. Μονο η Winmain ομως (η κυρια ομαδα των Windows), κανει compile σε builds τα οποια εχουν συγκεντρωμενα ολα τα χαρακτηριστικα.
Με την αδεια σου αγαπητε μου φιλε, και απλα για ακαδημαικα ενημερωτικους λογους, θα μου επιτρεψεις να πω πως αυτα που εχεις διαβασει ειναι περα για περα λαθος. Κανενα ανεξαιρετως μερος του Windows source tree δεν αναπτυσεται εκτος Redmond. Ακομα και adopted projects της Microsoft Research (η οποια ειναι αυτη που εχει ανα τον κοσμο research centers), χρονια πριν την ενσωματωση τους στο primary OS development "μεταφερονται" μαζι με τα teams τους στα κεντρικα της MSR.

Ο λογος που οχι μονο στην Microsoft αλλα στη πλειοψηφια των εταιρειων συμβαινει αυτο, περαν της ασφαλειας και των πρακτικων δυσκολιων ειναι διοτι εχει προ πολλου αποδειχτει στη βιομηχανια software πως διασπασμενες ομαδες αναπτυξης οδηγουνται με μαθηματικη ακριβεια σε ατελεσφορη χρονικα και οσο αφορα το project consistency, προσπαθεια, λογω πληθους διαδικαστικων και λειτουργικων δυσκολιων. Με απλα λογια, τιποτα δεν μπορει να υποκαταστησει την στενη καθημερινη συνεργασια των development teams, και την οσο το δυνατον αμεσοτερη επιλυση αναριθμητων δυσκολιων, διαφωνιων και διαφορετικων προσεγγισεων.

Τελος, επισης ενημερωτικα οσον αφορα τα build numbers, δεν υπαρχει καποια "παραδοση" εντος MS να "υπερπηδωνται" build numbers σε οποιαδηποτε φαση αναπτυξης του συστηματος. Απλα απο τα χιλιαδες tree builds μονο ελαχιστα εξ αυτων δημοσιοποιουνται εκτος Microsoft, ενω ειδικα σε προχωρημενα χρονικα σταδια αναπτυξης δεν ειναι σπανιο λογω last-minute bug submissions και test releases ο αριθμος των builds να υπερβαινει κατα πολυ τα συνηθως 1-2 ημερησιως. Και ολα αυτα διχως βεβαια να παραλειπουμε τα failed builds (για οποιαδηποτε αιτια) τα οποια ασχετα με το τι προκαλεσε την αστοχια η την μη ολοκληρωση τους, εχουν για ευνοητους λογους το δικο τους μοναδικο αυξοντα αριθμο.

Tabs στον file manager εχουμε η ακομα; Ακομα και σε linux υπαρχουν tabs, στον χειροτερο file manager.
Ποιος ο λογος αγαπητε φιλε Caret, υιοθετησης tabs στον Windows Explorer, τη στιγμη που υπαρχει η δυνατοτητα multiple combined instances (single η multi-process); Περαν απο συγκεκριμενους εγγενεις περιορισμους του tab-based interface (π.χ. tab-modality), το να εφαρμοζονται χρηστικες τεχνικες multiple document σε ενα host app ειναι κατανοητο, οταν ομως ηδη host app ειναι το ιδιο το desktop και ο explorer, δεν υπαρχει λογος επαναληψης μιας ηδη υπαρχουσας λειτουργικοτητας.

Αυτο που λες θα μπορει να γινει προφανως σε συστηματα με μικρες απαιτησεις και με ικανους επεξεργαστες συνοδευομενους με GPU στο ιδιο DIE ειτε σε embedded αρχιτεκτονικες ειτε στις γνωστες Intel/AMD x64 να φανταστω ;
Εκτος και αν η υπαρξη του WARP ακομη πιο κατω τελικα ξεκλειδωσει επιδοσεις ακομη και σε high end καρτες.

Σε ολα τα GPU παλαια η νεα, discrete η on die και φυσικα στις νεωτερες υλοποιησεις των SOC. Οσο για τις high-end καρτες τις οποιες αναφερες φιλε Μανο, στις νεωτερες απο αυτες (DX10, 10.1, 11) οι διαφορες σε επιπεδο desktop rendering αν και θα υπαρχουν θα ειναι λιγοτερο θεαματικες μια και ηδη ειναι D2DHW. Παλαιοτερα ομως GPU που μεχρι τωρα αρκουνταν στο software rendering αν και ειχαν στοιχειωδεις αλλα αδρανεις δυνατοτητες επιταχυνσης, εκει ειναι λογικο πως θα υπαρχουν ιδιαιτερα μεγαλες διαφορες αποδοσης.

Και για να μην παρερμηνευτουν τα λεγομενα μου απο καποιους φιλους, το ζητουμενο (απο μερους MS) δεν ειναι η "ακυρωση" των προσπαθειων της βιομηχανιας GPU για ταχυτερα γραφικα ειδικα στο high-end, ουτε ο καταναλωτικος χωρος του gaming. Αυτο απο το οποιο παρατηρημενα "πασχει" εδω και δεκαετιες το καθε graphics based λειτουργικο ειναι το desktop rendering. Και ενω σε επιπεδο system software εγιναν στο παρελθον πραγματικα εντυπωσιακα βηματα (απο την display postcript μεχρι το applevel DirectX κλπ) η βιομηχανια των GPU με εξαιρεση την περιπτωση του GDI δεν ακολουθησε σχεδον ποτε, επικαλουμενη παντοτε τον εντελως ανυποστατο ισχυρισμο πως το 2D εχει φτασει στα ορια του οσον αφορα τις δυνατοτητες επιταχυνσης σε επιπεδο hardware.

Δεν ειναι αλλωστε μυστικο πως απο εποχης frame buffers, απο το OSX μεχρι τα xWindows το μονο απο το οποιο επωφελειται καποιο συστημα (σε desktop-2D) ειναι απο το αυξημενο bus bw και την ταχυτητα της μνημης αλλα απο rendering με εξαιρεση τα στοιχειωδη line drawing, bitblit και memblock transfers τιποτα ιδιαιτερα περισσοτερο. Και εδω που τα λεμε, αν δεν ειχε υπαρξει η "χρυση" δεκαετια του 90 και το GDI το πιθανοτερο ειναι πως ακομα σαν απλα frame buffers θα λειτουργουσαν σε επιπεδο 2D οι καρτες γραφικων.

Ετσι λοιπον οπως προτεινει και η γνωστη παροιμια για τον "Μωαμεθ και το βουνο", εφοσον οι GPU vendors δεν δινουν σημασια παρα μονο στο 3D (ελεω gaming), ερχεται πλεον το λειτουργικο να προβαλλει το 2D desktop με οτι αυτο συμπεριλαμβανει σε 3D flat space, με το συνολο του rendering και του geometry σε επιπεδο software που στην βαση του απαιτει απο το GPU microcode μονο ενα ελαχιστο subset DX δυνατοτητων το οποιο ετσι και αλλιως ηδη υπαρχει.

Αυτο ειναι ολο με απλα λογια Μανο. Στα Windows ξεκινησε ως ιδεα με αφορμη το WPF, περασε σε καποιο βαθμο σε επιπεδο συστηματος με τη μορφη του advanced rasterization platform στα 7 και ωριμαζει ως πληρες core GX layer στα 8. Πρακτικα καποτε αυτονομες οντοτητες οπως DX, WPF κλπ ενοποιουνται ως ενα και μοναδικο GX layer με δυνατοτητες emulation (μεσω mapping) GDI αλλα και απαλλαγης απο τους εγγενεις περιορισμους που αυτο επεβαλε. Ετσι, περαν απο τα γνωστα πλεονεκτηματα, δεν θα πηγαινει "χαμενη" η πραγματικα τεραστια επεξεργαστικη ισχυς των συγχρονων GPU, αλλα εκτος του gaming θα αξιοποιειται και απο το υπολοιπο 99% της καθημερινης χρησης. Αλλωστε, ολοι μας ειδαμε τα εντυπωσιακα αποτελεσματα τοσο στο screen rendering του IE9 οσο και στο lag-free WP7, καιρος δεν ειναι Μανο να τα δουμε και στο υπολοιπο desktop; :)

και να σου απαντησω, αν και αυτο που θες να πεις αν καταλαβα χοντρικα ειναι:
Ειδαμε και αποειδαμε με τους ελλιπεις drivers μεγαλων εταιρειων (βλεπε τι τραβαμε στον IE9), τους δωσαμε τροφη στο στομα με τα 7 και δεν καταλαβαν τιποτε, οποτε αποφασισαμε να τους ξεπαστρεψουμε και να παραγουμε εμεις optimized κωδικα για παρτη τους και για τις καρτες τους:p
Σε οφελος φυσικα της επιταχυνσης ολων των λειτουργιων οσο το δυνατον απο ολο το συστημα CPU/GPU αντι μονο CPU επειδη καποιοι βαριουνται να γραψουν σωστο κωδικα. Σε πιανω ;

Αν και νυχτα, μια χαρα το επιασες το νοημα Μανο. :p

Παντως το μονο σιγουρο και οχι μονο λογω MS/w8 κλπ, ειναι πως συντομα, μα παρα πολυ συντομα οι καρτες γραφικων τουλαχιστον οπως τις γνωριζουμε σημερα, θα κανουν καλη παρεα με τους δεινοσαυρους. Αλλωστε ηταν πραγματικα κριμα ικανοτατα κατα τα αλλα GPU και αρκετες KWh ρευματος να μενουν πρακτικα ανεκμεταλευτα και να μην συντελουν στο ελαχιστο στην βασικοτερη λειτουργια ενος υπολογιστη, το desktop rendering δηλαδη με οτι αυτο συμπεριλαμβανει.

Σακη μια ερωτηση σχετικα με την χρηση Vector graphics. Αυτο σημαινει αλλαγες στα fonts για LCD/TFT ; Η παραμενουν κατω απο το Direct2D/Directwrite ;

Αλλαγες στα fonts και το ClearType ερχονται κυριως σε επιπεδο API integration point Μανο. Εξακολουθουν οπως σωστα υποθετεις και οπως ειναι αναμενομενο να ειναι κατω απο τα DirectWrite/D2D αλλα πλεον τα δυο αυτα API αφηνουν μεγαλο μερος του curve rasterizer του CT στο D2D DXGI. Οπως αποδειχτηκε απο τα Windows 7, το DXGI οντας χαμηλοτερα στο graphics stack καταφερνει να εχει performance ισαξιο και σε καποιες περιπτωσεις με ελλειπη υποστηριξη HDX (βλεπε Nvidia) ανωτερο ακομα και απο το performance του native D2D/HW.

Και για να σε εξιταρω λιγο (μια και η ερωτηση σου σηκωνει πολυ συζητηση), θα δωσω λιγο τροφη για το μυαλο. Για φαντασου λοιπον φιλε μου Μανο, τι θα γινοταν αν το DXGI και το WARP αποτελουσαν πλεον ενα ενιαιο core rasterization API, στο κατωτερο επιπεδο υλοποιησης του GX kernel (ναι kernel ring module) με τους HLSL compilers του WARP να παραγουν σε πραγματικο χρονο το απαραιτητο foundation bytecode για τα vectors; Και ακομα καλυτερα, για φαντασου το HLSL/JIT να μετατρεπει εντος του pipeline το bytecode των geometry, vertex και pixel shaders αντι για SSE2, SSE4.x, x86, η x64 assembly που γινοταν μεχρι τωρα (software rendering), σε hardware foundation function calls συμβατων και υποστηριζομενων δηλαδη απο σχεδον οποιαδηποτε DX καρτα γραφικων, ακομα και αυτες που υποστηριζαν DX10, 9, 8.... :)

Καταλαβαινεις πως σε αυτη την περιπτωση, οχι μονο το font rendering για το οποιο ρωτησες, αλλα το συνολο του D2D/DW rendering ακομα και σε περιβαλλον μη υποστηριξης D2D HW, δηλαδη σε καθαρα software, θα επιτυγχανει performance και οπτικα - αισθητικα αποτελεσματα σχεδον πληρως επιταχυνομενα στο κατωτερο επιπεδο τους. Με απλα λογια, μπορουμε να μιλουμε για πληρη ενεργοποιηση ολων σχεδον των "απαιτητικων" D2D features, με το μεγαλυτερο μερος του WPF eye-candy σε επιπεδο software αλλα με performance hardware accelerated, ακομα και οταν αυτο σε επιπεδο DX11.x δεν παρεχεται απο το GPU.

Και για να τελειωσω την ακατασχετη μακρυγορια μου γυρνωντας στην αρχικη σου ερωτηση, ναι το font-rasterizer εξακολουθει να ειναι κατω απο το DW συνεπως το D2D. Απλα το D2D δεν θα ειναι πλεον αυτο που ξερουμε, γι'αυτο και μιλησα για αλλαγες σε επιπεδο ntegration point. Τα DW/D2D μαζι με το WARP γινονται πλεον μερος ενος ευρυτερου low-level pipeline που θα παραγει unified optimized GX κωδικα με τεραστιες διαφορες στις επιδοσεις ακομα και σε επιπεδο ελλειπους hardware επιταχυνσης, επιτυγχανοντας ταυτοχρονα το ανωτερο δυνατο επιπεδο antialiased curve rendering και οχι μονο στα fonts.

Ribbon-UI στον Windows Explorer;
Αν και δεν ειμαι ο πλεον αρμοδιος να σχολιασει θεματα UI των w8, ωστοσο ο προσανατολισμος και σε touch platforms δεν αφηνει πολλα περιθωρια στο κλασσικο pull-down-menu/status header concept. Με αφορμη ομως την ενσωματωση του ribbon control στα system core widgets και την χρηση του τοσο απο τα system applets οσο και απο τις επερχομενες εφαρμογες, αποφασιστηκαν καποιες εμφανισιακες αλλα και χρηστικες αλλαγες που θα δουμε σε μετεπειτα previews και που κανουν το ribbon περισσοτερο touch-friendly αλλα και λιγοτερο intrusive.

Συγκεκριμενα το trigger action (το γνωστο ctrl+F1), το οποιο μεχρι σημερα στις διαφορες υλοποιησεις ribbon αλλoτε υπηρχε και αλλοτε οχι, υιοθετειται ως standard και με παραμετρικο default value, με μορφη system touch button, system shortcut και system touch gesture. Το επιθυμητο ειναι οχι μονο το ribbon αλλα και τα status floaters να εμφανιζονται on-demand με την χρηση καποιων απο αυτα τα triggers ελαχιστοποιωντας ετσι την οπτικη "ενοχληση".

Επιπλεον το νεο system-wide ribbon control δεν θα ειναι το γνωστο στατικο widget που ειχαμε συνηθισει μεχρι σημερα. Τελωντας ως class host interface θα μπορει να "φιλοξενησει" pinned & favorite shortcuts, class extensions και user η system shell extenders, αναβαθμιζοντας την χρηστικη του αξια πανω απο τα ορια ενος touch-enabled υποκαταστατου του menu. Αναλογες με του ribbon σημαντικες αλλαγες ερχονται και στην taskbar αν και θα πρεπει να περιμενουμε καποιους μηνες πριν τα δουμε στην πραξη. :)

Για τις CTP φιλε Μανο δεν υπαρχει team beta testing καθως αποτελουν απλως παρουσιαση του τι επεται ενω στο μεγαλυτερο τους μερος δεν στηριζονται στο τρεχον project source tree αλλα σε επιλεγμενα μονο μερη του. Οι beta βεβαια ειναι αλλη ιστορια και εκει θα εχουμε ολοι μας λογο και συμμετοχη. Οσο για τα NDA εχει παψει (ευτυχως) προ πολλου η Microsoft να θετει τετοιες "γραφικες" απαιτησεις στους εκτος εταιριας συμμετεχοντες. Αλλωστε ειναι γνωστο τοις πασι και αναμενομενο πως τετοια NDA υπαρχουν αποκλειστικα και μονο για να ...παραβιαζονται. :)

Σχετικα με τα vector based, μια μικρη ενσταση Μανο. Στο OSX ειναι ελαχιστα τα vector στοιχεια του interface, και στην πραγματικοτητα λιγοτερα απο οτι ακομα και στα Vista (που ανερχοταν εκτος GDI στο περιπου 10%). Η χρηση alternative bitmap elements και μαλιστα 72dpi, η αυστηρως αναλογικη κλιμακωση (XYx2) και τα λοιπα συναφη οπως γνωριζεις ουτε ειναι vector based interface ουτε αποτελουν το ευκολοτερα αντικαταστησιμο με vectors υποβαθρο.

Στην περιπτωση των w8 ολοκληρωνεται αυτο που ξεκινησε πρωτα απο τα Vista και σε μεγαλυτερο βαθμο απο τα w7, το DX<->WPF interoperability με ταυτοχρονο remapping των GDI calls στο νεο vectorization model. Στην πραγματικοτητα για πρωτη φορα το DX core και το unmanaged WPF core δεν θα ειναι πλεον μερη ξεχωριστων και αυτονομων υποσυστηματων αλλα αναποσπαστο μερος του system graphics layer, ενω ακομα και μικρες "πινελιες" του users experience (π.χ. tile & frame effects, GUI widgets, desktop element scaling κλπ) ειναι πλεον ανυσματικα και hardware independent. Επιπλεον με το UX layer να αποτελει μερος του unified kernel, τα vector based χαρακτηριστικα ακομα και για την περιπτωση του full hw optimized πολυ απαιτουν πολυ μικροτερο platform based foundation.

Ετσι για παραδειγμα, ενω ενα πληρως DirectX-compliant hardware υποσυστημα απαιτουσε απο το GPU το implementation περιπου 550 functions, το νεο υποσυστημα αρκειται σε περιπου 20 θεμελιωδεις και οι οποιες θα υλοποιουνται απο πολυ οικονομικοτερα, μικροτερα, ψυχροτερα και on dye GPU. Εδω ειναι και το ζητουμενο, καθως ο ορος unified kernel θα πρεπει να ισχυει και στην πραξη μια και τα w8 θα απευθυνονται τοσο σε desktops οσο και σε thin clients, embedded SOCs κλπ.

Συνεπως το "software rendering" για το οποιο βλεπω πως γινεται αρκετη συζητηση, δεν ειναι ουσιαστικα το ζητουμενο αλλα απλα και μονο μια λειτουργικη "παρενεργεια" του platform unification και του device independence στα οποια και προσανατολιζονται πλεον τα Windows. Το βεβαιο ειναι πως για πρωτη ισως φορα, στον κυκλο του development των w8 θα υπαρχουν σημαντικες αλλαγες και επιπροσθετα features σε καθε milestone/beta release. Ισως μαλιστα μεχρι και την τελευταια στιγμη να προστιθενται η να διαφοροποιουνται, καθως ο χρονος που απαιτειται για την ολοκληρωση των προβλεπομενων χαρακτηριστικων ειναι στην πραγματικοτητα υπερδιπλασιος απο αυτον που προβλεπει το schedule. Οποτε δεν αποκλειεται τελικα η RTM να μετατεθει λιγο μακρυτερα απο το Q3 του 2012.

Ειναι βεβαια πολυ νωρις ακομα για να πουμε κατι το τελικο. Ο χρονος θα δειξει την πορεια των πραγματων και εδω θα ειμαστε να τα συζητησουμε διεξοδικα. :)

Το μονο σιγουρο ειναι οτι δε μπορουμε να πληρωνουμε καθε 2 χρονια για λειτουργικο...
Το μεσοδιαστημα των major updates των Windows φιλε vasileios13, δεν ηταν ποτε μικροτερο των τριων ετων και αυτο δεν προκειται να αλλαξει στα επερχομενα Windows. Συγκεκριμενα η RTM των w8 δεν αναμενεται πριν το Φθινοπωρο του 2012 (το συντομοτερο) με την ευρυτερη εμπορικη τους διαθεση να προσδιοριζεται καποια στιγμη στις αρχες του 2013.

Οσον αφορα στα milestones και το beta stage γενικοτερα, ειναι ακομα πολυ νωρις για να μπορεσει να γινει αντιληπτο (και χρησιμοποιησιμο) το ευρος των αλλαγων και των δυνατοτητων του νεου συστηματος. Και για να γινω σαφης, προς το παρον δεν εχει παρα ελαχιστη και μονο "ακαδημαικη" αξια η χρηση καποιας milestone release η οποια ελαχιστα φανερωνει σχετικα με το τι επεται.

Για παραδειγμα, τα μεχρι στιγμης milestone previews χρησιμοποιουν interim kernel και οχι καποια εκδοση του unified kernel που θα χρησιμοποιειται στην τελικη εκδοση. Συνεπως platform χαρακτηριστικα οπως το heterogeneous processing layer, το MPI parallelization implementation του νεου process manager, το επισης νεο WinSock kernel interface WSK, το touch & pysx geometric layer και πληθος αλλων, δεν εχουν ακομα ενσωματωθει στο code tree με αποτελεσμα οπως ειναι φυσικο να μην μπορουν να ενσωματωθουν και να χρησιμοποιηθουν εστω ως επιδειξη ουτε τα user interface parts που θα κανουν χρηση αυτων των δυνατοτητων.

Εκτος μαλιστα των παραπανω "low level" νεων χαρακτηριστικων, και ελλειψει αυτων, δεν εχει ακομα ολοκληρωθει το vector based screen sublayer συνεπως ειναι μαλλον νωρις για να σχολιασουμε το sw η hw rendering, η σωστοτερο τα hardware optimization dependencies του rendering (το οποιο αλλωστε ειναι παντοτε software-based). Μια ομως και αρκετοι φιλοι αναφερθηκαν σε αυτο, αξιζει να προσθεσω πως θα υπαρξουν πολλες ευχαριστες εκπληξεις σε αυτο. Με πλεον του 80% (εναντι 15%) του screen rendering να ειναι πλεον vector based (η vector mapped) και συνεπως hardware optimized τα αποτελεσματα ειναι κατι περισσοτερο απο εμφανη...

Οσον αφορα το beta testing, αναμενεται σχετικα συντομα μια πρωτη community technical preview η οποια και θα συμπεριλαμβανει μεγαλο μερος αν και οχι το συνολο των platform-based χαρακτηριστικων του νεου kernel καθως και τις νεες δυνατοτητες που αυτα προσδιδουν στο users experience. Το αν θα επακολουθησει δευτερη CTP η θα μεταβουμε σε beta stage αυτο ειναι κατι που δεν εχει ακομα οριστικοποιηθει. Παντως οπως εγινε και με τα w7, οι επομενοι 12-15 μηνες αναμενονται ιδιαιτερα "θερμοι" και σε συνεργασια με καποια ενεργα και ικανα μελη εδω στο forum θα επαναδραστηριοποιησουμε το δικο μας beta team. :)

Γνωριζουμε προγραμμα η εντολη που να μας δειχνει ποσο χρονο εχει μεινει ανοιχτο το pc;

Ενα WMI powershell single-liner ειναι συνηθως αρκετο για το uptime status (ωρες:λεπτα:δευτ.μ/sec)

"Uptime (hh:mm:ss): " + (New-TimeSpan (::ToDateTime((Get-WmiObject Win32_OperatingSystem).LastBootUpTime)) (Get-Date))

...Τωρα απο την αλλη μπορεις να μου πεις οτι λαικιζω, αλλα εαν τα νουμερα δεν ειναι και πολυ διαφορετικα απο αυτα που γραφω, ας βγαλει ο καθεις τα συμπερασματα μονος του...
Δεν νομιζω να χρειαζεται φιλε μου anon να σου πω ποσο ελλειπη (επι το επιεικοτερο) ειναι τα στοιχεια σου, αλλωστε δεν ειναι αυτο το ζητουμενο. Υποθετω πως ουτε για εσενα ειναι αλλιως θα επρεπε να μην ξεχασεις στο τελος του μηνα να πληρωσεις τις περιπου 85.000 υπαλληλων που ...αφησες απληρωτους. Ξερεις μπορει να ειναι οπως τους αποκαλεσες, "μη-παραγωγικοι, πωλησεις, μαρκετινγ, νομικα τμηματα, ρεσεψιον", αλλα βλεπεις εχουν και αυτοι την "κακη συνηθεια" να πληρωνονται. :)

Φιλε μου anon, δεν βρισκομαι εδω για να υπερασπιστω η να επικρινω τις τιμολογιακες, μισθοδοτικες η οτι αλλες πρακτικες της Microsoft, ουτε για να κανω απογραφη των εξοδων της, συντελωντας σε αυτη την κατα την ταπεινη μου αποψη αεναη και ατελεσφορη παραφιλολογια. Δυστυχως η ευτυχως ζουμε σε καθεστως ανοιχτης και ελευθερης παραγωγης και οικονομιας, οποτε ο καθενας μας ειναι σε θεση να κανει την επιλογη η την μικρη του επανασταση αν προτιμας, επιλεγοντας καποιο απο τα ανταγωνιστικα προιοντα, τις ανταγωνιστικες εταιριες και τις εναλλακτικες προτασεις που υπαρχουν.

Βεβαια, οπως λεει κι ο αποπανος, οντως, μιλαμε για νεο λειτουργικο συστημα σε ~2 χρονια απο το προηγουμενο... Και να ηταν δωρεαν η αναβαθμιση, αει στο καλο, αλλα...
Ο τριετης κυκλος ανανεωσης του συστηματος δεν ειναι κατι το νεο μια και κρατα απο γενεσεως των Windows, ουτε και αποτελει καποια παγκοσμια πρωτοτυπια της Microsoft. Ολοι μας γνωριζουμε αλλους OS vendors οι οποιοι οχι απλα ακολουθουν αντιστοιχα μεσοδιαστηματα, αλλα προχωρωντας ενα βημα παραπανω δεν δισταζουν να χρεωνουν ακομα και για service packs. Και αν διευρυνει κανεις την κριτικη του προοπτικη, διαπιστωνει πως ο κυκλος ζωης ακομα και του μικροτερου και απλοικοτερου software application σπανια σημερα περνα το ενα ετος. Ακομα χαρακτηριστικοτερο παραδειγμα το hardware που ανανεωνεται με καταιγιστικους ρυθμους ακομα και σε τριμηνιαια βαση.

Ομως ουτε π.χ. το ανανεωμενο CAD, image processor η εστω το απλο burning application παρεχεται δωρεαν στους προηγουμενους κατοχους, ουτε ο νεος επεξεργαστης, ουτε το refreshed laptop η το ανανεωμενο μοντελο αυτοκινητου. Αντιθετα σχεδον στην πλειοψηφια τους δεν προσφερουν ουτε αυτη την μειωμενη τιμη αναβαθμισης την οποια παρεπιπτοντως, στην περιπτωση των Windows οι χρηστες την εχουν σχεδον καθολικα αναγαγει σε τιμη αποκτησης και χρησης.

Και οπως ο χρηστης οποιουδηποτε software η hardware δεν ειναι σε καμια περιπτωση υποχρεωμενος να ακολουθησει το καθε εξελικτικο σταδιο της συσκευης η της εφαρμογης του, ετσι ακριβως και στα Windows μπορει να συνεχισει να αξιοποιει τις δυνατοτητες που του προσφερει η εκδοση που ηδη χρησιμοποιει. Ως χρηστης βεβαια και ο ιδιος, κατανοω απολυτα την "μανια" ανανεωσης και διατηρησης του software (η του hardware) στο εκαστοτε current-top-of-the-line status. Ακομα ομως και οταν για καποιους αυτο δεν ειναι εφικτο η εστω δεν ειναι επιθυμητο, δεν σημαινει σε καμμια περιπτωση πως θα σταματησει η εξελιξη των πραγματων. Ειδικα μαλιστα οταν μιλουμε για λειτουργικο συστημα που ισως ειναι η μονη software "εφαρμογη" που χρησιμοποιειται συνεχως καθε μερα, καθε ωρα και καθε λεπτο χρησης του υπολογιστη, ενω το χρονικα καταμερισμενο κοστος της μετα βιας ξεπερνα τα 5€ το μηνα.

Αν παλι ρωτησεις φιλε μου harris την προσωπικη μου αποψη, θα ηθελα να ηταν ολα δωρεαν, ολες οι αναβαθμισεις, τα παντα lifetime licensed. Δυστυχως ομως στο τελος του μηνα 80.000 ατομα δεν θα αρκεστουν σε μια μικρη αμοιβη "συντηρησης" και "ανανεωσης" αλλα θα απαιτησουν ολοκληρο το μισθο τους. :p

Ελπιζω τουλαχιστον τα παραθυρα του explorer που οριζουν το bloatware, να επανασχεδιαστουν η τουλαχιστον να υπαρχει μινιμαλιστικη εναλλακτικη, διατηρωντας το aero.
Αν και θα με βρεις κατι περισσοτερο απο απολυτα συμφωνο με την παρατηρηση σου, η επερχομενη πληρης και εγγενης υποστηριξη touch δεν αφηνει περιθωρια υπερβολικης αισιοδοξιας για καποιο σημαντικο minimalization του explorer user interface. Απο οσο ομως γνωριζω, το team που ασχολειται με τη συγκεκριμενη "εφαρμογη" κανει μια αξιολογη προσπαθεια γενικοτερου εξευγενισμου της, κατι που βοηθουμενο απο το vector based GUI των w8 εχει τουλαχιστον κατα την αποψη μου ιδιαιτερα ελκυστικα και λειτουργικα αποτελεσματα.

Επισης ελπιζω να βελτιωσουν και την δυνατοτητα αναζητησης σε τοπικα δικτυα....
Θα υπαρχει η δυνατοτητα local και remote indexing των shared volumes (η folders) χωρις την προυποθεση του offline caching. Αυτο που δεν εχει ακομα αποφασιστει ειναι αν η συγκεκριμενη δυνατοτητα θα χρησιμοποιει share mounting auto-sense η θα ενεργοποιειται manually για συγκεκριμενα volumes. Παντως οι μεχρι τωρα αποψεις συγκλινουν στο manually (για ευνοητους λογους), χωρις να αποκλειεται η χρηση policies για την κατα περιπτωση επιλογη.

Οταν ειχα XP, γνησια, μου ειχαν προτεινει να μην εγκαθιστω τα updates γιατι περισσοτερα προβληματα δημιουργουν παρα λυνουν
Το ιδιο ακριβως ισχυει αγαπητε μου φιλε και με κατι τετοιες αφελεις και ακρως επικινδυνες συμβουλες κακων συμβουλων. Περισσοτερα προβληματα δημιουργουν παρα λυνουν...

Εγω ετοιμαζω σιγα σιγα ενα μικρο partition για native εγκατασταση Windows 8
Ειναι πολυ πολυ νωρις ακομα. Τα Windows 8 σε συνολικες ανθρωποωρες αναπτυξης, αναμενεται να ειναι συντριπτικα το μεγαλυτερο project απο ιδρυσεως της Microsoft, οποτε και το χρονοδιαγραμμα των ctp/beta milestones θα ειναι σημαντικα αμβλυμενο συγκριτικα με το παρελθον. Το ιδιο δυστυχως και η πληροφορηση, τουλαχιστον προς το παρον.

Ετσι λοιπον ...λευτερια στα δεσμευμενα partitions μεχρι τον Ιουνιο. :)

To Service Pack 1 εχει ολοκληρωθει εδω και αρκετες εβδομαδες, ενω προ ημερων αρχισε η επισημη διανομη του στους OEMs. Αυτος αλλωστε ειναι και ο λογος υπαρξης των διαφορων "leaks" στο web, καθως ειναι αδυνατον να ελεγχθουν οι πραξεις μερικων εκατονταδων χιλιαδων εργαζομενων σε αυτους. :)

Ενημερωτικα και για να λυθει η απορια καποιων σχετικα με τον λογο που το SP1 οπως και καθε service pack διατιθεται ευρεως στο κοινο με μια καθυστερηση , ο λογος ειναι πολυ απλος και πιστευω λογικος. Η εγκατασταση καθε service pack δημιουργει κυριως στην πλειοψηφια των μη καταρτισμενων τεχνικα χρηστων ενα κυμα αποριων, ενδεχομενως προβληματων χειρισμου η συμβατοτητας, καθως και απλες χρηστικες δυσκολιες. Ολα αυτα θα πρεπει να τα αντιμετωπισει το customer support του καθε κατασκευαστη η το IT τμημα μεγαλων οργανισμων και εταιρειων, κατι που με τη σειρα του απαιτει εκπαιδευση του προσωπικου υποστηριξης (στο συγκεκριμενο SP), προετοιμασια των customized deployment images, προετοιμασια των WSUS και φυσικα hardware validation για οσους δεν το εχουν ηδη πραξει.

Ολα αυτα απαιτουν χρονο προετοιμασιας, που οι OEM/IT δεν θα ειχαν αν ενα service pack κυκλοφορουσε και διανεμοταν αμεσα στον τελικο χρηστη. Ετσι εδω και δεκαετιες εφαρμοζεται απο την Microsoft το μοντελο διανομης OEM->VL->TechNET/MSDN subscribers -> MS partners -> final users / WU.

Συγκεκριμενα, σε major OS - application releases η καθυστερηση απο το πρωτο σταδιο διανομης (OEM) μεχρι το τελευταιο (customers - users) ειναι 12 εβδομαδες, σε minor (SP) 6 εβδομαδες και σε hotfixes 3 εβδομαδες. Σε καθε ομως περιπτωση οταν καποιο release ειναι RTM-tagged αυτο ειναι παντοτε και ανεξαιρετως η επισημα τελικη εκδοση η οποια θα φτασει συν τω χρονο και στα χερια του τελικου χρηστη, χωρις την παραμικρη ενδιαμεση αλλαγη.

ναι ναι ναι. το ξερω απλα μου ηρθε απορια. οποτε θ ακανω ενα partiition ntfs gia ta windows 7---> ποσα γιγα προτεινετε ?

επισης ενα η δυο μετα μικροτερα partitions τα οποια θα ειναι ntfs kai ayta ?

σκληρος 120 giga
Σχετικα με το θεμα του partitioning, εφοσον φιλε μου JeanPaul δεν εχεις συγκεκριμενο χρηστικο λογο που σου επιβαλλει την χρηση πολλαπλων partitions, και καθως αναφερεσαι στο system disk, η χρηση ενος και μονο ενος partition ειναι η ενδεδειγμενη καλυτερη οσον αφορα το performance σε απολυτα νουμερα. Η χρηση περισσοτερων του ενος partition στον ιδιο δισκο εχει ως αποτελεσμα μια αρκετα σημαντικη αυξηση του overhead κατα την προσπελαση του απο το συστημα.

Απο την αλλη παλι, η διαιρεση του system disk σε διαφορετικα partitions (π.χ. για system και data) εχει ως πρακτικο οφελος την διατηρηση των data οταν και αν ποτε χρειαστει πληρης επανεγκατασταση του συστηματος. Γινεται λοιπον κατανοητο πως θα πρεπει ο καθε χρηστης να "ζυγισει" τα πλεονεκτηματα και μειονεκτηματα και να πραξει οπως αυτος κρινει προτιμοτερο. Με απολυτο παντως ζητουμενο το performance, η αρχη "ενας φυσικος δισκος - ενα partition" ειναι το ιδανικο.

Για το CTCP ισχυουν ολα αυτα στα οποια αναφερθηκα προηγουμενως. Με απλα λογια ειναι εντελως περιττη η οποιαδηποτε μεταβολη της τιμης του, τη στιγμη που το συστημα δεν χρησιμοποιειται ως WAN gateway αλλα χρησιμοποιει router γι'αυτο το σκοπο.

Οσον αφορα το ECN, εφοσον γνωριζεις πως το router σου του υποστηριζει, μπορεις να το ενεργοποιησεις εστω δοκιμαστικα. Θα πρεπει ομως να γνωριζεις πως ακομα και αν το router σου αναφερει σαφως την υποστηριξη ECN αυτο δεν σημαινει πως υποστηριζεται "σωστα" το RFC3168, ενω επισης προαπαιτουμενο ειναι πως και καθε transport network device που ισως υπαρχει στο δικτυο (π.χ bridges, firewall κλπ) θα πρεπει και αυτα να υποστηριζουν πληρως ECN η τουλαχιστον να κανουν passthrough τα packets με non-zero ECN bits στο header. Αλλιως θα διαπιστωσεις packet loss καθως θα απορριπτουν τα συγκεκριμενα TCP headers ως corrupted.

τι ενννοεις ? μπορει να βαλω ενα usb stick και να μην το αναγνωρισει ?
Να μην το αναγνωρισει ποιος, τα Windows η καποιο αλλο λειτουργικο συστημα; Τα Windows θα στο αναγνωρισουν ειτε ειναι FAT/FAT32 ειτε NTFS. Αν ομως το συγκεκριμενο stick ειναι NTFS - formated και το χρησιμοποιησεις σε αλλο λειτουργικο (οχι Windows) που δεν υποστηριζει αυτο το filesystem ειναι λογικα αναμενομενο πως δεν θα το αναγνωρισει. Γι'αυτο αλλωστε, οπως και για καποιους αλλους τεχνικους λογους που δεν ειναι του παροντος, στα USB sticks το ενδεικνυομενο filesystem παραμενει το FAT32.

Αλλα απο οτι καταλαβα απο το αρχικο post στο οποιο και απαντησα προηγουμενως, το θεμα δεν ειναι το filesystem ενος USB stick αλλα ενος hard disk partition.

Δεν υπαρχει κανενας απολυτως λογος σημερα να χρησιμοποιειται FAT32 (ποσο δε μαλλον FAT) εκτος και αν προκειται το συγκεκριμενο αποθηκευτικο μεσο η partition να χρησιμοποιηθει απο καποιο αλλο συστημα που δεν υποστηριζει NTFS. Επιπλεον τα Windows 7, 2008/R2 και Vista, σε αντιθεση με παλαιοτερες εκδοσεις του συστηματος, ειναι NTFS optimized με αποτελεσμα να παρουσιαζουν 10-20% υψηλοτερο overhead κατα την χρηση FAT32 partitions, παρα τον απλοικοτερο αρχιτεκτονικα χαρακτηρα του συγκεκριμενου filesystem. Τελος τα FAT/FAT32 δεν υποστηριζουν παρα ενα μινιμαλιστικο subset των extended attributes και security permissions που προσφερει το NTFS και φυσικα κανενα απο τα advanced fault-tolerant options του.

Πιστεψε με καλε μου φιλε πως δεν υπαρχει κανενας λογος να καταφυγεις σε τετοια "τεχνασματα", καθως στην πλειοψηφια των setups δεν υπαρχει το παραμικρο οφελος. Στο παρελθον οταν για τη συνδεση με καποιον ADSL ISP απαιτουνταν Windows PPPOE client, η στην σπανια πλεον περιπτωση χρησης ADSL Windows modem device, καποιες συγκεκριμενες αλλαγες ορισμενων τιμων οπως π.χ. τα MTU/MRU ηταν συχνα επιβεβλημενες ωστε να διατηρειται η "ισορροπια" του packet framing.

Απο τη στιγμη ομως που καποιος χρησιμοποιει ethernet router, ειτε με ενσωματωμενο modem ειτε μεσω εξωτερικου bridged, οι τιμες αυτες του λειτουργικου αφορουν πλεον LAN port οποτε τα default values ειναι τα πλεον ενδεδειγμενα, ενω η αλλαγη τους χωρις να μπορει προσφερει τιποτα οσον αφορα το DSL, θα δημιουργησει προβληματα στην εσωτερικη δικτυωση. Αλλαγες που αφορουν MTU, MRU, TTL packet window sizes κλπ, και που επηρρεαζουν την ADSL (WAN) δικτυωση θα πρεπει να εφαρμοστουν (οταν αυτο απαιτειται) στο wan interface controller, εν προκειμενω στο router και σιγουρα οχι σε ενα συστημα πισω απο αυτο.

Για τις υπολοιπες παραμετρους που αναφερονται στο αρθρο και αφορουν καποια ιδιαιτερα χαρακτηριστικα του stack οπως για παραδειγμα το Direct Cache Access, η οποιαδηποτε αλλαγη τους εξαρταται αποκλειστικα απο το αν ο ethernet controller υποστηριζει μεσω του driver του το εν λογω NETDMA extension. Καθως ομως δυστυχως συχνα, οι κατασκευαστες network adapter δεν υιοθετουν πληρως (η σωστα) αυτα τα extensions, η για το compilation των drivers δεν χρησιμοποιουν το WDK που τα υποστηριζει, τοτε η ενεργοποιηση αυτου του optimization (π.χ. του DCA caching) δεν εχει καποιο θετικο αντικτυπο ενω σπανιοτερα αντι για παραδειγμα να μειωνει το παρατηρουμενο lag το αυξανει η και δημιουργει frame overflows.

Ετσι η αποδοχη και χρηση των defaults για παραμετρους οπως τα rss, chimney, congestionprovider, netdma, dca κλπ ειναι ο ασφαλεστερος δρομος, εκτος και αν ο χρηστης ειναι πολυ καλος γνωστης του network stack των Windows και αντιμετωπιζει συγκεκριμενη κατασταση που ενδεχομενως επιλυεται η βελτιωνεται μεσω αυτων των παραμετρων. Αυτο ομως ειναι κατι το εντελως διαφορετικο και σε καμμια ομως περιπτωση δεν πρεπει καποιος να θεωρησει "αφελως" αυτες τις ρυθμισεις ως μεσον προς ενα "ταχυτερο internet", καθως αυτο εξαρταται απο πληθος αλλων διαφορετικων παραγοντων που δεν εξαρτωνται παρα ελαχιστα απο το stack.

Ελπιζω να βοηθησα.

Η εντολη που εδωσες για το DISM, με το τελευταιο hidesp εφαρμοζει το clean και σε προηγουμενα updates του WU ; Αν οχι υπαρχει αντιστοιχη παραμετρος ;
Το /hidesp αφορα αποκλειστικα και μονο service packs και οχι hotfixes. Ωστοσο το command sequence "/cleanup-image /spsuperseded" κατα την εκτελεση του αφαιρει τα leftovers απο οσα cab και msu hotfixes δεν ειναι επισημασμενα ως system reversible η δεν ειναι απαραιτητα στην παρουσα φαση του συστηματος για το recovery environment.

Πρακτικα Μανο, στην κατασταση που βρισκονται σημερα τα w7 μονο 5-6 hotfixes ειναι uninstallable πριν το SP1 και το DISM και απο αυτα τα δυο που ειναι non-reversible καθαριζονται μια χαρα με το "/cleanup-image /spsuperseded", αφηνοντας το συστημα σε σχεδον clean-installed κατασταση.

Προσωπικα, δεν βλεπω κανεναν λογο καποιος που εχει μια πληρως λειτουργικη εγκατασταση να περιμενει το integraded ISO για clean installation. Εκτος βεβαια και αν ο ιδιος κρινει πως συγκεκριμενα third party apps/drivers του δημιουργουν προβληματα και γι'αυτο επιθυμει να ξεκινησει απο μηδενικη βαση. Παντως απο μονο του το συγκεκριμενο service pack και μετα το DISM δεν εγειρει κανενα τετοιο ενδεχομενο.

+1 και εγω αυτο περιμενω, ολα τα αλλα ειναι ημιμετρα

Εφοσον καποιος χρηστης δεν αντιμετωπιζει για δικους του λογους αμεση αναγκη επανεγκαταστασης του συστηματος, δεν υπαρχει ουσιαστικος λογος αναμονης του integraded ISO. Με την αλλαγη της πρακτικης service pack deployment & installation (απο εποχης Windows Vista), ολα τα backups και τα SP leftovers ειναι tagged στην MSIDB και μπορουν να σβηστουν απλουστατα, αποδεσμευοντας το χωρο τοσο του system disk οσο και της registry.

Απλα μετα την επιτυχη εγκατασταση του Service Pack 1 τρεχουμε σε command prompt το παρακατω.

dism /Online /Cleanup-image /spsuperseded /hidesp

Υστερα απο αναμονη περιπου 3-5 λεπτων το συστημα θα εχει απαλλαγει δια παντος απο καθε τι το περιττο. ΠΡΟΣΟΧΗ ομως, μετα τα παραπανω δεν θα υπαρχει πλεον η δυνατοτητα απεγκαταστασης του service pack.

Για τους σχολαστικοτερους (που btw τους καταννοω απολυτα), λιγη υπομονη μεχρι τα integraded ISOs, και για τους συν τοις αλλοις βιαστικους υπαρχει παντοτε η λυση του WAIK.

@flamelab: Γεια σου αγαπητε φιλε flamelab. Χαιρομαι που σε βρισκω ξανα και συγχαρητηρια για την προαγωγη. :)

Ακομη περιμενω τα επισημα hashes του SP1.
Το γνωριζουμε οτι το SP1, εχει ολοκληρωθει, αλλα επισημα hashes καπου δεν θα ηταν ασχημο.
Αμα παιζει και Slipstreamed iso, ακομη καλυτερα :p

File: windows6.1-KB976932-x86.exe (INTL Rel)
Ver: 6.1.7601.17514 (win7sp1_rtm.101119-1850)
MD5: 4BF28FC00D86C936C89E2D91EF46758B
SHA1: C3516BC5C9E69FEE6D9AC4F981F5B95977A8A2FA

File: windows6.1-KB976932-X64.exe (INTL Rel)
Ver: 6.1.7601.17514 (win7sp1_rtm.101119-1850)
MD5: 28D3932F714BF71D78E75D36AA2E0FB8
SHA1: 74865EF2562006E51D7F9333B4A8D45B7A749DAB

File: windows6.1-KB976932-ia64.exe (INTL Rel)
Ver: 6.1.7601.17514 (win7sp1_rtm.101119-1850)
MD5: C0A186B85239BFAB823B22FF74C192B2
SHA1: 1AB97593F6F625392CA90B18F7617B0797A46F1C

Οσον αφορα integrated ISOs, τα γνωστα δηλαδη ως "slipstreamed", λιγη υπομονη μεχρι την ερχομενη εβδομαδα για συνδρομητες TechNet Std/Pro & MSDN και μεχρι το τελος του μηνα για VL και S/G partners.

Χμμ, για να ειμαι ειλικρινης ποτε μου δεν προκαλεσα τετοια "ριγη συγκινησης" οπως ο εν λογω κυριος. Δυστυχως ειναι λιγο αργα για να αλλαξω επαγγελμα, αν και αυτο να συνεβαινε μαλλον παλι απαρατηρητος θα περνουσα. :)

Γεια σου Μανο, καλως σας βρηκα, αν και εδω που τα λεμε δεν ελλειψα και καθολου. Αρκετα συχνα διαβαζω τα τεκταινομενα στο forum αλλα απλα δεν εχω να πω κατι ιδιαιτερο. Συντομα παντως προβλεπεται ..."δραση" οποτε πιστευω πως θα εχουμε πολλα να σχολιασουμε.

Πληκτρολογω ms βγαζει σε popup list διαφορα και συνεχιζοντας με το c (msc) δεν βγαζει κατι.
ΝΑΙ το msconfig.exe εμφανιζεται κανονικα στο C:\Windows\System32...:)
Υπαρχει καποια λυση να μου το βρισκει οπως θα επρεπε, απ το Εναρξη/Αναζητηση;
Γιατι δεν το κανει τωρα, χωρις... διοδια;:what:

Οπως ειπαν και οι αλλοι συνομιλητες σας, θα πρεπει να γραψετε ολοκληρο το filename (το extension δεν ειναι απαραιτητο). Ο λογος που στο συγκεκριμενο executable οπως αλλωστε και στα περισσοτερα αρχεια του συστηματος δεν υποστηριζεται start menu auto-completion, ειναι πως απλα στα directories \Windows\ και \Windows\System32 δεν γινεται by default indexing ενω ταυτοχρονα δεν ειναι δηλωμενα start menu items.

Φιλε iakoboss7, η βαθμολογηση του WEI δεν ειναι ενα απλα performance index ανεξαρτητων αποτελεσματων benchtesting αλλα συναρτηση πολλων ταυτοχρονως υπο τη μορφη γραμμικων (στην περιπτωση του disk) η μη γραμμικων (π.χ. graphics) αλγοριθμων. Ετσι για παραδειγμα στην περιπτωση του storage assessment, το εμφανες index ειναι ο μεσος ορος 11 ανεξαρτητων benchtests τοσο του ιδιου του δισκου οσο και του burst cmd transfer του interface, καθως και ενος penalty factor στην περιπτωση synched I/O.

Συνεπως το γεγονος πως η βαθμολογια ενος SSD συχνα δεν "εντυπωσιαζει", δεν θα πρεπει να σου προκαλει εντυπωση. Η συντριπτικη πλειοψηφια των NAND SSDs ενω αριστευουν σε sequential R/W και long burst I/O δεν τα πηγαινουν παντοτε τοσο καλα σε random reads και σε grouped I/O κυριως λογω περιορισμων του interface και του EC. Καταλαβαινεις λοιπον πως εφοσον το WEI ειναι απλα ενας μεσος ορος, αρκει μια μετρια η κακη επιμερους βαθμολογηση για να κατεβασει τον γενικο δεικτη, κατι αναμενομενο και λογικο.

Θα προτεινα, οπως σωστα παρατηρησε ο φιλος G.F.D, να δεις τα επιμερους assessments χρησιμοποιωντας το command line winsat.exe μεσω διαπιστωνοντας ετσι τι ειναι αυτο που υποβιβαζει την μεση βαθμολογηση του WEI. Οσο για τα περι "μπακαλιστικου", μπορει οι μεσοι οροι του WEI να ειναι απλα ενδεικτικοι αλλα οι επιμερους δεικτες του WinSat δεν εχουν καμια απολυτως σχεση με αυτο τον χαρακτηρισμο, ουτε και με διαφορα εντυπωσιακα πλην αχρηστα benchtests utilites που κυκλοφορουν. Το WinSat ως foundation subsystem λειτουργει στο κατωτατο επιπεδο εκαστου του καθε kernel device και δεν λαμβανοντας υποψιν overheads και optimizations που κανενα high level benchtest δεν μπορει να λαβει υποψιν, παρεχει τα performance indexes στους bias-correction algorithms του ιδιου του συστηματος.

PS: Τους χαιρετισμους μου σε ολους του καλους φιλους με τους οποιους εχουμε καιρο να τα πουμε.

Εγω ποτε δεν ειχα πει να μην γινεται.
Ειχα πει να γινεται ΔΩΡΕΑΝ.
Ειναι αποδεδειγμενο και τοις πασι γνωστο πως τιποτα το "δωρεαν" δεν εξασφαλιζει την ασφαλεια του origin που απαιτειται σε ενα security certificate. Με την ιδια λογικη που καθε SSL encrypted site owner πληρωνει για ενα managed domain certificate ενω μπορει να εχει ενα self-signed δωρεαν που κανεις ομως δεν θα εμπιστευονταν, ετσι ακριβως και ενας developer ειδικα ενας system developer, μπορει να πληρωσει το αστειο ποσο που απαιτειται για ενα code-sign certificate. Ειναι καθαρα θεμα διαχειρισης, και οπως ειχα πει και στο παρελθον δεν ειναι η Microsoft αυτη που καθοριζει ποσο και αν κοστιζουν τα certificates με τα οποια αλλωστε δεν εχει καμμια σχεση, αλλα οι CA (certification authorities). Σε αυτους λοιπον τα παραπονα περι τιμης, αν και προσωπικα θεωρω πως το κοστος ειναι πραγματικα αναξιο λογου.


Εκει, υπαρχει πολυ μικροτερο προβλημα, για 2 λογους:
α. Υπαρχει το ενδιαμεσο layer των πακετων και του PMS+PM
β. Υπαρχει ενα και μονο ενα copy οποιασδηποτε βιβλιοθηκης σε ολο το συστημα. Οχι οπως στα Windows, οπου εχουμε 10αδες διαφορετικα αντιγραφα των runtimes της VC++ και της VB. Αυτο ειναι επισης ενα πραγμα οπου η Microsoft επρεπε να εφαρμοσει δρακοντεια πολιτικη, και δεν εκανε τιποτα. Επρεπε να απαγορευσει να υπαρχει πανω απο ενα αντιγραφο της καθε βιβλιοθηκης στο συστημα.

Θαυμασια. Με την ιδια λογικη θα σου αντιπαραθεσω πως και στα Windows εδω και χρονια υπαρχει ο Windows Installer που δεν επιτρεπει τετοιες παρατυπιες, ...οταν ομως χρησιμοποιειται. Εξασφαλιζει σε τιποτα ενα linux distribution η υπαρξη package manager πως δεν θα χρησιμοποιηθει αντι του port – package το original source που βαζει τα config, τα scripts η και τα binaries σε λαθος θεση; Φυσικα οχι. Ετσι ακριβως δεν εξασφαλιζει κανενας installer η αλλη τετοια μεθοδος πως θα τηρηθουν τοσο απο τον developer οσο και απο τον καθε administrator τα guidelines του συστηματος. Οσο για τα runtime libs, να υποθεσω πως δεν εχεις συναντησει multiple versions των shared libs που χρησιμοποιουνται σε ενα linux; Ρητορικη σαφως η ερωτηση καθως ολοι μας γνωριζουμε τι και γιατι συμβαινει.

Γι’αυτο αγαπητε μου Wan ας μην καταντησουμε το θεμα X vs Y στο οποιο και δεν εχω την παραμικρη διαθεση να συμμετασχω, τη στιγμη που ολοι μας γνωριζουμε πολυ καλα πως τα παντα στην τηρηση και εφαρμογη καποιων ορθων guidelines ειναι απλα θεμα υπευθυνοτητας για την οποια δεν φημιζεται η πλειοψηφια τοσο των Windows οσο και των *NIX developers. :)


Γεια χαρα Σακη !
Γεια σου Μανο. Χαιρομαι πολυ που εισαι εδω. Για να ειμαι ειλικρινης οποτε κατα διαστηματα επισκεπτομουν το forum διαπιστωνα την απουσια τοσο τη δικη σου οσο και των περισσοτερων της παλιας συντροφιας. :)

Γιατι τα 64-bit ηταν απαραιτητα στο development εφαρμογων για στοιχειωδη πραγματα, πολυ πριν τις αρχιτεκτονικες 64-bit -> και επρεπε τοτε να καταφευγουμε σε ματσακονιες τυπου int64 (αν το ειχε η βιβλιοθηκη μας και ο compiler μας - αν οχι επρεπε με το χερι να χειριζομαστε 2 διαδοχικους 32-bit integers), π.χ. αποθηκευση αρχειων (οριο 4GB), και πολλα αλλα.
Τα ορια και οι περιορισμοι στα οποια αναφερεσαι αγαπητε Wan δεν εχουν σχεση με το μηκος του ακεραιου, καθως παντοτε υπηρχαν 64bit ακεραιοι ασχετως αρχιτεκτονικης, ουτε και ειναι απαραιτητη η χρηση των _int64 η των 64bit integer _t macros. Το TR1 C++ extension library εχει υιοθετησει ως επισημο 64bit integer data type το longlong της C99 ο οποιος υποστηριζεται εξαρχης αμιγως απο την MSC++ δικαιολογωντας απολυτα την επιλογη του LLP64 ADM απο τη Microsoft.

Συνεπως ουτε στο παρελθον ουτε και σημερα δεν υπαρχει κανενας λογος χρησης του _int64 εφοσον αυτο σε ενοχλει. Μιλωντας επι το θεωρητικοτερο οσον αφορα τα δυο abstract data models, τοσο το LP64 οσο και το LLP64 ειναι standard με το δευτερο ομως να γλυτωνει χρονο και stack space απο το ασκοπο waste. Αλλωστε το μονο που απασχολει στο migration 32 -> 64 ειναι οι pointers και τα register types, τα οποια εδω και χρονια ειναι architecture depended και auto expanded. Σε καθε περιπτωση ολα τα παραπανω ειναι περισσοτερο θεωρητικος προβληματισμος καθως η χρηση fixed sized arithmetic datatypes ειναι επιβεβλημενος μονοδρομος για τον οποιοδηποτε συνετο developer.


Και εχω πει πολλες φορες, οτι ουδεποτε η Microsoft κυνηγησε ανελεητα - οπως θα επρεπε - τετοιες κακιστες προγραμματιστικες τακτικες.
Που απο τη στιγμη που φτιαχνει αυτη το API, ειναι εξαιρετικα ευκολο.
Θα επρεπε να απαγορευει το συστημα την απευθειας προσβαση εφαρμογων (με strings στα paths) σε οποιοδηποτε αρχειο των directories του συστηματος.
......
Δεν το τηρει αυτο μια εφαρμογη; Δεν πειραζει κυριε. Κλεισαμε. Πορτα απο τον scheduler και τον kernel και ΔΕΝ τρεχει η εφαρμογη.
Θεωρητικα μιλωντας και αν θελεις την προσωπικη μου αποψη ολα αυτα ειναι περα για περα σωστα. Δυστυχως ομως το σωστο δεν ειναι παντοτε πρακτικα εφαρμοσιμο η αποδεκτο. Και μια και μιλουμε περι 64bit θα μπω στον "πειρασμο" να σου θυμισω την οπως αποδειχτηκε απολυτα σωστα επιβεβλημενη χρηση code signing τουλαχιστον σε επιπεδο kernel modules (drivers, hook traps κλπ). Θα θυμασαι βεβαια ακομα και την δικη σου αντιδραση σε αυτη την επιβολη η οποια κατα την τοτε γνωμη σου αφηνε εκτος Win64 καποιους open source developer drivers λογω των $100 που επρεπε να "επενδυσουν" σε ενα CS certificate (τριτου διαχειριστη και οχι της MS).

Η να σου θυμισω τις ιδεολογικες αντιδρασεις μεγαλου αριθμου Mac developers απο τον ελεγχο και την "λογοκρισια" που η Apple για δικους της φυσικα λογους επιβαλει. Αν θελεις μπορουμε να συζητησουμε για κατι ισως πιο γνωριμο σε εσενα, το FHS. Οπως γνωριζεις απο το 1993 επιχειρειται (και πολυ σωστα) ο καθορισμος συγκεκριμενου structure του file system hierarhy ενω χιλιαδες σελιδες, RFC και αρθρα εχουν γραφει στο κατα ποσο developers και source maintainers θα πρεπει να το τηρουν τοσο ως δομη οσο και ως χρηση για τα configs, τα scripts, τα locks κλπ. Οπως ομως γνωριζεις καλυτερα ισως και απο εμενα, μεχρι και σημερα εξακολουθουν να υπαρχουν apps (και distros) που αδιαφορουν εντελως.

Καταλαβαινεις λοιπον πως η καθε επιβολη αν και θεωρητικα με βρισκει απολυτα συμφωνο, δεν ειναι παντοτε αποδεκτη η εφικτη επι του πρακτεου. :)


Εχω την αισθηση πως ο ρυθμος μεταβασης με την ελευση την windows 7 επιταχυνθηκε, ισως το το επομενο λειτουργικο της Microsoft στοχευει κυρια στα 64bit.
Ο ρυθμος μεταβασης στα 64bit αγαπητε φιλε mob, δεν επιταχυνθηκε εξαιτιας των Windows 7. Ο πραγματικος λογος ειναι η παρελευση του χρονου που εφερε ανανεωμενο hardware στα χερια των χρηστων και μεγαλες ποσοτητες "φτηνης" μνημης που πρεπει να αξιοποιηθει. Αυτο ειναι ολο.
Οσο για το επομενο λειτουργικο της Microsoft, πιστεψε με δεν προκειται να απευθυνθει αποκλειστικα και μονο στα 64bit, οπως δεν προκειται να το κανει και κανενα αλλο OS ευρειας καταναλωσης για τους λογους που προαναφερθηκαν. Αλλωστε εκτος του ψυχολογικου παραγοντα, δεν υπαρχει λογος να απασχολει για παραδειγμα τον χρηστη Win64 τι περιεχει το δευτερο DVD του συστηματος, αυτο δηλαδη των 32bit, ετσι δεν ειναι; :)

Ενημερωτικα μια και αναφερθηκες στο "επομενο συστημα", η αρχιτεκτονικη προσεγγιση των Windows 8 ειναι εντελως διαφορετικη απο αυτη που εχουμε συνηθισει μεχρι σημερα. Συγκεκριμενα για πρωτη φορα θα γινει χρηση των executive snap-ins ως funtamental WOWxx extender, κατι που θα επιτρεπει multiple architectural binaries τοσο system οσο και user, οπως και ανομοιογενους distributed processing με δυνατοτητες εκτελεσης σε διαφορετικα executive stacks (GPU, HPC, foreign architectures κλπ). Και σε ολα αυτα, το pure 64bit εχει σαφως μικροτερη αναφορικη αξια καθως καποια απο τα execution stacks θα ειναι 32, καποια 64 και ορισμενα 128 η και 256bit. Οι λεπτομερειες δεν ειναι βεβαια του παροντος, αλλα στο μελλον αυτες οι αλλαγες θα μας αποσχολησουν πολυ περισσοτερο και οπως καταλαβαινεις θα τις συζητητουμε και διεξοδικοτερα.

PS: Γεια σου φιλε μου flamelab. Χαιρομαι που καποιοι απο την παλια καλη συντροφια εξακολουθουν να ειναι active στο forum. :)

κακιστως στα Win64 υπαρχει ακομα το SysWOW64, κακιστως δεν ονομαστηκε το system32 system64, κακιστως ο long παρεμεινε στα 4 bytes και δεν πηγε στα 8 κλπ.

Αρχιζοντας απο το τελος, για ποιο λογο ο long η οποιοσδηποτε fixsized datatype θα επρεπε να αλλαξει μηκος; Πρωτον η μεταβαση στα 64bit, ειναι μεταβαση σε διαφορετικο memory addressing οχι διαφορετικο arithmetic model. Συνεπως το autoexpand ολων των int/long σε 64bit το μονο που θα επιτυγχανε θα ηταν wasted space στην μνημη χωρις κανενα απολυτως οφελος, ενω θα προκαλουσε πληθος align και arithmetic και source compatibility issues. Το επιθυμητο ειναι το autoexpand των int pointers, των alloc returned structures και των και του CPU mask σε 64bit πραγμα το οποιο και πραγματοποιειται αυτοματως.

Περισσοτερες πληροφοριες μπορεις να βρεις στο MSDN η στο συγκεκριμενο αρθρο: http://msdn.microsoft.com/en-us/magazine/cc300794.aspx

Παρεπιπτοντως αν φιλε μου Wantilles σου εχει οντως δημιουργηθει το ακαδημαικο ενδιαφερον για development και τα λοιπα συνναφη, πραγμα ευχαριστο, ειμαι στη διαθεση σου στα σχετικα topics ωστε να μην ταλαιπωρουμε τους φιλους μας με τετοιες "βαρετες" λεπτομερειες.

Για το αλλο θεμα που εθιξες, αυτο του system32, θα σου απαντησω μια και αποτελει συχνο ερωτημα παροτι δεν εχει παρα ονοματοδοτικη αξια και τιποτα περισσοτερο. Ακομα και σημερα, υπαρχουν εκατονταδες third party εφαρμογες, κυριως παλαιοτερης σχεδιασης, που λογω κακων πρακτικων που ακολουθησαν οι developers τους, οριζουν ως hardwired το %windir%\system32 directory και οι οποιες εφαρμογες απλα θα επαυαν να λειτουργουν στην περιπτωση απλου renaming.

Ωστοσο, και για να απαντησω στο πρωτο σου ερωτημα, στα 64bit Windows, υπαρχει το γνωστο WOW64 service το οποιο ολα τα API requests αυτων των hardwired εφαρμογων αλλα και γενικοτερα ολων των Windows binaries, τα τροποποιει αυτοματα δρομολογωντας τις κλησεις στο directory SysWow64. Με απλα λογια, σε ενα Win64 συστημα υπαρχουν δυο ξεχωριστα system directories, ενα 32bit για συμβατοτητα με τις αντιστοιχες εφαρμογες, και ενα 64bit η χρηση των οποιων οριζεται απο το FSR η αλλιως File System Redirection.

Αντιστοιχη ειναι και η κατασταση των COM server calls οπου τα πραγματα ειναι δυσκολοτερα απο τα static extern calls αλλα με το WOW64 και το sysdir redirection επιτυγχανεται η επιθυμητη και απροσκοπτη συμβατοτητα διαφορετικης αρχιτεκτονικης binaries, libs, user drivers και object servers.

Για ολα αυτα και πολυ περισσοτερες πληροφοριες σχετικα με το FSR των Win64 και τις λεπτομερειες που σε ενδιαφερουν μπορεις να συμβουλευτεις το παρακατω doc.

http://download.microsoft.com/download/A/F/7/AF7777E5-7DCD-4800-8A0A-B18336565F5B/wow64_bestprac.docx


Τωρα σχετικα με το κυριως θεμα της συζητησης, την ευρεια υιοθετηση των 64bit, οι παλαιοτεροι νομιζω θυμομαστε πως το migration 16->32bit χρειαστηκε πλεον της μιας δεκαετιας για να ολοκληρωθει οχι τοσο τεχνικα οσο σε χρηστικο επιπεδο, ενα διαστημα που αναμενωμενο ειναι πως θα χρειαστει και στην σημερινη μεταβαση 32->64. Απο τη μια η εγγενης δυσπιστια και ο σκεπτικισμος που συνηθως ταλανιζει τους χρηστες τετοιες μεταβατικες περιοδους, απο την αλλη η επισης λαθος αντιληψη της ολοκληρωτικης μεταβασης που χαρακτηριζει τους "technofreaks", συν τα εκατομμυρια παλαιοτερης αρχιτεκτονικης μηχανηματα, ολα αυτα καθυστερουν την πληρη μεταβαση.

Απο την αλλη παλι, δεν σημαινει πως τα 32bit θα εξαφανιστουν η θα πρεπει να εξαφανιστουν σε μια νυχτα, ουτε πως τα εκατονταδες εκατομμυρια 32bit μηχανηματα που κυκλοφορουν θα παψουν να ειναι λειτουργικα και θα παρουν τον δρομο της ανακυκλωσης. Επιθυμητο μεν θεωρητικα αλλα ασκοπο και δαπανηρο για πολλους απο τους χρηστες τους. Οποτε οσο υπερμαχος ειμαι των ριζοσπαστικων αλλαγων που ευαγγελιζεται ο Wan και αλλοι φιλοι, αλλο τοσο προσπαθω να βλεπω με λιγο πρακτικο ματι την ισχυουσα κατασταση η οποια δυστυχως η ευτυχως μικρη σχεση εχει με ενα group tech-enthusiasts οπως το forum μας. :)

Αν και καποτε θα πρεπει να παρθει μια αποφαση και να κοψουμε το γορδιο δεσμο με την καταργηση του 32bit. Μηπως με τα Windows 8;
Φιλε μου apostol70 η καταργηση των 32bit δεν προκειται απο μονη της να καταφερει κατι το θετικο η μαλλον το επιθυμητο. Εδω που τα λεμε τον "γορδιο δεσμο" οπως τον χαρακτηριζεις, ηδη τον κοβει ο σχετικα εμπειρος χρηστης με την επιλογη του να στηριξει το συστημα του σε καποιο 64bit OS. Τωρα αν μιλαμε για επισημη καταργηση των 32bit ως pointed architecture αυτο δεν προκειται να γινει ουτε στα Windows 8 οπως δεν αναμενεται να γινει συντομα και σε κανενα αλλο γνωστο συστημα, για τους λογους που προαναφεραμε. Με απλα λογια, δεν υπαρχει λογος να εκβιαστει μια μεταβαση που ετσι και αλλιως ηδη τελειται, ουτε να στερηθουμε την επιλογη ως εστω προσωρινη εναλλακτικη. :)

Ενω το Linux και οι εφαρμογες του, εχουν μεταφερθει πληρως απο το φθινοπωρο του 2004.

Τα ειπαμε και αλλη και φορα φιλε μου WAntilles, το να μεταφερεις μια οποιαδηποτε εφαρμογη και οποιουδηποτε λειτουργικου σε 64bit runtime δεν ειναι τιποτα δυσκολο καθως στην πλειοψηφια τους το μονο που απαιτειται ειναι ενα rebuild. Το να το κανεις ομως σωστα εκμεταλευομενος για παραδειγμα full wide mallocs με 64bit returns η extended addressing FIELD_OFFSETs και ενα σωρο τετοιες μικρολεπτομερειες που κανουν την διαφορα, ειναι μια εντελως διαφορετικη ιστορια. Συνεπως το να μιλουμε σε οποιοδηποτε λειτουργικο για "πληρως μεταφερθεισες" εφαρμογες ειναι ενα θεμα που σηκωνει πολυ και αφανταστα βαρετη συζητηση.

Αν μου επιτρεπεις μια προσωπικη αποψη, τετοιου ειδους ports απλα rebuilds δηλαδη ειναι προτιμοτερο να μην υπαρχουν, ειδικα μαλιστα οταν κατι τετοιο δεν ειναι απαραιτητo. Και με εξαιρεση συγκεκριμενες κατηγοριες εφαρμογων η συντριπτικη πλειοψηφια δεν εχει και πολλα να κερδισει απο μια βιαστικη και κατ' ονομα, αδοκιμη μεταβαση στα 64bit, εστω και αν κατι τετοιο περαν του ψυχολογικου παραγοντα περι ομοιογενειας. θα διευκολυνε τις ζωες πολλων απο εμας, εμου συμπεριλαμβανομενου. :)

PS: χαιρετω τον φιλο WAntilles και ολη την παρεα, μια και εχουμε πολυ καιρο να τα πουμε.

"Beta για download"; Θα ελεγα πως πρεπει να εχεις αρκετη υπομονη μεχρι τοτε αγαπητε φιλε flapjsck. :)

Για το μονο που μπορουμε να μιλουμε ασφαλως για πολλους μηνες ακομα, ειναι ενα εντελως πρωιμο technology preview χρησιμο μονο ως standpoint framework καποιων πρωτων σημαντικων νεων αρχιτεκτονικων, και αυτο οχι publicly released πριν το Q1 2011. Οσο για συγκεκριμενο χρονο εναρξης του beta stage, εννοειται πως κανεις δεν γνωριζει ακομα καθως δεν εχει προσδιοριστει, ουτε προβλεπεται να γινει κατι τετοιο πριν τους πρωτους μηνες του 2011.

Παντως, απο το ερχομενο καλοκαιρι θα εχουμε πολλα να συζητησουμε σχετικα με καποια απο τα νεα χαρακτηριστικα των w8, και τοτε θα εχουμε ολοι την ευκαιρια να διαπιστωσουμε ποσο πραγματικα απεχουν οι "προβλεψεις" που κατα καιρους κυοφορουνται στο web...

Aλλα γιατι συγκεκριμενα το Φθινοπωρο???

Μετα τον Αυγουστο ξεκιναει το πρωιμο alpha/tp stage των Windows 8 που καποια στιγμη μεσα στο 2011/Q1 θα οδηγησει στο πρωτο public technical preview. Σε καμμια περιπτωση δεν θα ελεγα φιλε flapjsck, πως θα πρεπει να περιμενει καποιος μια ολοκληρωμενη εικονα του συστηματος σε αυτο το πρωτο σταδιο, ωστοσο θα γινουν ευρυτερα γνωστα πολλα χαρακτηριστικα του τα οποια και το διαφοροποιουν απο καθε προηγουμενο release. Και πιστεψε με, σε πολυ λιγα σημεια αναμενεται να θυμιζει τα γνωστα η εστω και εμφανισιακα τα διαφορα mockups που κυκλοφορουν στο web.

Δεδομενου μαλιστα του ενδιαφεροντος που ειχε εκδηλωθει απο δεκαδες μελη του adslgr στο παρελθον κατα το tp και beta testing των w7, υπαρχει μια σκεψη για την δημιουργια ενος επισημου Microsoft Connect channel που ελλειψει official Greek beta team θα επιτρεπει σε εναν αρκετα μεγαλο αριθμο εμπειρων μελων να συμμετασχουν ενεργοτερα στο αντιστοιχο σταδιο των w8, με προσβαση σε private builds, resources, bug reports κλπ. Αυτο βεβαια για την ωρα ειναι απλα μια σκεψη, ισως ομως συντομα το δουμε να πραγματοποιειται. :)

Γεια σε ολους, εφτιαξα ενα site για τα μελλοντικα windows 8 και θα ηθελα να μου πειτε γνωμες, να γραψετε στο blog και να μου πειτε (στο blog παντα) αν θα θελατε να προσθεσω κατι στο ιδιο το site η για κατεβασμα.

Καλη η προσπαθεια αγαπητε φιλε flapjsck, ομως θα μου επιτρεψεις την παρατηρηση πως τοσο τα screenshots που εμπεριεχονται στο site σου, οσο και τα λοιπα info περι "Windows 8". δεν εχουν σχεδον καμμια σχεση με την επερχομενη εκδοση των Windows, τοσο εμφανισιακα οσο και λειτουργικα.

Προκειται για fake mockups και μαλλον ελαχιστα ευφανταστα καθως ακολουθουν την πεπατημενη του τρεχοντος look του συστηματος, κατι που δεν θα ελεγα πως ισχυει στην πραγματικοτητα. Αν εχεις αρκετη υπομονη μεχρι το Φθινοπωρο θα μπορεσεις να σχηματισεις μια ακριβεστερη προσεγγιστικα αποψη για το τι επεται... :)

ΧΡΟΝΙΑ ΠΟΛΛΑ - ΚΑΛΑ ΧΡΙΣΤΟΥΓΕΝΝΑ

τις καλυτερες ευχες μου για υγεια και ευτυχια σε ολους τους φιλους!

Υπαρχουν φωτογραφιες απο τα κοριτσια...:whistle::p

Αρκει να μην πεσουν αυτες οι φωτογραφιες στα χερια της κυριας μου. :)

Που να δεις τις οδηγιες του συμβολαιου μη αποκαλυψης λεπτομερειων :p

Μονο αγαπητε φιλε nnn, στα πλαισια του NDA και της ευρυθμης λειτουργιας του forum θα παρακαλεσω να μην δωσεις λεπτομερειες σχετικα με το τι εγινε μολις ηρθαν στο παρτυ τα κοριτσια. :)

Ε τοτε και το defrag στον δισκο σου δινει την εντυπωση οτι πας πιο γρηγορα......:rolleyes: το ιδιο ακριβως ειναι............ Το ενα εχει σχεση με την αναγνωση δεδομενων των αρχειων και το αλλο των προγραμματων (registy).

Δεν ειναι ακριβως ετσι φιλε μου chosenOne. Στη μια περιπτωση η καθυστερηση οφειλεται σε επαναλαμβανομενη μηχανικη κινηση του disk head, η οποια εκ φυσεως ειναι (θεωρητικα) αργη ενω στη δευτερη δεν μιλουμε παρα για locating του intex pointer μιας database, μια απο τις ταχυτερες in-mem διαδικασιες. Εκτος δε απο αυτη την σημαντικη διαφορα, να θυμισω πως δεν πρεπει να συγχεουμε το registry file defragmentation με το hive defragmentation στο οποιο και αναφερθηκες.

Το μεν πρωτο, μπορει να εχει fragments, αρμοδιο ομως γι'αυτα ειναι το fs defragmenter των Windows (η καποιο third party). Το registry defragmentation ομως ειναι εντελως διαφορετικη διεργασια και δεν εχει σχεση με τα fragments του αρχειου αλλα των hives. Και αυτο οπως ηδη προανεφερα κατι τετοιο δεν προσφερει απολυτως τιποτα οσον αφορα το performance, ενω ταυτοχρονα το ιδιο το συστημα διαχειριζεται αυτοματα τις (σπανιες) περιπτωσεις των excessive fragmenting η των off-sync indexes, με την ιδιες σχεδον μεθοδους αναδιαταξης που χρησιμοποιουνται σε καθε indexed database.

Το windows update φιλε Wan, χρησιμοποιει by default το %windir%\softwaredistribution directory για d/l και caching ολων των hotfix downloads και αυτο δεν μπορει να βρισκεται εκτος root. Το συγκεκριμενο directory, εκτος του BITS caching αποτελει αναφορα και requirement των MSI installers (γι'αυτο αλλωστε και φερει TrustedInstaller security ACL που εκ φυσεως δεν υποστηριζεται σε SAMBA) και συγκεκριμενα το caching των prerequisites καθως και ως local caching των WSUS.

Οποτε κατι τετοιο που ζητας δεν μπορει ευκολα να γινει, καθως για τη συγκεκριμενη εργασια προτεινεται η χρηση των Windows Server Update Services (WSUS) που ειναι και η ευκολοτερη και αποτελεσματικοτερη λυση.

Ωστοσο οπως θα προσεξες, τονισα το "ευκολα" γιατι ειναι δυνατον να εχεις τη λειτουργικοτητα που ζητας με τη χρηση admin scripting που απλα θα αναλαμβανει το mirroring του %windir%\softwaredistribution\Download σε καποιο SMB share στο δικτυο σου. Με απλα λογια, το μονο που χρειαζεται ειναι ενα script το οποιο χρησιμοποιωντας π.χ. το robocopy θα κανει ανα τακτα χρονικα διαστηματα sync του update caching folder με οποιο lan share θελεις.

Το Αερο και ολα αυτα τα καλουδια πως βγαινουν απο τα win 7 μιας και HTPC το μηχανημα και δεν προκειται ποτε να τα δειξει αυτα αφου μονο το MCE ανοιγει αυτοματα.

Εφοσον φιλε μου giorgiosb το συστημα σου ειναι εξοπλισμενο με καρτα ικανη να υποστηριξει το Aero, τοτε απενεργοποιωντας το θα επιτυχεις το εντελως αντιθετο αποτελεσμα απο το ζητουμενο. Θα υπαρξει δηλαδη μειωση του performance της απεικονισης αντι για βελτιωση. Και αυτο διοτι το Aero σε αντιθεση με την κοινη αντιληψη πως προκειται απλα για ενα skin, ειναι στην πραγματικοτητα host του μονου πληρως accelerated graphics layer των w7.

Αναφορικα με το θεμα περι registry defragmentation, πολυ σωστα το εθεσαν οι φιλοι συνομιλητες, εντελως περιττη και ακρως επικινδυνη διεργασια χωρις κανενα οφελος για το συστημα. Εκτος αυτου, το ιδιο το συστημα αναλαμβανει την συντηρηση η και ανακτηση πιθανων fragments στη registry με db compacting (κατα τη διαρκεια του hives backup creation), κατι ομως που εκτελειται σε επιπεδο system αυτοματα και μονον εφοσον ειναι πραγματικα απαραιτητο (excessive fragmenting, off-sync indexes κλπ).

Θα μου επιτρεψουν οι δυο καλοι μου φιλοι c4lex και asm να εχω μια καλυτερη προταση.

Γιατι δεν μενετε και οι δυο πιστοι στις επιλογες σας οποιες και αν ειναι αυτες, αφηνοντας στην ακρη τις αντιπαραθεσεις που περαν των προσωπικων προσβολων δεν προσφερουν τιποτα σε κανεναν, ενω ταυτοχρονα αμφιβαλλω αν εχουν την παραμικρη αξια για το forum;

Καλο μεσημερι σε ολους. :)