The Caribbean Weblog

Ce billet à été posté sur le GwadaLUG

Tout d'abord, il est inefficace d'essayer de convaincre de passer à GNU/Linux par le simple argument que c'est mieux, car en vérité ça n'est pas vrai partout. L'important est de trouver les situations où GNU/Linux est vraiment supérieur. Ou plutôt, que l'utilisateur lambda puisse déterminer quel système est plus adapté à l'utilisation qu'il a de son ordinateur. Pour se faire, il faut classer les arguments en fonction de leur champs d'applications. On pourrait donc avoir une classification de ce type : je suis un graphiste, je suis un développeur, je suis un utilisateur de base, je suis un joueur, je fais de la bureautique, etc. Déjà sur ces cinq catégories, il y en a deux où Linux c'est pas le meilleur (graphiste/joueur).

L'un des principaux buts de GwadaLUG apparait ici : informer. Informer ceux qui seront à coup sûr intéressé de la supériorité du libre dans leur catégorie, bien que ses principaux avantages sont présents dans toutes les catégories (liberté, gratuité, fiabilité, sécurité...).

Nous avons déjà résolu la question du pourquoi, maintenant il faut lister celle du "où".

Pas aux centres nerveux des réseaux, car c'est heureusement déjà le cas. Je pense en premier aux administrations (écoles, mairies...), qui payent avec notre argent des licenses couteuses (Windows, Office...) pour des besoins largement couverts par des logiciels libres. Le mouvement est déjà en marche, l'on pense tout de suite à la migration vers OpenOffice de la Gendarmerie nationale. Je féciliterais d'ailleurs le campus de Fouillole pour avoir installé Linux sur la quasi-totalité des PC de son parc. Mais je pense aussi aux entreprises et autres collectivités, mais il y a un temps pour tout.

Parce qu'il serait trop facile de jeter la pierre aux administrations, il faut aussi indiquer que les fournisseurs de celles-ci continuent vendent le matériel avec une license Windows. C'est aussi un point à s'occuper.

Pour ma part, je commence la rédaction d'un dossier invitant les écoles primaires et collèges de trois communes de Grande-Terre (sous l'autorité d'un service aux Abymes) à passer sous Linux.

PS: La première partie à honteusement été pompée du Fashion blog

EDIT: Suite

Après quelques brèves recherches, il semble que nul besoin était de réinventer (réécrire) la roue, car d'autres ont déjà effectué une énorme partie du travail.

Je pense en particulier à Pierre Drouin et Sophie Rioux :

Le premier qui propose une étude faite à une commission scolaire du Québec avec le soutien du ministère de l'éducation. Ce document titré "LINUX À L'ÉCOLE - CONTEXTE ET CONDITIONS D'IMPLANTATION" à quand même six ans d'ancienneté. Il faut donc tenir compte de la baisse des coûts matériels, et de l'évolution sensible des software libres présentés.

Rioux quant à elle nous gratifie de "Linux dans les écoles primaires et secondaires : état de la situation" de 83 pages (en deux parties, ici et ici) au total écrit de Novembre 2000 à Juin 2001.
Son rapport s'attaque entre autres aux aspects suivants :

• Dégager les raisons qui motivent la décision d'implanter Linux dans les écoles- Cerner l'accueil réservé à cette décision par les usagers dans les écoles concernées
• Vérifier comment se présente l'entretien de Linux, comparativement aux systèmes plus souvent utilisés dans le milieu scolaire
• Identifier les principaux avantages et inconvénients associés à l'utilisation de Linux.

Très peu d'intelligence suffit à l'adapter au contexte local. À utiliser en référence, avec le projet MILLE (encore canadien) et l'AbulÉdu.

Et ceux qui pensent que faire migrer des parcs entiers d'ordinateurs vers le logiciel libre relève du jamais vu seraient très surpris de lire les news de http://linuxfr.org , où l'on constate mois après mois, un mouvement définitif des administrations étrangères ou non, vers ces logiciels.

Du jamais vu en Guadeloupe ? Certainement, et cela serait un honneur pour nos décideurs de faire le deuxième pas.

À l'instant, j'entends la pluie qui tombe dehors, j'ouvre donc la fenêtre et éteint la lumière pour regarder ça, j'adore la nuit et le bruit vent de la pluie...
J'avance ma tête par la fenêtre quand des gouttes de pluie me tombent sur le visage : j'étais tellement surpris, mais genre "de l'eau qui tombe du ciel sur mon visage !" (!)

