Snow Leopard - Page 1

Tiens, il n'y avait pas encore de sujet dessus...
Snow Leopard Client
Snow Leopard Server


Je dois avouer que je l'attends avec impatience, surtout quelques fonctionnalités de la version serveur :
- iCal Server 2 (avec un webcalendar)
- un nouveau serveur mail , Dovecot, enfin parfaitement compatible IMAP, avec le push vers l'iPhone
- serveur de carnet d'adresse
- système de fichiers ZFS
Bref, j'envisage très fortement un MacMini avec 10.6 server et un iPhone


Après, le Client, je ne sais pas trop ce que ça va donner... Qu'en pensez-vous ?

Quels sont les problèmes avec ZFS ? sur le papier, ça paraît pas mal, pourtant ?

bouffeur de ressources (j'en avais déjà parlé dans le coin, le prefetch zfs est pas génial génial), des problèmes little endian/big endian (bon, pas lié 100% à ZFS, mais il se trouve que les perfs du zfs import sont mauvaises et il bouffe 100% de CPU)...

Mais n'est-ce pas lié à l'implémentation de Sun ? Si celle d'Apple n'est toujours pas finie, on peut supposer qu'ils ont réglé ces problèmes, non ? (en tout cas, je l'espère)

Accessoirement, je suis tombé sur ces benchs du ZFS vs HFS+ sur 10.5, ça vaut ce que ça vaut, mais c'est plutôt prometteur semble-t-il ?

ben ça dépend, très franchement, ZFS va tenir la comparaison en access time pur, mais il va demander plus de ressources cpu/ram, et fera plus d'accès disques à cause du prefetch.
pour l'implémentation j'en sais rien, j'aurais tendance à dire que ZFS est un produit Sun, ils ont des chances d'avoir un temps d'avance sur les autres au niveau backend et compétences...

Peut-être que c'est la raison pour laquelle ils le réservent aux serveurs, qui aura les ressources CPU et RAM pour utiliser correctement le ZFS.
C'est dommage, les fonctions pour vérifier l'intégrité des données m'intéressent beaucoup

hmmm, pour l'intégrité après je sais pas, j'ai été utilisateur mais non administrateur (-> les problemes de cpu/ram), et maintenant, côté stockage baie (-> les problemes de perf aux montages, et autres joyeusetés propres aux problématiques stockage massif)

Ah dommage :/
c'est vraiment un truc qui m'intéresse, et je ne vois pas vraiment de solutions de remplacement :/

bah après sur une station cliente pourquoi pas, m'enfin disons que de ce que j'en vois, ça participe à la nécessité de courir aux augmentations de cpu/ram. En gros, on sait que la cpu et la ram, c'est pas cher, le disque non plus, alors on s'emmerde plus à faire des trucs "légers", on fait un truc plus lourd, qui a certes des perfs plus intéressantes, m'enfin ça bouffe de la ressource pour de l'accès disque et je trouve ça lamentable ^^

kim (./10) :
bah après sur une station cliente pourquoi pas, m'enfin disons que de ce que j'en vois, ça participe à la nécessité de courir aux augmentations de cpu/ram. En gros, on sait que la cpu et la ram, c'est pas cher, le disque non plus, alors on s'emmerde plus à faire des trucs "légers", on fait un truc plus lourd, qui a certes des perfs plus intéressantes, m'enfin ça bouffe de la ressource pour de l'accès disque et je trouve ça lamentable ^^

Bien sûr, mais je trouve que la sécurité apportée par cette vérification est vraiment intéressante... J'ai eu plusieurs fois des fichiers corrompus, sans savoir à partir de quel moment ils l'étaient... 

kim (./10) :
on s'emmerde plus à faire des trucs "légers", on fait un truc plus lourd

