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.
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 ;-)
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.
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 ;-)
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 ;-)
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.
Chez amen.fr, il y a un pack web nom+ a 12€ HT par an avec 2Go d'espace web et une adresse mail. C'est que du web statique mais c'est parfois pas plus mal, tu dors tranquille car cela tourne tout seul ;-)
Java prône une organisation basée sur les noms de domaine des projets. C'est idiot. Le CPAN de Perl est organisé autour des thématiques. Lorsqu'un domaine émerge, tous les projets contribuent et le sous (et les sous) domaine(s) prennent de l'ampleur. Par exemple Moose:: DBI:: POE:: etc.
Bref, le CPAN est un réseau hiérarchique collaboratif constructif alors qu'avec Java, tu pioches des JAR à droite et à gauche...
Un langage à la Eiffel en plus simple et sans la covariance : Sather !
Sather a presque tout : des types mutable ou immutable clairs. Un arbre d'héritage simple ou seul les feuilles peuvent être instanciés et ou l'on peux surtypé (chose fondamentale que l'on presque nulle pars)... Sather a aussi la notion d'iterator intégré dans les classes sous forme de coroutine, cela permet de faire des boucles ayant un taux d'erreur très faible et d'une clarté limpide (rien à voir avec les bouses de classes parallèles du C++).
Il manque une petite mise à jour de l'ensemble ;-) A mon avis, il faut aussi un environnement parallèle de base fiable (pSather ?) et surtout, on a besoin de nos jours de pouvoir intégrer dans le langage la programmation événementielle, genre les slots de Qt ? Il est aussi important de pouvoir programmer en utilisant des fonctions non bloquantes sans faire des usines à gaz... J'aime bien aussi le framework Coro de Perl qui pourrait être une bonne base d'inspiration.
Le langage doit permettre de faire des programmes parallèles de type calcul (MPI - Fortran - Performance) et de type serveur (exemple ejaberd - Erlang - Robustesse)...
Si on pars sur un langage typé (compilé), il faut aussi la compilation modulaire (chose que ne faisait pas le compilateur Sather) et évidement des espaces de noms... Donc il faut aussi un CPAN structuré et central comme le CPAN (pas une hiérarchie idiote en reverse DNS comme le java).
Enfin, le langage doit normaliser le mappage des objets dans le format ELF afin de faciliter les passerelles avec les autres langages, notamment le C !
On envoi un mail au webmaster ou au contact de la page. Normalement, dans ce genre de formulaire, on est sensé je pense utiliser des formats de PDF "stable" (1.2, 1.4...).
On me dira que ça ne change pas grand chose, que ça soit l'état qui finance la CNM (via le budget global), ou
que l'argent soit directement rediriger à partir de nos fournisseurs d'accès, néanmoins, sur le principe, cela
me gène
Le problème des impôt fléchés, c'est que cela reviens à la dîme du moyen âge. C'est mauvais. Un des grands principe de l'état français est le budget global, la répartition est ensuite votés tous les ans par le parlement.
Ensuite, financer la culture donc la musique a toujours été une mission en partie réalisé par l'état. Donc, ce n'est pas choquant de le re-formaliser et de mettre à jour les structures /a priori/...
Ce qui est choquant, c'est la durée des droits d'auteur qui tue en grande partie la création. 50 ans, 70 ans... C'est beaucoup trop long. S'il y avait quelques choses à modifier, c'est ce point là qui me semble majeur et revenir à des durées bien plus raisonnable.
Avez vous essayer sur des partitions de 15To par exemple ayant des millions de fichiers ? Cela tiens ? Ce qui m'ennuie avec btrfs, c'est qu'il n'y a pas encore de fsck je crois...
Sinon, n'étant pas sur que lsyncd tiennent la charge sur des millions de fichiers, ce serait effectivement bien de pouvoir faire un snapshot sur l'original qui garde un journal des fichiers modifié/ajouté/supprimé afin de lancer le backup sur ces seuls fichiers et avoir encore un gain très important sur le temps passé à la sauvegarde. Je ne sais pas si btrfs fait cela (ou ZFS).
Évidement, il faut alors contrôler ensuite une partie aléatoire des données pour être sur qu'elle sont toujours bonne, de l'ordre de 1%. C'est comme cela que fait backuppc lorsqu'on utilise l'option --checksum-seed de rsync (voir option RsyncCsumCacheVerifyProb).
J'ai essayé backuppc sur une partition de 10To ayant des millions de fichier, c'est inutilisable. Backuppc marche bien pour les homes des utilisateurs.
Ca tient la charge ? J'avais tenté la même chose avec LVM il y a quelques années mais c'était ingérable du fait de LVM...
Un point important serait lors des backup de ne sauver que les block qui ont été modifié depuis le dernier backup... Comment avoir cette liste des block modifié sur le serveur de base, via un snapshot LVM :
lvmsync semble intéressant ! J'ai pas encore testé. Il y a juste un truc qui me chiffonne, il faut faire un snapshot LVM sur la source juste pour avoir la liste des block modifié... LVM fait bien plus que cela donc ralentis... Il serait intéressant d'avoir un snapshot LVM qui liste juste les block modifié sans dupliqué ces block. On n'aurait alors aucune perte et performance quasiment. Je ne sais pas si cela existe...
Sinon, plutôt que LVM, peut être qu'il est possible d'avoir la liste des fichiers modifiés via lsyncd et de n'envoyer à rysnc ou rdiff-backup que cette liste histoire de gagner encore du temps ! Je ne sais pas comment se comporte lsyncd sur une grosse arborescence de millions de fichiers sur 30To par exemple...
Si je comprends bien, tu veux faire un rdiff-backup au dessus d'un rdiff-backup ! sachant que l'algo sous jacent est le même que rsync (librsync), pourquoi ne pas faire bêtement un rsync entre dépôt 1 et dépôt 2 à la fin ? Sur le dépôt 2, tu auras tout l'historique qu'il y a sur le dépôt 1...
Par simplicité, on remonte effectivement au . initial. Sur mes serveur DNS, le domaine en .42 fonctionne ! Il est très facile de nos jours de faire un paquet DNSROOT qui aurait les serveurs racines des différents pays et serait régulièrement remis à jour, un peu comme TZDATA...
Bref, si jamais les américains coupe une nom de domaine d'un pays, ce sera la fin du . sommital, et la parade pour les FAI sera très rapide à mettre en place. Je pense que le scénario est guère probable !
Et qu'est-ce que vous voulez ? Un espace sans règle ni loi ?
On vit sous le régime des états nations. Tout n'est pas idéal mais je réfère cela à celui des entreprises nations qui est une voie possible ;-)
Si on est en France, on applique le droit français et s'il est dépassé, il faut essayer de le mettre à jour. C'est difficile et long mais tout est possible... Le .fr applique le droit Français, je ne vois pas ou est le problème.
Je me souviens des débuts du web, le droit français s'appliquait déjà. Je me souviens d'une descente de la DST chez nous car un de nos étudiants nous avait piraté ! Ce couillon, s'il avait été Canadien, il n'aurait jamais été embêté car les procédures inter-état étaient (sont toujours ?) bien trop lourde.
Il ne faut pas mélanger liberté d'expression et zone de non droit... Le web peut être soumis au droit sans qu'on tombe forcément dans big brother...
[^] # Re: Garde fou
Posté par Sytoka Modon (site web personnel) . En réponse au message Déplacer mes fichiers dans un dossier temporaire avant effacement avec rm. Évalué à 4.
Bash fait (faisait c'est sur) des conneries.
Par exemple :
efface tout sauf les fichiers . car * en premier veut dire tout sauf le point.
MAIS
efface tout et remonte l'arborescence car il prend . mais aussi .. ce couillon !
Solution qui marche très souvent
# Grenouille RITA
Posté par Sytoka Modon (site web personnel) . En réponse au message Capteur et/ou enregistreur de température. Évalué à 1.
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.
[^] # Re: Ca chiffre à?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Quelles solutions adopter pour améliorer un parc existant ? La suite !. Évalué à 2.
Puisqu'il y a un serveur de meta données, le 'ls' devrait être super rapide ?
[^] # Re: Ah les numéros de version...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 2.
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 ;-)
[^] # Re: J'aimerais
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 2.
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.
[^] # Re: Mes idéaux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
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...
[^] # Re: J'aimerais
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
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 ;-)
[^] # Re: Accès aux fichiers
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche ownCloud 3. Évalué à 3.
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...
[^] # Re: J'aimerais
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
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.
[^] # Re: pour moi
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
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 ;-)
[^] # Re: J'aimerais
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
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...
...
[^] # Re: Mes idéaux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
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 ;-)
[^] # Re: pour moi
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 2.
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 !
[^] # Re: Mes idéaux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
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.
[^] # Re: ma vie
Posté par Sytoka Modon (site web personnel) . En réponse au message Offre d'hébergement adaptée à quelques pages HTML ?. Évalué à 2.
Chez amen.fr, il y a un pack web nom+ a 12€ HT par an avec 2Go d'espace web et une adresse mail. C'est que du web statique mais c'est parfois pas plus mal, tu dors tranquille car cela tourne tout seul ;-)
[^] # Re: Sather
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 6.
Le problème n'est pas la !
Java prône une organisation basée sur les noms de domaine des projets. C'est idiot. Le CPAN de Perl est organisé autour des thématiques. Lorsqu'un domaine émerge, tous les projets contribuent et le sous (et les sous) domaine(s) prennent de l'ampleur. Par exemple Moose:: DBI:: POE:: etc.
Bref, le CPAN est un réseau hiérarchique collaboratif constructif alors qu'avec Java, tu pioches des JAR à droite et à gauche...
# Sather
Posté par Sytoka Modon (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 5.
Un langage à la Eiffel en plus simple et sans la covariance : Sather !
Sather a presque tout : des types mutable ou immutable clairs. Un arbre d'héritage simple ou seul les feuilles peuvent être instanciés et ou l'on peux surtypé (chose fondamentale que l'on presque nulle pars)... Sather a aussi la notion d'iterator intégré dans les classes sous forme de coroutine, cela permet de faire des boucles ayant un taux d'erreur très faible et d'une clarté limpide (rien à voir avec les bouses de classes parallèles du C++).
http://www.gnu.org/software/sather/docs-1.2/tutorial/iterators.html
Il manque une petite mise à jour de l'ensemble ;-) A mon avis, il faut aussi un environnement parallèle de base fiable (pSather ?) et surtout, on a besoin de nos jours de pouvoir intégrer dans le langage la programmation événementielle, genre les slots de Qt ? Il est aussi important de pouvoir programmer en utilisant des fonctions non bloquantes sans faire des usines à gaz... J'aime bien aussi le framework Coro de Perl qui pourrait être une bonne base d'inspiration.
http://search.cpan.org/dist/Coro/Coro/Intro.pod
Le langage doit permettre de faire des programmes parallèles de type calcul (MPI - Fortran - Performance) et de type serveur (exemple ejaberd - Erlang - Robustesse)...
Si on pars sur un langage typé (compilé), il faut aussi la compilation modulaire (chose que ne faisait pas le compilateur Sather) et évidement des espaces de noms... Donc il faut aussi un CPAN structuré et central comme le CPAN (pas une hiérarchie idiote en reverse DNS comme le java).
Enfin, le langage doit normaliser le mappage des objets dans le format ELF afin de faciliter les passerelles avec les autres langages, notamment le C !
# webmaster
Posté par Sytoka Modon (site web personnel) . En réponse au message Putain de "modernisation" à la con (ou encore: ouvrir un PDF provenant de gouv.fr). Évalué à 8.
On envoi un mail au webmaster ou au contact de la page. Normalement, dans ce genre de formulaire, on est sensé je pense utiliser des formats de PDF "stable" (1.2, 1.4...).
# Budget global
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vous avez internet, vous financez la musique française. Évalué à 6.
Le problème des impôt fléchés, c'est que cela reviens à la dîme du moyen âge. C'est mauvais. Un des grands principe de l'état français est le budget global, la répartition est ensuite votés tous les ans par le parlement.
Ensuite, financer la culture donc la musique a toujours été une mission en partie réalisé par l'état. Donc, ce n'est pas choquant de le re-formaliser et de mettre à jour les structures /a priori/...
Ce qui est choquant, c'est la durée des droits d'auteur qui tue en grande partie la création. 50 ans, 70 ans... C'est beaucoup trop long. S'il y avait quelques choses à modifier, c'est ce point là qui me semble majeur et revenir à des durées bien plus raisonnable.
[^] # Re: Même pas peur…
Posté par Sytoka Modon (site web personnel) . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 3.
Avez vous essayer sur des partitions de 15To par exemple ayant des millions de fichiers ? Cela tiens ? Ce qui m'ennuie avec btrfs, c'est qu'il n'y a pas encore de fsck je crois...
Sinon, n'étant pas sur que lsyncd tiennent la charge sur des millions de fichiers, ce serait effectivement bien de pouvoir faire un snapshot sur l'original qui garde un journal des fichiers modifié/ajouté/supprimé afin de lancer le backup sur ces seuls fichiers et avoir encore un gain très important sur le temps passé à la sauvegarde. Je ne sais pas si btrfs fait cela (ou ZFS).
Évidement, il faut alors contrôler ensuite une partie aléatoire des données pour être sur qu'elle sont toujours bonne, de l'ordre de 1%. C'est comme cela que fait backuppc lorsqu'on utilise l'option --checksum-seed de rsync (voir option RsyncCsumCacheVerifyProb).
[^] # Re: backuppc ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 2.
J'ai essayé backuppc sur une partition de 10To ayant des millions de fichier, c'est inutilisable. Backuppc marche bien pour les homes des utilisateurs.
rdiff-backup résoud le même problème en 15min...
[^] # Re: Même pas peur…
Posté par Sytoka Modon (site web personnel) . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 3.
Ca tient la charge ? J'avais tenté la même chose avec LVM il y a quelques années mais c'était ingérable du fait de LVM...
Un point important serait lors des backup de ne sauver que les block qui ont été modifié depuis le dernier backup... Comment avoir cette liste des block modifié sur le serveur de base, via un snapshot LVM :
http://serverfault.com/questions/27397/sync-lvm-snapshots-to-backup-server
http://theshed.hezmatt.org/lvmsync/
lvmsync semble intéressant ! J'ai pas encore testé. Il y a juste un truc qui me chiffonne, il faut faire un snapshot LVM sur la source juste pour avoir la liste des block modifié... LVM fait bien plus que cela donc ralentis... Il serait intéressant d'avoir un snapshot LVM qui liste juste les block modifié sans dupliqué ces block. On n'aurait alors aucune perte et performance quasiment. Je ne sais pas si cela existe...
Sinon, plutôt que LVM, peut être qu'il est possible d'avoir la liste des fichiers modifiés via lsyncd et de n'envoyer à rysnc ou rdiff-backup que cette liste histoire de gagner encore du temps ! Je ne sais pas comment se comporte lsyncd sur une grosse arborescence de millions de fichiers sur 30To par exemple...
# tcp sur tcp
Posté par Sytoka Modon (site web personnel) . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 3.
Si je comprends bien, tu veux faire un rdiff-backup au dessus d'un rdiff-backup ! sachant que l'algo sous jacent est le même que rsync (librsync), pourquoi ne pas faire bêtement un rsync entre dépôt 1 et dépôt 2 à la fin ? Sur le dépôt 2, tu auras tout l'historique qu'il y a sur le dépôt 1...
[^] # Re: La décentralisation est déjà effective
Posté par Sytoka Modon (site web personnel) . En réponse au journal De la possibilité de décentralisation de la gestion des noms de domaine. Évalué à 3.
Par simplicité, on remonte effectivement au . initial. Sur mes serveur DNS, le domaine en .42 fonctionne ! Il est très facile de nos jours de faire un paquet DNSROOT qui aurait les serveurs racines des différents pays et serait régulièrement remis à jour, un peu comme TZDATA...
Bref, si jamais les américains coupe une nom de domaine d'un pays, ce sera la fin du . sommital, et la parade pour les FAI sera très rapide à mettre en place. Je pense que le scénario est guère probable !
[^] # Re: La décentralisation est déjà effective
Posté par Sytoka Modon (site web personnel) . En réponse au journal De la possibilité de décentralisation de la gestion des noms de domaine. Évalué à 5.
Et qu'est-ce que vous voulez ? Un espace sans règle ni loi ?
On vit sous le régime des états nations. Tout n'est pas idéal mais je réfère cela à celui des entreprises nations qui est une voie possible ;-)
Si on est en France, on applique le droit français et s'il est dépassé, il faut essayer de le mettre à jour. C'est difficile et long mais tout est possible... Le .fr applique le droit Français, je ne vois pas ou est le problème.
Je me souviens des débuts du web, le droit français s'appliquait déjà. Je me souviens d'une descente de la DST chez nous car un de nos étudiants nous avait piraté ! Ce couillon, s'il avait été Canadien, il n'aurait jamais été embêté car les procédures inter-état étaient (sont toujours ?) bien trop lourde.
Il ne faut pas mélanger liberté d'expression et zone de non droit... Le web peut être soumis au droit sans qu'on tombe forcément dans big brother...