faut vraiment que je sorte plus souvent de chez moi...

Vous l'avez cherché, vous en avez rêvé (moi si en tous cas), la voici la voilà : Using prototype.js vx

C'est à vue de nez, la meilleure ressource online sur le sujet.

EDIT: Comme je le pensais, mon maitre l'avais déjà posté ici, la semi-traduction française en tous cas : http://www.electrolinux.com/traductions/prototype.js.html

\_o< ~coin coin~

J'ai updaté ma breezy, et outre les apps cassées (ce qui est normal pour une distro en testing) et xscreensaver qui veut me rendre épileptique, il y a plusieurs choses à déplorer.
- Gnome 2.13.91 : Déception due l'inutilité complète du bouton "Search" intégré à nautilus, pourtant longtemps attendu : il est lent (non utilisation de l'index ?!) et ne cherche pas dans le dossier courant ! Pour avoir utilisée cette fonctionnalité sous OS X il y a longtemps, je peut crier son utilité à qui veut bien l'entendre (ça va être les dev' de gnome cette fois ci)
- J'ai entendu dire que sur le cd live/d'install, xchat sera remplacé par xchat-gnome... Bien que je n'utilise pas xchat, je préfère croire à la plaisanterie... xchat-gnome est une horreur, tellement que je n'ai même pas envie de m'étaler sur son sujet...
- Détail, mais le remplacement de l'icone du "Moniteur réseau" (applet) pour faire "comme windows" est vraiment déplorable :/ (sous entendu, je préférais l'autre)

XGL

Beaucoup de bruit autour de ce petit bijou... et à raison : c'est époustouflant, même avec ma 9200SE :-)
L'effet de cube est très réussi, et le "glissement" de fenêtre inter-desktop est pas mal, les "fade", les minimize et compagnie sont très jolis. Il n'y a que la vraie transparence que je n'ai pu (voulu) tester, par flemme essentiellement, à cause de XGL justement :
=> Ça fatigue les yeux très vite, surtout la demi-seconde de flou après le déplacement d'une fenêtre dûe à l'effet "de goutte".
Ah oui au fait, c'est totalement inutile, donc tout à fait indispensable, surtout son côté tape à l'oeil qui séduira plus d'un (windowsien).
Pour ceux qui ça intéresse sous ubuntu, suivez le guide, simple and easy. (notez que quand je suis retourné à xorg, ça m'a quand même bousillé l'ouverture correcte du gnome-decoration-manager, j'ai du donc m'occuper des ~/.gnome*)

Serviteur.

Beaucoup de poésie dans cet anime, objectivement d'une grande qualité. Le film qui en a été tiré quand à lui ne décoit pas du tout : pour ma part, je le préfère à l'anime, pour sa qualité irréprochable.
Heureux de constater que l'ami Xethorn l'aime déjà, je ne puis que le conseiller à tous, c'est un must !!!

pUr3 1337 r0x0r1z1nG, mangez ça.

Parce qu'a force d'avoir des tests à effectuer en live sur vos pages avec prototype, vous avez surement créé un "RequestHandler(.php)", je veux dire par là : un fichier spécialement fait pour traiter les requetes Ajax.

La situation

Sur ce fichier donc, vous envoyez les tests avec Ajax.Request par exemple, vous obtennez le résultat, vous avisez en fonction du résultat retourné de votre fonction onSuccess:

Le problème

Le mieux serait de donner un exemple : Vous avez un formulaire, qui vérifie onBlur sur le champ pseudo que le pseudo tapé n'existe pas dans la base de donnée. On appelle donc Ajax.Request('/RequestHandler.php', method: 'post', postBody: action=verifPseudo&pseudo=pseudo.value); plus un callback onSuccess: par exemple, qui avertira l'internaute par innerHTML qu'il y a un soucis.
Jusqu'ici pas de soucis, l'user peut ignorer le message, notre bon PHP vérifiera encore à la validation. Et c'est bien là que ça commence à devenir ennuyeux :

pourquoi retaper le code PHP qui vérifie l'existence du pseudo dans la bdd ?

Dans notre cas, ça n'est pas important vu que le code tiens tranquillement sur une ligne, mais dans d'autres cas, serait-ce vraiment justifié de faire ainsi ?

