> Maintenant, qqsoit le language on peut écrire cradement (c'est moins vrai
> pour le python ;-). ça on est d'accord ...
Ben je suis désolé mais je n'y comprends rien en Python. J'ai même du balancé un site web en Zoppe pour faire du SPIP car Python me gonflait plus que la normale, et pourtant je déteste le PHP qui n'aurait jamais du exister car c'était du sous perl.
Non, le Python n'est pas mieux que les autres, il a ses fans mais il a aussi des inconvénients comme les autres.
Pour me changer les idées, je me suis mis à Erlang et là au moins, on change de perspective. C'est amusant.
Si Sather implémentait le retour multiple sans définir de type à l'aide de tuple. C'est exactement ce que tu as écrit (a la syntaxe type Eiffell près).
D'ailleurs, c'est marrant, dès qu'on parle Lissac ici, je sors mon Sather;-)
Faut arrêter de dire que le Perl est incompréhensible !
Je ne comprends rien aux programmes Java avec leur millions de lignes, leur millions de classe, les fichiers de conf XML de Tomcat ;-)
J'ai travaillé avec pas mal de personne qui n'avait jamais fait de Perl, qui n'en pensait que du mal mais qui avait fait du PHP ! Et bien, tous ont compris de suite les programmes ! Evidement, il y a quelques règles à respecter pour avoir du Perl lisible mais c'est pareil dans tous les langages.
Sinon, il y a des milliers de modules sur le CPAN et la doc est très claire pour les utiliser. Je n'ai pas vraiment de soucis avec les paramètres.
Au niveau objet, je ne sais pas pourquoi le mot clef 'class' n'a pas été intégré pour faire plaisir aux gens. A mon avis, c'est pas si difficile à faire pour les bons programmeurs Perl. Mais pour les gens comme moi, on peut déjà utiliser Moose ou Mouse et c'est pas plus dur que de faire une classe en Java.
Tu installes un Windows XP sur une partition de 15Go, tu fais les mises à jour et tu regardes la fragmentation, c'est lamentable... pour une machine qui n'a même pas encore servit en production.
Rien n'empêche de ne faire qu'une écriture. Option 'secure-delete=1' par exemple. Et puis, il peut mettre des zéro ou des chiffres aléatoire... Encore une fois, je pense que déléguer cette tâche a un processus parallèle asynchrone me semble une bonne idée.
> Par nature le copy-on-write defait toute stratégie d'effacement sécurisé
> puisque les blocs ne sont pas écrasés mais réécrits à côté.
Je ne vois pas ou est le problème...
Pour vraiment effacer les données, il faut ré-écrire dessus un certain nombre de fois et non une seule fois.
Rien n'empêche d'écrire le fihcier n+1 sur l'ancien fichier n.
Mieux encore, rien n'empêche d'avoir une option de montage, du style 'secure-delete' qui écrirait dans un journal tous les block qui ne servent plus et qu'un processus parallèle de BtrFS s'occuperait en tâche de fond d'effacer entre 4 et 7 fois avec des données aléatoires.
Bref, je ne vois pas ou est la sécurité de ré-écrire au même endroit.
Pas forcément. comme BtrFS a un notion du bloc (les autres système de fichier aussi), alors il ne copiera que les blocks modifiés mais pas l'ensemble du fichier.
C'est exactement ce que fait LVM lors d'un snapshot.
> Le site oss.oracle.com est entièrement down pour le moment, désolé, voici une version
> en cache :
Pas de pot, je fais une dépêche la dessus et leur site est HS depuis déjà un bout de temps. Idem tout à l'heure, je n'ai pas pu mettre la référence de la partie réseau associé BtrFS.
A mon avis, on est trop nombreux à vouloir y aller ! DLFP a trop de succés !
Au niveau des formules, j'ai lu un support MathML. En pratique, cela marche comment ? Il faut se farcir le MathML ou on peut tapper en LaTeX les formules ?
Je pose cette question car on a un certain nombre de document collaboratif à réaliser mais il y a toujours plein de formule a intégrer dedans.
> btrfs permet de faire des snapshots d'un répertoire quelconque du
> système de fichier
Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes.
> Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur
> Wikipédia
Je ne sais pas si Patrick a écrit la version anglaise sur Wikipedia. Je suis partis sur cette version la car je savais que pas mal de personne sauterais sur la version Française de wikpedia. Ainsi le débat n'est en que plus animé, la version anglaise étant assez différente de la version française.
Au niveau de la séparation avec la couche LVM et le fait que cette séparation ne soit pas effective, je trouve cela dommage. J'aurais préféré que le système LVM et le device-mapper soient étendus afin de pouvoir répondre aux questions existentielles des systèmes de fichier.
Sinon, je n'y connais rien en système de fichier, j'essaye juste d'être un utilisateur avertis ;-)
Sinon, il y a une "extension" a BrtFS qui me semble aussi intéressante : CRFS (Coherent Remote File System), Il s'agit en fait d'une couche réseau pour accéder au système de fichier à distance. A suivre... car je ne sais pas ce que cela apporte par rapport a du NFSv4 ou du parrallèle NFS. En tout cas, il est bien préciser que CRFS se base sur les fonctionalités de BtrFS.
J'ai utilisé il y a longtemps LilyPond et c'était très bien, très propre pour ce que j'en faisais.
Depuis quelques temps, je me suis mis à l'accordéon diatonique et on fonctionne (on est plusieurs) par tablature. D'ailleurs, je trouve cela très bien car on travaille plus sur le rythme que savoir si c'est un LA ou un DO !
Bref, à par tabledit qui n'est pas libre et qui ne tourne pas sous Linux, je n'ai rien trouver pour faire des tablatures de type diato et c'est très dommage.
Du coté de LilyPond, j'ai vu passer un patch sur le sujet mais pas intégré dans le main du programme et maintenant assez agé.
Question : LilyPond se spécialise-t-il sur la "grande" musique ou certains développeurs seraient intéressé par la musique plus traditionnelle (folk) ?
Je n'ai pas essayer G'MIC mais le traitement d'un photo numérique d'un 5M de pixel avec GREYStoration prend plusieurs minutes sur mon P4 2,5GHz...
Il faut donc voir les points suivants :
- combien de temps est perdus dans le chargement déchargement dans G'MIC
- combien de temps je passe à interfacé mon code C++ (G'MIC) avec le code C (Gimp), sachant que le C++ et le C ne font pas toujours bon ménage si on commence à trop vouloir mélanger...
- combien de temps je vais gagner à passer par des appels système ?
- combien de temps mon algorithme de calcul pourra être réduit dans le futur.
Dans les cas de calculs longs avec des temps de transfert court et s'il n'y a pas a court terme de moyen de diminuer le temps de calcul, le passage par pipe est une bonne solution alliant souplesse, modularité, indépendance, maintenance.
Dans mon cas à moi, le code était en fortran 90, le post-traitement en C++ et l'hyperviseur en Perl. Faire parler tout cela via des pipes m'a permis d'avoir une grande souplesse de développement, de perdre des poullièmes de secondes et d'avoir des modules complémentement indépendant tant que le langage dans le pipe suivait une certaine convention.
Je crois qu'avec G'MIC, on est aussi dans cette problématique pour le moment. Rien n'empêche une fois que tout marche bien et que c'est utilisé par pleins de personne, de remplacer les pipes par des appels à des bibliothèques standardisés.
J'ai fait du calcul de structure ou le temps de calcul est long sur le temps de chargement de fichier. Dans ce type de problème, passer les données par des pipes est très pratique pour les raisons suivantes :
- chaque programe est indépendant. Il est plus facile a débogguer
- les programmes peuvent dans des langages différents
- il est facile de remplacer les pipes par des netcat et d'avoir une couche réseau...
Avec un peu de Perl, on arrive ainsi a faire des choses vraiment intéressante qui n'était pas du tout prévu par les différents programmes à la base. Par exemple, j'avais fait un hyperviseur en Perl qui me pilotait le programme de calcul ainsi que le post-traitement. Ainsi, je récupérait les images en cours de calcul pour monter un petit film, le tout sans garder un seul résultat intermédiaire et en modifiant quasiment que très peu les programmes originels.
> Ceci dit je ne suis pas sur de vouloir poursuivre un opérateur qui par
> ailleurs me rend de grands services...
Nous savons tous qu'il y a du Linux la dedans et au niveau de la gestion des réseaux, cela ne va pas aller en diminuant.
Moi, je trouve cette procédure très bien. Free est pris en exemple car ils ont été le fer de lance de ce procédé. Si Free est condanné, je ne suis pas inquiet, les autres devront changer rapidement de méthode ou se voir eux-aussi inlfiger un procès.
Ce n'est pas parce que free rend bien des services que l'on doit fermer les yeux. Et comme d'autres l'ont dis, il n'y a rien dans une freebox aujourd'hui que les autres opérateurs ne sachent pas. Donc ici, cacher l'information n'a de sens que pour mettre l'utilisateur final dans l'opacité du fonctionnement des réseaux ADSL. Ce n'est pas bon.
-1- Les VM ne sont pas 100% portable pour une raison simple, si on fait des choses pointus, on a toujours des classes spécifiques à l'OS. En fait, il n'y a pas bien grande différence à coder sur une VM ou avec des librairies portables. Cependant, en ne travaillant pas sur une VM, on peut aussi tester d'auters compilateurs. Tu vas me dire qu'il y a plusieurs VM. Certes... Donc au final, cela ne change pas grand chose.
La différence entre une VM comme java et un environnement comme le couple gcc+Qt par exemple, c'est qu'il n'y a pas les mêmes moyens dessus ! Plus tu as de moyens, plus tu es capable de faire de test et de valider ton environement sur du multiplateforme.
Tiens un exemple qui me revient en mémoire. J'ai un onduleur dont le programme de pilotage est en java. Et bien la boite qui vends cet onduleur ne valide pas son logiciel pour une machine Itanium ! Pourtant, c'est pas bien compliqué comme programme, c'est juste des appels SNMP sur l'onduleur... Un bête programme en Perl ou en C serait plus portable que celui en java.
-2- Si on change d'OS et de compilateur, on a la chance de voir plein d'erreur. Mais il faut aussi changer de compilateur, si tu restes sur GNU, cela ne change souvent pas grand chose.
Je me souviens de programmes en fortran qui étaient pourtant bien codé et lisible, qui donnaient les bons résultats et dont on a trouvé des bogues monstrueux rien qu'en changeant de compilateur. On se demande parfois comment le résultat pouvait être juste avec l'autre version de compilateur !
On rentre dans une période de vote dans mon laboratoire, il y a une commission électorale formé de 3 personnes, tout le monde leur fait confiance... Si jamais elles trichaient, ce serait une faute TRES grave. En pratique, ce type de vote ne pose de problème de conscience à personne.
Faire un truc plus lourd avec la seule bonne volonté pour dépouiller signifie en pratique pas d'élection en interne ! Encore une fois, il ne faut pas confondre l'election du président de la république et des députés avec toutes les autres élections.
Je finit donc par une question simple : " Remets-tu en cause la légitimité du leader de debian ? "
A mon avis, il ne sais pas ce qu'il veut. Du libre 100% mais fait par des gens payés, des bleeding edge mais archi stable, pas d'installation tous les 4 matins...
En plus, c'est bien de vouloir Apache-2.2.9 plutôt que la 2.2.3 mais il faut une raison derrière. Qu'elles sont les nouvelles focntionalités du dernier dont tu as absolument besoin ?
Ensuite, tu sors des arguments foireux que debian modifie les paquets originaux ! Mais toutes les distributions font cela. Par exemple, debian est un contributeur majeur sur l'aspect multiplateforme. Si tu as développé un peu du code sur 3 processeurs différents, tu sais que faire cela permet de découvrir plein de bogue...
Donc certe, debian modifie les paquets. Certes, debian a fait une énorme bourde avec openssl et PERSONNE ne l'a vu pendant plusieurs années. Mais elle a été corrigé, rendu publique, tout cela en restant dans la philosophie du libre. Et je n'ai pas connaissance d'une attaque en masse contre les machines debian qui aurait permis a des pirates d'en prendre le controle.
Donc, au final, ce mini crack chez debian a été plus bien géré et va permette d'avoir des procedures qui évite ce genre de chose dans l'avenir. Mais il y en aura d'autres, c'est inévitable. D'ailleurs, red-hat a aussi mis des bogues (moins grave) dans ses paquets et pourtant, ce sont des pros ! Et puis, le protocole DNS avait aussi un bogue ! Putain merde, le pilié d'internet... et tu l'utilises encore.
A mon avis, fixe toi sur une distribution et commence par gérer un parc de 40 machines, tant serveur que de bureau, sur 4 ans et on en reparle.
Finalement, tu as l'air de l'aimé plutôt la debian. Ton problème me semble être sur un nombre réduit de paquet comme Gimp et justement, il y a les backports pour cela.
Bref, pourquoi les balayer comme cela en une seule phrase sèche ?
Les personnes dans une boite font confiance aux administrateurs systèmes et réseaux. Et pourtant, il est très facile pour nous d'aller lire des documents confidentiels...
Qu'est ce qui protège les personnes de leur administrateur système ?
-1- l'OS. C'est la stratégie prise par Microsoft avec NT de dire que root n'a pas tous les pouvoirs notament de voir les documents des utilisateurs. En pratique, c'est parfois très chiantcar cela nous empêche de faire notre boulot.
-2- la loi. Un administrateur système est pénalement responsable. Il est déjà arrivé au CNRS par exemple qu'un adminsitrateur système se retrouve devant la justice pour avoir diffusé un document sans autorisation de la personne.
Pour un certain nombre de vote, le vote électronique marche très bien. Qui remet en cause le leader de debian ? Pourtant debian utilise le vote électronique. Si les administrateurs debian qui gère le système de vote trichent un jour, ils risquent très gros. Quel est leur intérêt de tricher ?
C'est pareil pour tout un tas de vote en entreprise. Le vote électronique permet de plus consulter, de pouvoir plus s'appuyer sur la démocratie directe.
Ceux qui veulent des urnes sont-ils près à aller toutes les semaines les vider et faire de dépouillement ?
Avec le vote électronique, on peux aussi mettre en place les votes de type condorcet (utilisés chez debian). Ce genre de système est quasiment impossible à mettre en place avec une urne.
J'ai connu à la fac le système de vote par liste majoritaire ou on avait le droit de barrer des noms et d'en rajouter !! Il fallait trois jours pour dépouiller cette horreur et on finissait par même plus vraiment savoir pour qui on votait exactement.
Le vote électronique est basé en interne dans une structure de type entreprise sur la confiance dans les administrateurs systèmes et réseaux. Ils sont pénalement responsable et sont, sur un certain nombre de point, indépendant de leur direction directe.
Travaillant dans un laboratoire CNRS, il y a un certain nombre d'ordre que mon directeur peut me donner que je n'exécuterait jamais, car elle ne sont pas de son resort. Il faut arrêter de croire que le directeur a tous les pouvoirs.
Parfois, pour faire avancer le débat, on est obliger de balancer des phrases un peu (trop) choc qui oblige à se rendre compte de l'absurdité de notre situation actuelle. Mais rassure toi, je n'en veux pas aux pompistes que je respecte beaucoup (quand j'en vois encore), c'est une image d'épinal comme la tienne que je te renvoyais.
L'Homme d'hier en Occident a eu beaucoup de mal a accueillir les noirs. L'Homme actuel a beaucoup de mal a accueillir ses cousins grands singes qui lui sont ses plus proches parents au sens génétique. L'Homme de demain aura certainement du mal a accueillir les autres espèces...
Un bouquin qui parle un peu de cela est : Les prairies bleus, d'Athur Clarke.
Pour ce qui est du QI, les expériences sur les autres grands singes sont assez étonnantes, mais elles manquent de continuité car justement les résultats pourraient trop déranger.
Pour conclure, je ne suis pas végétarien pour rien ;-)
Les votes aux CNRS pour les différentes élections se font via des enveloppes que l'on envoi. Il n'y a pas d'urnes. Des personnes récupèrent les enveloppes, les ouvrent, prennent la seconde enveloppe et la mette dans l'urne...
Bref, tout cela se fait sans les agents autour... On fait confiance dans les personnes qui gèrent le vote.
Que le vote électronique soit un problème sur des élections sensibles ou les garants de l'état sont en jeu, je suis d'accord.
Sur des votes ou les garants du vote n'ont aucun intérêt dans celui-ci, je me pose la question. Si le vote électronique permet d'avoir un taux d'abstension bien plus faible... est-ce réellement pire ?
L'important, c'est que les représentants représentent. On peut faire des règles démocratiques avec des urnes et tout et tout, qui pourtant ne réprésente pas pour autant. Un exemple flagrant est le Sénat qui ne bouge pas de bords depuis 50 ans !
Vaut-il mieux un vote électronique juste ou des règles foireuses comme au sénat ?
[^] # Re: Explicit is better than implicit.
Posté par Sytoka Modon (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 1.
> pour le python ;-). ça on est d'accord ...
Ben je suis désolé mais je n'y comprends rien en Python. J'ai même du balancé un site web en Zoppe pour faire du SPIP car Python me gonflait plus que la normale, et pourtant je déteste le PHP qui n'aurait jamais du exister car c'était du sous perl.
Non, le Python n'est pas mieux que les autres, il a ses fans mais il a aussi des inconvénients comme les autres.
Pour me changer les idées, je me suis mis à Erlang et là au moins, on change de perspective. C'est amusant.
[^] # Re: javascript
Posté par Sytoka Modon (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 1.
D'ailleurs, c'est marrant, dès qu'on parle Lissac ici, je sors mon Sather;-)
[^] # Re: Explicit is better than implicit.
Posté par Sytoka Modon (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à -2.
Je ne comprends rien aux programmes Java avec leur millions de lignes, leur millions de classe, les fichiers de conf XML de Tomcat ;-)
J'ai travaillé avec pas mal de personne qui n'avait jamais fait de Perl, qui n'en pensait que du mal mais qui avait fait du PHP ! Et bien, tous ont compris de suite les programmes ! Evidement, il y a quelques règles à respecter pour avoir du Perl lisible mais c'est pareil dans tous les langages.
Sinon, il y a des milliers de modules sur le CPAN et la doc est très claire pour les utiliser. Je n'ai pas vraiment de soucis avec les paramètres.
Au niveau objet, je ne sais pas pourquoi le mot clef 'class' n'a pas été intégré pour faire plaisir aux gens. A mon avis, c'est pas si difficile à faire pour les bons programmeurs Perl. Mais pour les gens comme moi, on peut déjà utiliser Moose ou Mouse et c'est pas plus dur que de faire une classe en Java.
[^] # Re: Défragmentation
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 2.
Tu installes un Windows XP sur une partition de 15Go, tu fais les mises à jour et tu regardes la fragmentation, c'est lamentable... pour une machine qui n'a même pas encore servit en production.
[^] # Re: Granularité du COW ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 1.
[^] # Re: Granularité du COW ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 0.
> puisque les blocs ne sont pas écrasés mais réécrits à côté.
Je ne vois pas ou est le problème...
Pour vraiment effacer les données, il faut ré-écrire dessus un certain nombre de fois et non une seule fois.
Rien n'empêche d'écrire le fihcier n+1 sur l'ancien fichier n.
Mieux encore, rien n'empêche d'avoir une option de montage, du style 'secure-delete' qui écrirait dans un journal tous les block qui ne servent plus et qu'un processus parallèle de BtrFS s'occuperait en tâche de fond d'effacer entre 4 et 7 fois avec des données aléatoires.
Bref, je ne vois pas ou est la sécurité de ré-écrire au même endroit.
[^] # Re: Fin des ajouts dans le 2.6.29
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 6.
[^] # Re: Snapshot ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 1.
C'est exactement ce que fait LVM lors d'un snapshot.
# Fin des ajouts dans le 2.6.29
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 3.
http://lwn.net/Articles/314471/
Au bilan, les trois grands apport de cette version seront
* squashfs : un système de fichier compressé en lecture seule
* Btrfs (en mode développement, pas pour l'utilisateur lambda)
* Les "modes settings" pour les cartes graphiques Intel (chose que faisait avant X-Window et qui bascule petit à petit dans le noyau).
[^] # Re: Snapshot ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 3.
> en cache :
Pas de pot, je fais une dépêche la dessus et leur site est HS depuis déjà un bout de temps. Idem tout à l'heure, je n'ai pas pu mettre la référence de la partie réseau associé BtrFS.
A mon avis, on est trop nombreux à vouloir y aller ! DLFP a trop de succés !
# Formule de Math
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le CMS "La Poule ou l'Oeuf", le livre application. Évalué à 2.
Je pose cette question car on a un certain nombre de document collaboratif à réaliser mais il y a toujours plein de formule a intégrer dedans.
[^] # Re: Reiserfs
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 2.
> système de fichier
Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes.
> Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur
> Wikipédia
Je ne sais pas si Patrick a écrit la version anglaise sur Wikipedia. Je suis partis sur cette version la car je savais que pas mal de personne sauterais sur la version Française de wikpedia. Ainsi le débat n'est en que plus animé, la version anglaise étant assez différente de la version française.
Au niveau de la séparation avec la couche LVM et le fait que cette séparation ne soit pas effective, je trouve cela dommage. J'aurais préféré que le système LVM et le device-mapper soient étendus afin de pouvoir répondre aux questions existentielles des systèmes de fichier.
Sinon, je n'y connais rien en système de fichier, j'essaye juste d'être un utilisateur avertis ;-)
Sinon, il y a une "extension" a BrtFS qui me semble aussi intéressante : CRFS (Coherent Remote File System), Il s'agit en fait d'une couche réseau pour accéder au système de fichier à distance. A suivre... car je ne sais pas ce que cela apporte par rapport a du NFSv4 ou du parrallèle NFS. En tout cas, il est bien préciser que CRFS se base sur les fonctionalités de BtrFS.
# Tablature
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LilyPond 2.12. Évalué à 1.
Depuis quelques temps, je me suis mis à l'accordéon diatonique et on fonctionne (on est plusieurs) par tablature. D'ailleurs, je trouve cela très bien car on travaille plus sur le rythme que savoir si c'est un LA ou un DO !
Bref, à par tabledit qui n'est pas libre et qui ne tourne pas sous Linux, je n'ai rien trouver pour faire des tablatures de type diato et c'est très dommage.
Du coté de LilyPond, j'ai vu passer un patch sur le sujet mais pas intégré dans le main du programme et maintenant assez agé.
Question : LilyPond se spécialise-t-il sur la "grande" musique ou certains développeurs seraient intéressé par la musique plus traditionnelle (folk) ?
[^] # Re: Merci
Posté par Sytoka Modon (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 4.
Il faut donc voir les points suivants :
- combien de temps est perdus dans le chargement déchargement dans G'MIC
- combien de temps je passe à interfacé mon code C++ (G'MIC) avec le code C (Gimp), sachant que le C++ et le C ne font pas toujours bon ménage si on commence à trop vouloir mélanger...
- combien de temps je vais gagner à passer par des appels système ?
- combien de temps mon algorithme de calcul pourra être réduit dans le futur.
Dans les cas de calculs longs avec des temps de transfert court et s'il n'y a pas a court terme de moyen de diminuer le temps de calcul, le passage par pipe est une bonne solution alliant souplesse, modularité, indépendance, maintenance.
Dans mon cas à moi, le code était en fortran 90, le post-traitement en C++ et l'hyperviseur en Perl. Faire parler tout cela via des pipes m'a permis d'avoir une grande souplesse de développement, de perdre des poullièmes de secondes et d'avoir des modules complémentement indépendant tant que le langage dans le pipe suivait une certaine convention.
Je crois qu'avec G'MIC, on est aussi dans cette problématique pour le moment. Rien n'empêche une fois que tout marche bien et que c'est utilisé par pleins de personne, de remplacer les pipes par des appels à des bibliothèques standardisés.
[^] # Re: Merci
Posté par Sytoka Modon (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 3.
- chaque programe est indépendant. Il est plus facile a débogguer
- les programmes peuvent dans des langages différents
- il est facile de remplacer les pipes par des netcat et d'avoir une couche réseau...
Avec un peu de Perl, on arrive ainsi a faire des choses vraiment intéressante qui n'était pas du tout prévu par les différents programmes à la base. Par exemple, j'avais fait un hyperviseur en Perl qui me pilotait le programme de calcul ainsi que le post-traitement. Ainsi, je récupérait les images en cours de calcul pour monter un petit film, le tout sans garder un seul résultat intermédiaire et en modifiant quasiment que très peu les programmes originels.
[^] # Re: Just for the record
Posté par Sytoka Modon (site web personnel) . En réponse au journal EyeOS 1.7.0. Évalué à 10.
Les utilisateurs ont le droit d'avoir un . dans leur login, il faut prendre l'habiture de mettre : dans la commande chown.
[^] # Re: boitier HD: ffmpeg ? VLC ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Free assigné pour violation de la GPL. Évalué à 10.
> ailleurs me rend de grands services...
Nous savons tous qu'il y a du Linux la dedans et au niveau de la gestion des réseaux, cela ne va pas aller en diminuant.
Moi, je trouve cette procédure très bien. Free est pris en exemple car ils ont été le fer de lance de ce procédé. Si Free est condanné, je ne suis pas inquiet, les autres devront changer rapidement de méthode ou se voir eux-aussi inlfiger un procès.
Ce n'est pas parce que free rend bien des services que l'on doit fermer les yeux. Et comme d'autres l'ont dis, il n'y a rien dans une freebox aujourd'hui que les autres opérateurs ne sachent pas. Donc ici, cacher l'information n'a de sens que pour mettre l'utilisateur final dans l'opacité du fonctionnement des réseaux ADSL. Ce n'est pas bon.
[^] # Re: backports ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Le choix d'une distribution Linux. Évalué à 2.
La différence entre une VM comme java et un environnement comme le couple gcc+Qt par exemple, c'est qu'il n'y a pas les mêmes moyens dessus ! Plus tu as de moyens, plus tu es capable de faire de test et de valider ton environement sur du multiplateforme.
Tiens un exemple qui me revient en mémoire. J'ai un onduleur dont le programme de pilotage est en java. Et bien la boite qui vends cet onduleur ne valide pas son logiciel pour une machine Itanium ! Pourtant, c'est pas bien compliqué comme programme, c'est juste des appels SNMP sur l'onduleur... Un bête programme en Perl ou en C serait plus portable que celui en java.
-2- Si on change d'OS et de compilateur, on a la chance de voir plein d'erreur. Mais il faut aussi changer de compilateur, si tu restes sur GNU, cela ne change souvent pas grand chose.
Je me souviens de programmes en fortran qui étaient pourtant bien codé et lisible, qui donnaient les bons résultats et dont on a trouvé des bogues monstrueux rien qu'en changeant de compilateur. On se demande parfois comment le résultat pouvait être juste avec l'autre version de compilateur !
[^] # Re: Le Vote electronique mene a la guerre civile
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vote par Internet pour les élections prud'homales sur Paris. Évalué à 2.
Faire un truc plus lourd avec la seule bonne volonté pour dépouiller signifie en pratique pas d'élection en interne ! Encore une fois, il ne faut pas confondre l'election du président de la république et des députés avec toutes les autres élections.
Je finit donc par une question simple : " Remets-tu en cause la légitimité du leader de debian ? "
[^] # Re: backports ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Le choix d'une distribution Linux. Évalué à 8.
En plus, c'est bien de vouloir Apache-2.2.9 plutôt que la 2.2.3 mais il faut une raison derrière. Qu'elles sont les nouvelles focntionalités du dernier dont tu as absolument besoin ?
Ensuite, tu sors des arguments foireux que debian modifie les paquets originaux ! Mais toutes les distributions font cela. Par exemple, debian est un contributeur majeur sur l'aspect multiplateforme. Si tu as développé un peu du code sur 3 processeurs différents, tu sais que faire cela permet de découvrir plein de bogue...
Donc certe, debian modifie les paquets. Certes, debian a fait une énorme bourde avec openssl et PERSONNE ne l'a vu pendant plusieurs années. Mais elle a été corrigé, rendu publique, tout cela en restant dans la philosophie du libre. Et je n'ai pas connaissance d'une attaque en masse contre les machines debian qui aurait permis a des pirates d'en prendre le controle.
Donc, au final, ce mini crack chez debian a été plus bien géré et va permette d'avoir des procedures qui évite ce genre de chose dans l'avenir. Mais il y en aura d'autres, c'est inévitable. D'ailleurs, red-hat a aussi mis des bogues (moins grave) dans ses paquets et pourtant, ce sont des pros ! Et puis, le protocole DNS avait aussi un bogue ! Putain merde, le pilié d'internet... et tu l'utilises encore.
A mon avis, fixe toi sur une distribution et commence par gérer un parc de 40 machines, tant serveur que de bureau, sur 4 ans et on en reparle.
[^] # Re: Linux sur un P6...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Puisque. Évalué à 3.
Bref, c'est un serveur qui fait économiser beaucoup à très peu. On devrait proposer cela à l'équipe en place autour de Sarkozy ;-)
# backports ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Le choix d'une distribution Linux. Évalué à 3.
Pourquoi ?
Finalement, tu as l'air de l'aimé plutôt la debian. Ton problème me semble être sur un nombre réduit de paquet comme Gimp et justement, il y a les backports pour cela.
Bref, pourquoi les balayer comme cela en une seule phrase sèche ?
[^] # Re: Le Vote electronique mene a la guerre civile
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vote par Internet pour les élections prud'homales sur Paris. Évalué à 3.
Les personnes dans une boite font confiance aux administrateurs systèmes et réseaux. Et pourtant, il est très facile pour nous d'aller lire des documents confidentiels...
Qu'est ce qui protège les personnes de leur administrateur système ?
-1- l'OS. C'est la stratégie prise par Microsoft avec NT de dire que root n'a pas tous les pouvoirs notament de voir les documents des utilisateurs. En pratique, c'est parfois très chiantcar cela nous empêche de faire notre boulot.
-2- la loi. Un administrateur système est pénalement responsable. Il est déjà arrivé au CNRS par exemple qu'un adminsitrateur système se retrouve devant la justice pour avoir diffusé un document sans autorisation de la personne.
Pour un certain nombre de vote, le vote électronique marche très bien. Qui remet en cause le leader de debian ? Pourtant debian utilise le vote électronique. Si les administrateurs debian qui gère le système de vote trichent un jour, ils risquent très gros. Quel est leur intérêt de tricher ?
C'est pareil pour tout un tas de vote en entreprise. Le vote électronique permet de plus consulter, de pouvoir plus s'appuyer sur la démocratie directe.
Ceux qui veulent des urnes sont-ils près à aller toutes les semaines les vider et faire de dépouillement ?
Avec le vote électronique, on peux aussi mettre en place les votes de type condorcet (utilisés chez debian). Ce genre de système est quasiment impossible à mettre en place avec une urne.
J'ai connu à la fac le système de vote par liste majoritaire ou on avait le droit de barrer des noms et d'en rajouter !! Il fallait trois jours pour dépouiller cette horreur et on finissait par même plus vraiment savoir pour qui on votait exactement.
Le vote électronique est basé en interne dans une structure de type entreprise sur la confiance dans les administrateurs systèmes et réseaux. Ils sont pénalement responsable et sont, sur un certain nombre de point, indépendant de leur direction directe.
Travaillant dans un laboratoire CNRS, il y a un certain nombre d'ordre que mon directeur peut me donner que je n'exécuterait jamais, car elle ne sont pas de son resort. Il faut arrêter de croire que le directeur a tous les pouvoirs.
[^] # Re: gestion des images > 8 bits
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 2.
Parfois, pour faire avancer le débat, on est obliger de balancer des phrases un peu (trop) choc qui oblige à se rendre compte de l'absurdité de notre situation actuelle. Mais rassure toi, je n'en veux pas aux pompistes que je respecte beaucoup (quand j'en vois encore), c'est une image d'épinal comme la tienne que je te renvoyais.
L'Homme d'hier en Occident a eu beaucoup de mal a accueillir les noirs. L'Homme actuel a beaucoup de mal a accueillir ses cousins grands singes qui lui sont ses plus proches parents au sens génétique. L'Homme de demain aura certainement du mal a accueillir les autres espèces...
Un bouquin qui parle un peu de cela est : Les prairies bleus, d'Athur Clarke.
Pour ce qui est du QI, les expériences sur les autres grands singes sont assez étonnantes, mais elles manquent de continuité car justement les résultats pourraient trop déranger.
Pour conclure, je ne suis pas végétarien pour rien ;-)
# Au CNRS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vote par Internet pour les élections prud'homales sur Paris. Évalué à 1.
Bref, tout cela se fait sans les agents autour... On fait confiance dans les personnes qui gèrent le vote.
Que le vote électronique soit un problème sur des élections sensibles ou les garants de l'état sont en jeu, je suis d'accord.
Sur des votes ou les garants du vote n'ont aucun intérêt dans celui-ci, je me pose la question. Si le vote électronique permet d'avoir un taux d'abstension bien plus faible... est-ce réellement pire ?
L'important, c'est que les représentants représentent. On peut faire des règles démocratiques avec des urnes et tout et tout, qui pourtant ne réprésente pas pour autant. Un exemple flagrant est le Sénat qui ne bouge pas de bords depuis 50 ans !
Vaut-il mieux un vote électronique juste ou des règles foireuses comme au sénat ?