Sytoka Modon a écrit 4551 commentaires

En pratique, j'ai un certain nombre de site web accessible en interne via http sans mot de passe (si on veut que les personnes lisent un peu les doc, les mots de passe, c'est chiant...).

Ils sont accessible via reverse proxy en https en externe mais l'URL est quelque peu différentes... Donc via les directives d'Apache, je ré-écris en grande partie les URL

A noter que sous debian squeeze, php5 impose encore le mode prefork (apache2-mpm-prefork) ce qui n'est plus le cas de Perl... Ce php, quel boulet ;-)

C'est un filtre qui te permet de ré-écrire soit en entrée, soit en sortie. Dans le cas d'un proxy, cela peut être bien pratique !

Je pense qu'a terme, ce module va m'être bien pratique ;-)

On pointe du doigt l'IRAN depuis des années (un peu plus de 30 ans) comme le grand méchant de la région alors qu'il y a toujours eu des femmes à l'université et des femmes non voilées la bas... De l'autre coté, on ne dis jamais rien sur l'Arabie Saoudite qui est une des pires dictatures islamiques à ma connaissance, au contraire, selon nos hommes d'état, ce sont des gentils ! Pas étonnant que les discours de nos représentants soient de moins en moins crédible...

Le bon coté des choses est que le régime de la royauté est complètement débile, par définition, ce sont des croulants qui accèdent au trône. Normalement, le régime devrait s'effondrer de lui même prochainement, le plus probable par un coup d'état interne !

Si on veut un système qui fait tout, de manière cohérente, maintenable dans le temps, sur, etc. cela signifie en pratique que le projet est structuré en module le plus orthogonal possible avec une API claire, documenté et qui ne change pas tous les quatre matins.

En gros, cela reviendrait à terme à faire remonter dans LVM, le système RAID... petit à petit les API et les algorithmes pour les faire partager entre tous les systèmes de fichiers.

Il y a déjà plusieurs système de RAID1 dans le noyau... Il n'est pas impossible qu'à terme, tous ces systèmes convergent et s'unifient.

Enfin, c'est du java alors dans un wiki, ca va ramer fort ;-)

J'ai un nom de site web en www.labo.ville.cnrs.fr, avec les nouvelles fonctionalités des navigateurs, je me retrouve dans la barre de navigation en cnrs.fr !

Mon site n'est pas du tout un site officiel du central CNRS !

La politique des navigateurs pousse aussi a tout mettre en vrac sous la racine. C'est complètement idiot mais ça doit faire très web4 ;-)

Punycode est un algo qui permet de transformer un chaine UNICODE (donc UTF8) en ASCII. Cela permet de visuellement voir le phishing par exemple.

Bref, ASCII -> UTF8 -> Moulinette punnycode -> ASCII

C'est beau ;-)

PS : j'ai rendu hier deux domaines en .eu et .org qui ne servait à rien car le .fr suffisait... C'est dingue le nombre de courriel qu'on reçoit chaque année pour acheter tous les noms de domaines voisins du siens.

Le passage en UTF8 des DNS est surtout une question de rente pour le moment. Devant les avantages, il y a surtout le fait de rendre les trucs complètement imbitable et bien moins mondial. Je fais comment pour rentrer une URL coréenne ? Comment peux t'on se passer des moteurs de recherche puisqu'on ne pourra plus taper les URL ?

Les chiffres de 0 à 9 sont désormais universels je pense... En pratique, il y a de même des petites lettres de a à z...

Avec le _ - . @ cela fait 40 symboles commun pour que tout homme puisse naviguer de base n'importe ou.

Bref, on recule à mon sens !

Un forge type Redmine ou Trac ?

On boulot, on utilise SPIP (avec le kit CNRS), on est pas mal à séparer la partie publique de la partie privé en bloquant sur http/https et en bloquant une partie de /ecrire depuis le http dans Apache... Pas très catholique mais très efficace !

D'ailleurs, je trouve qu'un peu tous ces CMS que 'ai vu sont mal fichus à ce niveau là... La prise en compte des deux ports est mal gérés (pour ne pas dire pas gérés).

