Tout récemment, le disque dur système de mon PowerMac G5 est tombé en panne. C'était un bon vieux Raptor de 75Go. Aujourd'hui, les disques dur de grosses capacités ne coute plus grand chose mais les performances ne sont pas nécessairement là. Le remplacement est donc urgent, et je décide de le remplacer par un SSD de 60Go signé Ocz.
L'installation se passe bien puis je redémarre l'ordinateur sur le SSD. La différence n'est pas flagrante car le SSD est connecté en SATA de première génération. Cependant, le démarrage est plus rapide et la fluidité des applications bien plus grande. Par exemple, Page s'ouvrait en 10 ou 15 secondes alors que maintenant, je n'ai pas le temps de dire "ouf". L'application fait un bond dans le Dock est elle est lancé.
Le gain est bien là et avec les 4Go de RAM et deux G5 à 2,5GHz me voilà avec une belle machine.
Seulement, je n'ai pas acheter un SSD mais deux. Le deuxième, je le destine à un petit mac mini qui se traine. Malgrès sont disque dur à 5400 tpm, Word met près d'une minute à ce lancer. C'en est trop, j'ai décidé de le remplacer par le SSD.
Après avoir installer le SSD dans la machine et le disque dur dans un boitier externe, j'installe Mac Os X 10.6 sur mon petit Core Duo @ 1,66GHz.
La surprise fût grande lors du redémarrage, la petite roue sans fin qui aide à patienter au démarrage n'as même pas le temps de faire un tour complet que le bureau s'affiche. Je n'aurais jamais imaginer qu'un SSD puisse libérer autant de puissance.
Perdons nous patience ou est-ce une histoire marketing ?
En effet, à chaque renouvellement de gamme d'ordinateur, les constructeurs nous vente les mérites de leur ordinateurs. C'est pour vendre! Mais aurions-nous envie de changer si nos ordinateurs ne ralentissait pas ? Mon petit CoreDuo fait partie des premières séries de Mac Intel et malgré ces 5 années, il vient de repartir pour de nombreuses autres (je l'espère).
vendredi 25 février 2011
jeudi 24 février 2011
Apple présente sont implémentation de Light Peak
Apple viens de présenter ses nouveaux portables MacBook Pro 13" à 17" avec une nouvelle exclusivité !
En effet, Intel parle depuis un certain temps de sa technologie Light Peak mais la phase de l'industrialisation n'était pas encore réalisé. Il semble que cela soit le cas maintenant sous le nom de Tunderbolt. En français, nous pourrions le traduire par "Foudre".
Apple offre là une exclusivité pour les premiers pas de sa technologie. Le paris est-il risqué ? L'avenir nous le dira. Pour Intel et Apple il faut convaincre les partenaires à l'adopter comme la nième interface. Il est courant de voir des boitiers pour disque dur externe avec l'USB2 ou 3 et l'eSata. Macway a même réaliser un boitier très polyvalent car il dispose de l'USB2, du FireWire 400 et 800 et de l'eSata. Bientôt du Light Peak ?
Rappelez vous en 98, Apple abandonne du jour au lendemain tous ses connecteurs propriétaire pour faire place à l'USB et au Firewire 400. Au final, ils ont démocratisé mieux que personne ce connecteur mal connu et peux utilisé !
L'histoire se répètera-elle ? C'est à souhaiter car un tel connecteur est une aubaine pour bon nombre d'entre nous. Il faudra voir avec les périphériques compatibles mais imaginez un dock pour portable ou il vous suffit de connecter ce seul câble et l'alimentation pour être connecter à tous vos périphériques ?
En effet, Intel parle depuis un certain temps de sa technologie Light Peak mais la phase de l'industrialisation n'était pas encore réalisé. Il semble que cela soit le cas maintenant sous le nom de Tunderbolt. En français, nous pourrions le traduire par "Foudre".Apple offre là une exclusivité pour les premiers pas de sa technologie. Le paris est-il risqué ? L'avenir nous le dira. Pour Intel et Apple il faut convaincre les partenaires à l'adopter comme la nième interface. Il est courant de voir des boitiers pour disque dur externe avec l'USB2 ou 3 et l'eSata. Macway a même réaliser un boitier très polyvalent car il dispose de l'USB2, du FireWire 400 et 800 et de l'eSata. Bientôt du Light Peak ?
Rappelez vous en 98, Apple abandonne du jour au lendemain tous ses connecteurs propriétaire pour faire place à l'USB et au Firewire 400. Au final, ils ont démocratisé mieux que personne ce connecteur mal connu et peux utilisé !
L'histoire se répètera-elle ? C'est à souhaiter car un tel connecteur est une aubaine pour bon nombre d'entre nous. Il faudra voir avec les périphériques compatibles mais imaginez un dock pour portable ou il vous suffit de connecter ce seul câble et l'alimentation pour être connecter à tous vos périphériques ?
PHP 5.2.17 et Debian
PHP 5.2.17 est sortie le 6 Janvier 2011 et les utilisateurs de Debian Lenny n'auront pas d'autre choix que de recompiler à la main pour avoir droit aux dernières corrections.
Étant développeur web, je m'attend à ce que les dernières versions des logiciels que j'utilise puissent être mis à jour rapidement. En effet, il n'est pas nécessaire d'avoir les mises à jour dans l'heure qui suit, mais si le délais était un peux plus cours cela aiderais beaucoup de monde.
Depuis quelques jours la version Squeeze de Debian est sortie mais là aussi la version de PHP n'est pas la dernière (5.3.3 sur les dépôts alors que la 5.3.5 est disponible).
Si certain trouve que j'exagère, il est possible que oui. Mais le temps d'attente des mises à jour pénalise parfois les utilisateurs. Et même avec beaucoup de bonne volonté et malgrès le fait que je suis développeur, je n'ai pas l'intention de recompiler PHP à chaque nouvelle version pour la distribution Debian.
D'autre diront, pourquoi crier au loup ? Tous le monde sait ça !
Pas moi et je viens d'être confronté au fait que je suis bloqué sur PHP 5.2.6 sur le serveur alors que j'ai 5.3.3 sur mon poste de développement. Et que forcément j'ai utilisé des fonctions et argument de fonction qui n'existe pas dans la version du serveur. Cela m'oblige à faire du code conditionnel avec des réactions différentes selon la version de PHP. Cela ne m'était jamais arrivé auparavant et c'est très frustrant.
Maintenant, si il existe un dépôt utilisable sur Debian permetant de mettre à jour PHP rapidement avec les dernière version, je suis preneur.
Je prend également, si quelqu'un à une procédure simple pour compiler et installer PHP tout en mettant à jour la version de Debian. Je n'aime pas avoir deux versions d'une même logiciel sur un serveur.
Étant développeur web, je m'attend à ce que les dernières versions des logiciels que j'utilise puissent être mis à jour rapidement. En effet, il n'est pas nécessaire d'avoir les mises à jour dans l'heure qui suit, mais si le délais était un peux plus cours cela aiderais beaucoup de monde.
Depuis quelques jours la version Squeeze de Debian est sortie mais là aussi la version de PHP n'est pas la dernière (5.3.3 sur les dépôts alors que la 5.3.5 est disponible).
Si certain trouve que j'exagère, il est possible que oui. Mais le temps d'attente des mises à jour pénalise parfois les utilisateurs. Et même avec beaucoup de bonne volonté et malgrès le fait que je suis développeur, je n'ai pas l'intention de recompiler PHP à chaque nouvelle version pour la distribution Debian.
D'autre diront, pourquoi crier au loup ? Tous le monde sait ça !
Pas moi et je viens d'être confronté au fait que je suis bloqué sur PHP 5.2.6 sur le serveur alors que j'ai 5.3.3 sur mon poste de développement. Et que forcément j'ai utilisé des fonctions et argument de fonction qui n'existe pas dans la version du serveur. Cela m'oblige à faire du code conditionnel avec des réactions différentes selon la version de PHP. Cela ne m'était jamais arrivé auparavant et c'est très frustrant.
Maintenant, si il existe un dépôt utilisable sur Debian permetant de mettre à jour PHP rapidement avec les dernière version, je suis preneur.
Je prend également, si quelqu'un à une procédure simple pour compiler et installer PHP tout en mettant à jour la version de Debian. Je n'aime pas avoir deux versions d'une même logiciel sur un serveur.
Symfony et le reverse proxy Apache
Avez-vous déjà utilisé une application développé avec symfony derrière un reverse proxy géré par Apache 2 ?
Pour ma part, oui et il m'arrive un problème récurent avec le plugin sfDoctrineGuardPlugin.
En effet après l'identification il redirige l'utilisateur. Le choix de la redirection ce fait dans cet ordre :
Comme le port du serveur Apache interne n'est pas le 80, il tente de rediriger l'utilisateur sur ce port. Par exemple, si le port interne est le 88 et que l'URL du site est "www.test.dlt", je vais me retrouver avec l'URL suivante : "www.test.dlt:88". Ce qui est faux car l'URL pointe vers le reverse proxy Apache qui attend les connexions sur le port 80.
Pour ma part j'ai réglé le problème en définissant la clé dans app.yml à "accueil/index".
Pour ma part, oui et il m'arrive un problème récurent avec le plugin sfDoctrineGuardPlugin.
En effet après l'identification il redirige l'utilisateur. Le choix de la redirection ce fait dans cet ordre :
- Il tente de récupérer l'url enregistré dans le fichier app.yml sous la clé : sf_guard_plugin_success_signin_url
- Il renvoie vers la page "référer".
- Il renvoie vers la route "@homepage"
Comme le port du serveur Apache interne n'est pas le 80, il tente de rediriger l'utilisateur sur ce port. Par exemple, si le port interne est le 88 et que l'URL du site est "www.test.dlt", je vais me retrouver avec l'URL suivante : "www.test.dlt:88". Ce qui est faux car l'URL pointe vers le reverse proxy Apache qui attend les connexions sur le port 80.
Pour ma part j'ai réglé le problème en définissant la clé dans app.yml à "accueil/index".
jeudi 17 février 2011
Apache et les VirtualHost SSL
Ajourd'hui, je vais vous montrer comment configurer plusieurs VirtualHost SSL sur Apache.
Cela fait plus de 8 mois que je me bat avec cette configuration impossible à mettre en place.
Prérequis : Apache 2.2.9 minimum, mod_ssl, openssl
La première chose à faire est de se créer sont certificat. Pour cela j'ai suivi cette procédure. Le seul point à changer est pour le "Common name", il faut mettre "*.mondomaine.tld". Cela permet d'avoir un certificat valable pour tous les sous domaine.
Ensuite, configurer les VirtualHost comme si cela était des hôtes sans SSL (sur le port 443 tout de même).
Pour la directive "ServerName", précisier le port après le nom du serveur (ex: test.mondomaine.tld:443).
Ajoutez la configuration SSL :
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
Puis redémarrer Apache et cela fonctionne.
Il faut répéter la manœuvre autant de fois qu'il est nécessaire pour vos configurations.
Dans le cas d'un sous domaine avec un certificat wildcard vous n'avez pas besoin de changer la configuration SSL. Sinon, il suffit de choisir le bon certificat et la bonne clé.
Cela fait plus de 8 mois que je me bat avec cette configuration impossible à mettre en place.
Prérequis : Apache 2.2.9 minimum, mod_ssl, openssl
La première chose à faire est de se créer sont certificat. Pour cela j'ai suivi cette procédure. Le seul point à changer est pour le "Common name", il faut mettre "*.mondomaine.tld". Cela permet d'avoir un certificat valable pour tous les sous domaine.
Ensuite, configurer les VirtualHost comme si cela était des hôtes sans SSL (sur le port 443 tout de même).
Pour la directive "ServerName", précisier le port après le nom du serveur (ex: test.mondomaine.tld:443).
Ajoutez la configuration SSL :
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
Puis redémarrer Apache et cela fonctionne.
Il faut répéter la manœuvre autant de fois qu'il est nécessaire pour vos configurations.
Dans le cas d'un sous domaine avec un certificat wildcard vous n'avez pas besoin de changer la configuration SSL. Sinon, il suffit de choisir le bon certificat et la bonne clé.
Inscription à :
Articles (Atom)