La solution (j'ai pas trouvé mieux en tous cas)

L'idée serait donc de faire comme Ajax.Request (et Ajax.Updater), et d'envoyer la requete en post (ou get) à notre RequestHandler. Évidemment on en fera une fonction, vu que le code correspondant en php est (un peu) long :

<?php
function sendData($url, $method, $data){

	$pUrl = parse_url($url);
	$port = ($pUrl['port']) ? $pUrl['port'] : 80;
	
	
	$sock = fsockopen($pUrl['scheme'].$pUrl['host'], $port, $errno, $errstr, 10); 
	if(!$sock)
		die("$errstr ($errno)\n");
	
	fwrite($sock, strtoupper($method)." ".$pUrl['path']." HTTP/1.0\r\n");
	fwrite($sock, "Host: ".$pUrl['host']."\r\n");
	fwrite($sock, "Content-type: application/x-www-form-urlencoded\r\n");
	fwrite($sock, "Content-length: ".strlen($data)."\r\n");
	fwrite($sock, "Accept: */*\r\n");
	fwrite($sock, "\r\n");
	fwrite($sock, $data."\r\n");
	fwrite($sock, "\r\n");
	
	while ($str = trim(fgets($sock, 4096)))
	$headers .= "$str\n";
	
	while (!feof($sock))
	$body .= fgets($sock, 4096);
	
	fclose($sock);
	
	return $body;
} 
?>

• $url devrait être exprimé comme ceci : unmei.domtomconnection.com/headers/RequestHandler.php
  
• Le format de $data est le suivant 'variable1='.urlencode($_POST['variable1']).'&var2='.urlencode($_GET['var2'])
  
• N'oubliez pas que si vous faites une requête sur un serveur sécurisé, le port n'est plus 80 mais 443
  
• Dans ce cas, on utilise un timeout de 10s pour la connexion
  
• Le mieux serait de faire disparaitre le paramètre $url et le rendre interne à la fonction (ou utiliser une var globale valable pour cette fonction et les requests Ajax)
  

Donc vous faites une requete sur votre RequestHandler.php comme vous l'avez fait avec Ajax, et vous faites ce qu'il y a à faire en fonction du résultat.

(comment ça "inutile" ??)

Je me demande parfois si c'est normal... que je sois incapable de faire un site/partie d'un site en y mettant *moi-même* du contenu.
J'ai lu ici et là qu'effectivement :

(le programmeur) est toujours sûr de lui car il connaît les ficelles du html, du php, du javascript et accessoirement du Flash

Sur le plan technique, il n'y a rien à redire, c'est du travail de pro, chiadé à mort et digne de la NASA, mais il a oublié l'essentiel en cours de route : le fond. Et oui, entre coder et écrire, il faut choisir. Une seule chose l'intéresse: concevoir le site, bâtir le squelette, mais le remplir, ça l'emmerde. Quand il est fréquentable, il peut faire des merveilles dans une équipe mais tout seul, il est condamné d'avance.

Et c'est bien vrai.
Ya pas à dire, faut vraiment que je trouve le concept KITUE, parce que côté contenu, ça semble bel et bien condamné.

Pour le fun, je voulais mettre un plugin de calcul mathématique à mihiro (mon bot IRC, basé sur Botan), et j'étais naturellement confronté au souci de sécurité, étant donné que le calcul se fait par simple eval("\$resultat = ($calc);");... et pouf :

$calcul_presque_propre = preg_replace("/[^0-9+-\/*]/","",$texte);

Ceci supprime donc tout ce qui n'est pas chiffre, +, -, * ou /.

Mais quelle ne fut pas ma surprise de tenir une telle conversation (alors que tout le monde sait bien que 0318894273>0312547955) :

< Christophe971> !>0318894273-0312547955
< mihiro> 0318894273-0312547955 => -103758

...avant de découvrir que :

< Christophe971> !>42
< mihiro> 42 => 42
< Christophe971> !>042
< mihiro> 042 => 34

... et me voilà confronté à la terrible vérité : PHP traite tous les nombres commençant par zéro en base octale.

Et plutôt que de s'amuser à preg_match_all et à base_converter tout ce qu'il nous plait pas, un simple preg_replace répare ce terrible mal :

$calc = preg_replace("/([+-\/*]*)([0]+)([0-9]+)/","\\1\\3",$calcul_presque_propre);

Et voilà.