Un ordre d'idée du prix (je n'ai rien vu sur le web et je n'aime pas les boites dont les prix ne sont pas affichés) ?

Bash fait (faisait c'est sur) des conneries.

Par exemple :

rm -rf *

efface tout sauf les fichiers . car * en premier veut dire tout sauf le point.

MAIS

rm -rf .*

efface tout et remonte l'arborescence car il prend . mais aussi .. ce couillon !

Solution qui marche très souvent

rm -rf .[a-Z]*

On trouve une grenouille assez sympa ici

http://froggyhome.com/index.php

Ca marche sous linux. Il y a un soft non officiel frogd qui fonctionne dans mon labo très bien depuis des années... J'en ai une qui tourne depuis 7 ans non stop sans aucune intervention.

A noter que la boite se trouve à Annecy si mes souvenirs sont bon. C'est conçu et fabriqué la bas.

Puisqu'il y a un serveur de meta données, le 'ls' devrait être super rapide ?

mbox, c'est bien pour les archives... Cela fait des années que le support Maildir n'est pas à l'ordre du jour. Ne parlons pas du compactage absolument incompréhensible par mes utilisateurs. A ce sujet, quelqu'un sais comment lancer le compactage en ligne de commande avec un beau nice -18 devant ;-)

Je répond aux deux...

Un simple diff montre qu'il y a duplication.

Sinon, effectivement, dans certain cas particulier, une séparation peut être utile comme tu l'indiques. En Fortran, il suffit d'utiliser le préprocesseur avec un #include pour arriver au même résultat. Ces fichiers sont assez rare et portent l'extension .F90 plutôt que .f90 donc bien visible... C'est évidement un contournement mais à mon sens il vaut mieux cela sur quelques fichiers que d'emmerder le programmeur sur 99% des autres fichiers ;-)

Ceci dis, je suis très sceptique sur les "friend methods"... Une doc claire avec un API propre me semble le mieux. Vouloir faire des API pour machin mais pas pour truc me semble pas tendre vers de la programmation claire.

l'approche Fortran ("conservatrice")

Je ne peux pas laisser passer cela. A chaque nouvelle version, Fortran déclare des structures obsolètes... Fortran est un des plus vieux langage et un des langages qui a le plus évolué tant sur le fond que sur la forme ! Python a coté a les vertèbres bloquées ;-)