Tiens, je trouve cette assertion parfaitement vraie au niveau des jeux entre autres... (Avant on faisait tenir des FPS sur 100 mégas, aujourd'hui 25gos. Certes y'a plus de textures, mais je pense aussi qu'on optimise moins le code..)

D'un autre côté, il y a quand même nettement plus de fonctions et de services

Justement c'est discutable:
-Avant tu avais 10 (arbitraire) ressources et ton programme en nécessitait 2 pour 4 services.
-Aujourd'hui tu as 100 (x10) ressources, ton programme en bouffe 40 (x20!) pour te fournir 20 (x5...) services.

C'est pas du tout linéaire (enfin en même temps c'est pas 'implicitement' linéaire... C'est juste "désirement linéaire" pour le consommateur!)

Le blond (c)?

redangel (./14) :
Justement c'est discutable:
-Avant tu avais 10 (arbitraire) ressources et ton programme en nécessitait 2 pour 4 services.
-Aujourd'hui tu as 100 (x10) ressources, ton programme en bouffe 40 (x20!) pour te fournir 20 (x5...) services.

C'est pas du tout linéaire (enfin en même temps c'est pas 'implicitement' linéaire... C'est juste "désirement linéaire" pour le consommateur!)

Mais il y a également pas mal de services qui sont coûteux, tout de même (indexation, sauvegarde, ...)

Certes.

J'ai lu un peu ton comparatif: l'accès aux fichiers beaucoup plus rapide en ZFS, c'est ça? Grâce à l'indexation?

en fait, ZFS met en cache ce qui est accédé ou écrit sur disque, donc pour peu que tu sois pété de RAM, ZFS va limiter grandement tes accès disques. De plus, ZFS permet le prefetching, c'est à dire qu'il lit en avance les données. Genre tu regardes un fichier, il va lire plus loin que ce qui est demandé immédiatement, pour pouvoir répondre à un hypothétique besoin futur. Très pratique aussi, mais nécessite encore de la ram...

Tiens, autre effet marrant : ZFS derrière une baie EMC sur du solaris 10, c'est très fun : la baie va prefetcher des données, ZFS le fait également, et ajoute le cache côté baie et côté ZFS, et vous verrez les perfs d'accès s'effondrer (bah oui, si je demande 10Mo de données, on en vient à demander sur disque le quadruple minimum... très fun)

Ok, merci pour les infos

Donc ZFS+Ram = pasmal. (sauf petits fichiers... y'a pas une taille mini de préfetch réglable? Genre fichier<10mos => Pas de préfetch..)

bonne question. Je suppose qu'il va prefetcher les ptis fichiers aussi, ce qui te fera pas gagner énormément en soi, par contre, vu que y'a un cache, là, tu vas y gagner, comme en UNIX, d'une manière générale, tout est fichier, et niveau systèmes, *petits fichiers*

Bon, ZFS annulé


http://www.apple.com/fr/server/macosx/features/ => ils ne savent même plus traduire en français ? :/

Bon, passage au 64 bits
ils en ont profité pour booster la sécurité, si j'ai bien compris

Autre avantage des applications 64 bits dans Snow Leopard : elles sont mieux sécurisées contre les pirates et les logiciels malveillants que les versions 32 bits puisqu'elles peuvent exploiter davantage de systèmes de sécurité sophistiqués pour neutraliser du code potentiellement dangereux. Tout d'abord, les applications 64 bits protègent vos données grâce à un mécanisme de passage de fonctions plus sécurisé et à l'utilisation d'une fonction matérielle "execute disable for heap memory". De plus, la mémoire du tas système est protégée par des signatures cryptographiques renforcées, empêchant les attaques visant à corrompre la mémoire.

mais en vitesse, y a bien quelques applis qui ont l'air plus rapide (20 - 30, je suis curieux de voir si on le ressent vraiment

Grand Central
J'ai du mal à voir ce que c'est... On dirait un peu un OpenMP, mais dont le nombre de threads varie suivant la taille du calcul à faire (un seul thread si l'appli ne fait presque rien, davantage si elle bosse beaucoup).

OpenCL
Bon, rien de neuf à ce sujet, faut voir si l'API est simple d'accès... et si OpenCL a plus de succès que CUDA, et c'est loin d'être gagné.

QT X
Ça a l'air pas mal, mais là encore je suis curieux de voir si ça change beaucoup... Quid de QT Pro ? Quid du lecteur DVD ?

Exchange
Je ne pensais pas être intéressé, mais si ça apporte plus de fonctions que SL Server, ça pourrait être pas mal du tout (au niveau de la gestion des notes, du carnet d'adresse, etc.)

Voice Over
Il a l'air d'être en français \o/ Ça, c'est cool
Toujours dans l'accessibilité, j'espère que le passage en de l'écran niveaux de gris fonctionne mieux... (j'ai régulièrement plein d'artefacts avec Leopard)

Safari 4
J'adore Rien d'autre à dire

Mail & Cie
Manifestement, il sera nettement plus rapide... J'espère qu'il sera aussi débuggué, parce que la gestion des notes est pour l'heure... calamiteuse ?
Le carnet d'adresse gère la synchro avec un serveur, c'est franchement pratique ça aussi Mais l'iPhone n'a pas l'air d'en profiter


Bon, tout ça pour 29$... ça reste raisonnable, je trouve

Grave, le prix est fendard!

Mais à noter quand même que c'est pas Snow Leopard qui coûte 29$, mais bien la MISE A JOUR de Leopard vers la Neige...
Cela-dit, je vais pas hésiter une demi-seconde!

Quand à OpenCL, ça a franchement moyen de poutrer, si les API sont bonnes. J'ai envie d'y croire (et apparemment AMD et Nvidia aussi, qui sont quand même les acteurs )

Safari 4: quoi de mieux par rapport à la beta? Perso j'ai pas mal de problème avec Gmail (il faut genre le recharger 3 fois avant qu'il m'affiche la boîte...), mais peut-être dû à Gmail Offline(?); et aussi avec Facebook, qui 2 fois sur 3 ne charge pas la page complètement/la charge indéfiniment.

Manifestement, OpenCL ne sera réservé qu'à très peu de cartes graphiques  Dommage pour mon MBPro .. mais mon futur Mini va en profiter \o/)

L'accélération matérielle pour les vidéos ne sera que pour les GeForce 9400m  (l'entrée de gamme : mini, iMac 20", MB et le bas des MBPro )


Ils parlent d'un Mail plus respectueux d'IMAP


Pour les MBPro 15" 8h d'autonomie en WIFI
Je veux ! \o/ Avec un peu chance, ils vont finir par remplacer le lecteur CD par une batterie plus grande (histoire de passer à 10 ou 11h #reve#)

(enfin, j'ai encore 15 mois à faire avec mon portable actuel, on verra après )

Flanker (./24) :
ils vont finir par remplacer le lecteur CD

et tu trouves que c'est un bien? C'est un peu tôt encore je trouve.. (Ré-installer mac os, windows!..et les DVDs de films?)

Mais bon les 8h me font un chouille regretter mon achat d'y y'a 6 mois (mais c'était y'a 6mois).

Apparemment les nouveaux Macbooks Pro ont du sata2 bridé à 1,5 Gbit/s au lieu de 3..

EDIT: mauvais choix d'unités.

Pour OS X, tu peux réinstaller via le réseau (wifi ou ethernet)... Sinon, il y a toujours les lecteurs CD externes, hein

..qui te mangent un USB.

Mais bon, sur le fond, tu as raison.
(c'comme la suppression des disquettes.)


Mais bon on regardait pas de films sur disquettes, ni n'écoutions de musique d'ailleurs.
S'il faut emporter un lecteur externe pour regarder un DVD dans le train..

ouais enfin 'tention, si si, on échangeait les mp3 sur disquettes
Pis on jouait aussi

(1/2 mp3 par disquette? )

Pour jouer, je dis pas (Wolfenstein 3D )

./28 : t'es fou ! à l'époque, on compressait beaucoup plus

Le mp3 est pas (ou très peu) compressible. Je suppose que tu parles de mpeg1-layer 2 ou un truc plus vieux encore!
(ou du mp3 en 32kbits? #beurk#)