Juste trois exemples, Fortran 90 a amené le free form (on écrit comme dans les autres langages, plus d'histoire de numéro de colonne), Fortran 2003 a amené l'héritage simple (Fortran est un langage objet ce que n'est pas le C) et la version 2008 introduit le co-array, c'est à dire en gros des tableaux qui s'étendent sur un cluster... On aime ou on n'aime pas mais il ne faut pas dire que c'est conservateur...

En Fortran 90, tes modules sont coupés en deux parties, une première ou tu fixes les dépendances (use...) et tu déclare ce qui est public et privé puis une seconde ou tu fais l'implémentation.

Ensuite, via une moulinette, il est assez facile d'extraire du fichier de la doc qui te donne les en têtes des fonctions et mouline cela sous forme de man. Je faisais à l'époque "man Mon_Module" et hop, toute la doc du module. Bref, un environnement très lié au shell et pratique comme avec les packages Perl ;-)

Donc pour moi, dupliquer à la main les headers est une mauvaise chose. La doc intégré doit faire partie du langage (cf le POD du Perl) et les outils doivent suivre. De ce coté là, Ada a un train de retard mais il a le droit d'évoluer dans le futur ;-)

Il y a un projet que je suis en parallèle : WebDavCGI

http://webdavcgi.sourceforge.net/

L'idée est de faire tourner le script CGI sous l'identité de l'utilisateur. Tu peux alors partager ton home car tous les fichiers sont lus et écrit sous ton nom. Bref, les droits UNIX. C'est beaucoup plus simple comme application mais pour faire du "dropbox", c'est suffisant ;-)

C'est un peu le soucis des appli web, en règle général, tout tourne sous un seul compte et cela n'utilise pas du tout la couche de droit UNIX. C'est un peu du stockage type FAT32 et il faut faire 100% confiance dans la couche logiciel web. Or, il n'y a pas une application web qui ne soit pas une passoire potentielle vu la complexité de ce genre d'application...

De plus en plus de langage dynamique permettent de déclarer le typage des variables. C'est facultatif mais permet à l'interpréteur de faire quelques optimisations. Perl prends clairement cette voie.

Pourquoi veux tu que j'impose quelque chose, nous sommes dans une discution ;-)

Je pense que tout le langage de base doit être compatible pour le parallélisme et les fonctions systèmes non bloquantes. Ensuite, le langage doit privilégier les variables immutables plus simple à gérer et posant moins de problème de parallélisme. On doit avoir des boucles d'évènement intégrés dans le langage. A ce niveau là, je pense qu'Erlang montre bien une voie.

Bref, il faut arriver à gérer 50 000 processus parallèle simplement et de manière efficace sur un cluster. On sais faire cela aujourd'hui avec MPI qui utilise l'envoi de message... Encore une fois, les objets immutables sont d'une grande aide et Erlang les a mis au coeur du langage.

Une autre voie sont les fonctions pures de Fortran90. Mais cela me semble quand même très dédié calcul et peu généralisable...

Bref, je ne suis pas un architecte des langages. Je dirais qu'avec les interfaces graphiques, le web2 et le nombre de plus en plus élevé de coeur que nous avons sur une machine, il faut un langage objet parallèle et événementiel qui intègre de base une API efficace sur les tableaux et les tables de hachage. Avec cela, on a de quoi s'amuser pour quelques années ;-)

En conclusion, il faudrait Sather dans lequel on introduit toutes les bonnes idées d'Erlang ;-)

Personnellement, je préfère le begin-end de bash, pascal, fortran, ada aux accolades {} de la tendance C. Je ne pense pas que le frein soit là.

Ada est verbeux. Je pense que les langages de demain ne doivent plus avoir de header. C'est une erreur, de la duplication de code qui ne sers à rien. Il y a plus de 20 ans, Fortran 90 a montré la voie (je ne sais pas s'il y en a un autre avant) en générant automatiquement les fichiers headers à partir du corps du fichier (les fichiers .mod en fortran 90).

Un autre soucis est que la mappage avec les objets ELF n'est pas normalisé. Je ne comprends pas pourquoi les langages refusent de normaliser cela parce que cela permet d'avoir des compilateurs compatible (on a le même problème avec le Fortran 90).

Le langage Ada a été fait pour les militaires. Psychologiquement, cela a tué le langage et continue de le tuer pour bon nombre de gens...

...

Je pense que gfortran a évidemment un mode de compatibilité F77 mais à vrai dire, je ne veux plus voir du F77 car le Fortran moderne, c'est quand même autre chose...

Sinon, il fallait pas prendre Python mais Perl, mes programmes réalisés il y a 15 ans marche toujours sans aucune modification aujourd'hui ;-)

On parle ici du langage pour demain !

Qui a encore aujourd'hui une machine mono-coeur ? Le langage doit être parallèle dans sa conception, les appels systèmes doivent être non bloquant afin de pouvoir être mis dans des boucles d'évènement. Un certain nombre de structure doivent être clairement immutable ce qui simplifie le travail sur la mémoire.

Le GC travaille donc en tâche de fond, en fait un peu comme l'OS. A par dans la problématique du temps réel, qui se plaint de l'OS de nos jours ?

Je ne vois pas l'intérêt de refaire encore un autre langage basé sur une hypothèse de mono-processus de nos jours !

Le Fortran évolue rapidement et profondément... Enfin, plus que le C ;-) Comme dans tous les langages, a chaque version, ils annoncent qui suppriment quelques anciennes formes afin de nettoyer le langage de vieux truc. Le Fortran d'aujourd'hui n'a plus grand chose à voir avec le F77.