sorties il y a un an ... mais qui ne marche pas en multi-plateforme !
D'ailleurs je suis surpris qu'avec notre système UNIX multi couche et tout et tout, il y ai toujours autant de logiciels dépendant de l'architecture. C'est incroyable je trouve d'avoir autant de soucis d'architecture de nos jours.
Il faut dire qu'au niveau des couches basses, tous les 3 ans on nous sors un nouveau truc qui est génial et tout et tout et que le truc précédent, c'est vraiment de la daube. Trois ans après, même topo (cf hal...).
Chez moi tout va bien globalement sauf iceweasel et icedove qui plante au bout de 30s max... idem avec les versions officielles. Du coup, je tourne en schroot avec les version lenny !
Un des avantages de *roff est d'avoir une sortie terminal. Je pense que si LaTeX avait été conçu pour avoir une sortie dans le terminal, roff aurait disparu. Mais justement, pour moi, les deux ne sont pas incompatible mais tout à fait complémentaire.
A noter qu'avec les wikis en abondance de nos jours, tout le monde va nous dire que sa syntaxe wiki est meilleure et tout et tout.
Moi je faisais du pod car à l'époque, les wikis n'existait pas et c'était déjà intégré dans Perl. C'est très très simple et pour faire des pages de man, c'est suffisant car je veux un affichage simple dans le terminal. En plus, tous mes modules Perl sont documentés ainsi. C'est vraiment important d'avoir la doc minimale dans le code source.
Après, les syntaxes wiki, c'est bien mais j'en utilise 36, du coup, il me faut presque toujours une doc sous la main pour avoir les spécificités de la syntaxe d'un wiki particulier. Et comme il n'y en pas une qui se dégage du lot et que j'en trouve aucune parfaite, c'est pas près de changer.
La syntaxe est d'un autre âge mais l'outil est bien pratique. J'ai horreur des programmes qui n'ont pas de "man" et du coté des applications graphiques, cela arrive de plus en plus souvent.
Je faisais pas mal de man en pod (Perl). La commande pod2man transforme alors le fichier de roff que "man" sais lire. Cela permet de vite faire de la doc, propre et utilisable.
Un système trop intelligent ne sera pas assez généraliste et sera pénible car il y a une multitude de langage et des nouveaux langages arrivent...
Il me semble qu'il y a deux systèmes simples pour voir si un fichier a été modifié, la date et un checksum. Tout autre système devient intrusif. Il faudrait pouvoir choisir selon le type de fichier. C'est un peu ce que propose cfengine dans ses règles de "copy".
Je pense que les alternatives comme ANT... sont trop flêchés sur un langage : Java, C++... du coup, on n'a pas du tout envie de le mettre sur autre chose.
Il faut vraiment un outil qui à la base ne pense pas pour un langage.
Je pense qu'il faudrait un outil intelligent et généraliste ayant un moteur d'inférence intelligent et pouvant être facilement être étendue. Bref, un truc écrit pour des êtres humains pas pour des IDE !
Une petite idée vient de me passer en tête et je pense qu'il faudrait un truc équivalent à cfengine mais dédié pour la compilation. cfengine est écrit en C, son fichier de config est humain, il s'adapte aux différentes architectures via des règles et des classes et on envoi facilement une commande, pas forcément du bash.
Riak est une base de données dont l'intérêt principal est de se gérer par défaut comme un cluster maître maître dans lequel on peux ajouter et supprimer des noeuds. C'est trop rare pour ne pas être signalé.
Plus de noeud maître pour l'écriture... Pas de haute disponibilité à gérer... Riak gère tout cela en natif, tous les noeuds sont maîtres et c'est très bien.
Le principal problème que personne n'évoque ici c'est le problème Disney, ou Mickey ou plutôt Winnie l'ourson...
Pour s'assurer une rente sans rien faire, Disney (ses descendants) à fait rallonger les droits d'auteurs petits à petits. En gros aujourd'hui 70 ans après la mort de l'auteur.
C'est du n'importe quoi qui tue la créativité car beaucoup trop long et avantage les grosses multi-nationales qui verrouillent le marché de la culture (Disney par exemple). Bref, on ne peux plus créer sans se faire attaquer pour plagiat de x ou y...
L'UE ferait mieux de réduire les droits d'auteur à 30 ans après la mort de celui-ci comme avant en interne dans l'UE et d'imposer à l'export des règles de réciprocité !
Encore une fois, c'est un problème à l'origine américain que nous avons consciemment ramené sur le vieux continent. Laissons les USA avec leur soucis et ne les suivons pas bêtement avec toujours un train de retard.
Effectivement, il y a trois erreurs connus, impardonnable car on n'a pas écouté les conservateurs. Pour être en relation avec des architectes pour la construction de nouveau bâtiment public, il est très difficile de faire réellement prendre en compte le besoin des futurs utilisateurs... Bref, les trois erreurs visible :
- tour -> en cas d'incendie, c'est une vrai torche. Pour des livres inestimable, on considère le livre plus important qu'un homme donc en cas d'incendie, on a 30s pour quitter la pièce sinon attention aux gaz...
- paroi en verre -> on a beau mettre des traitements, la lumière tue le papier sur le long terme, n'importe qui le sais !
- réalisé sur une zone dont la partie en sous sol est innondable. Et oui, la TGB est en zone innondable !
Au final, c'est absolument n'importe quoi et c'est encore une réalisation ratée de FM (comme l'opéra bastille et l'arche de la défense) qui sera à terme un gouffre pour nos impôts.
La TGB aurait très bien pu être en province qui ne manque pas de site bien plus adapté.
Quasiment toutes les chaînes de télé ont du basculer sur le H264 aujourd'hui. De même avec la visio-conf (marché bien plus petit d'ou vient le H264). Bref, il y a un poids économique énorme derrière le H264.
Sinon, on a fait du web pendant des années avec des images GIF et le PNG n'a jamais réussi à virer le GIF malgré sa supériorité. De nos jours, le GIF ne pose d'ailleurs plus de soucis.
Sinon, comme pour le GIF, les brevets logiciels ne fonctionnent pas en en Europe donc le H264 est libre ici. Il faut arrêter de mettre le droit américain chez nous et empiler notre droit et le leur. Aucune entreprise Française n'a été embêté par le GIF dans les années 90. Les fournisseurs de vidéo n'ont qu'a se mettre en Europe comme dailymotion ;-)
Sinon, la séparation de la spécification et de l'implémentation du WebM (VP8) n'était pas si claire que cela si je me souviens bien. De plus, il y avait pas mal de boulot à faire sur le code pour en tirer une bibliothèque propre, lisible et bien "programmé".
Tout cela conduit à de beau jour pour le H264 et par la même, on va encore avoir cette daube d'Adobe sur 99% des postes utilisateurs...
> Redmine est un vieux projet qui s'est baladé avec du vieux code obscur ou franchement
> crade pendant un bon moment, il y a pas mal de passages qui était carrément l'inverse
> de bonne pratiques recommendées habituellement. Cela a changé au fil du temps,
> doucement mais sûrement.
C'est marrant car ici les gens sont très pro ruby et python et très peu perl et on voit à ce commentaire que ces langages ont les mêmes défauts (avantages) que perl, ils évoluent et le vieux code est parfois crade ;-)
La France a changé ses panneaux STOP quand j'étais petit. Cela s'est fait doucement et il n'en reste presque plus (j'en ai encore vu un l'an passé mais je ne sais plus ou !).
On pourrait donc envisager un système meilleure, surtout qu'avec les LED, c'est plus facile. Par exemple vert=rond, orange=triangle, rouge=carré. De plus, on en profiterais pour faire le réglage qu'on trouve dans plein de pays et qui est bien mieux qu'en métropole :
vert -> orange -> rouge -> rouge+orange -> vert...
> Pas pour suivre les autres, mais pour gagner de la place.
Le problème est que depuis quelques années les écrans diminuent... Depuis les années 90, les écrans augmentaient mais ce n'est plus le cas.
On a en ce moment des 22 ou des 24" qui n'ont même pas la définition verticale des écrans 4/3 d'il y a quelques années. Le format 16/9 très adapté à la vidéo n'est pas forcément le top pour le boulot ni le web je trouve. La lecture n'est as adapté à une trop grande largeur et le multi-colonne sur un système à ascenseur vertical ne fonctionne pas correctement. De plus, je trouve que c'est pas assez large pour avoir deux pages A4 cote à cote (par exemple le source TeX à gauche et le pdf à droite), sauf alors les très grand écrans.
Le 16/9 est parfait pour les portables puisque les claviers sont larges plus que profond ;-)
J'étais convaincu que les interfaces graphiques s'adapteraient à ce nouveau format 16/9. Je ne suis pas encore enchanté du résultat pour le moment. Il faudrait trouver comment utiliser judicieusement une bande verticale mais comme les européens écrivent de gauche à droite, c'est pas facile !
Et encore, lorsque tu balances dedans un bout de message d'erreur ayant plein d'espace mais aussi un "deux points" :, ce couillon cherche une URL et ne fait pas une recherche par défaut comme c'est le cas s'il n'y a pas de : qui traine...
> Sinon, je suis d'accord qu'il faut un moyen simple de voir les URL complète.
Sachant que il y a une différence entre une URL interne et une URL externe a un site. Une URL interne n'a pas réellement besoin d'être vu facilement, c'est un calback interne à l'application qu'on utilise. Un lien externe, c'est tout autre chose.
> Perso, la seule chose qui me fait rester sur FF, c'est que la barre d'URL "intelligente" est la
> seule qui me parait vraiment "intelligente" de tous les navigateurs du marché et qui colle
> parfaitement a ce que j'attends d'elle.
Et encore, lorsque tu balances dedans un bout de message d'erreur ayant plein d'espace mais aussi un espace, ce couillon cherche une URL et ne fait pas une recherche par défaut comme c'est le cas s'il n'y a pas de : qui traine...
Bref, en améliorant encore un peu la barre d'adresse, c'est la barre de recherche qui ne sers plus à rien.
Sinon, je suis d'accord qu'il faut un moyen simple de voir les URL complète. On ne peux pas se battre et essayer d'apprendre aux gens à ne pas suivre n'importe quelle URL et ne plus pouvoir les voir simplement.
[^] # Re: Ca tombe bien
Posté par Sytoka Modon (site web personnel) . En réponse au journal Debian Squeeze en février ?. Évalué à 10.
D'ailleurs je suis surpris qu'avec notre système UNIX multi couche et tout et tout, il y ai toujours autant de logiciels dépendant de l'architecture. C'est incroyable je trouve d'avoir autant de soucis d'architecture de nos jours.
Il faut dire qu'au niveau des couches basses, tous les 3 ans on nous sors un nouveau truc qui est génial et tout et tout et que le truc précédent, c'est vraiment de la daube. Trois ans après, même topo (cf hal...).
[^] # Re: La Question
Posté par Sytoka Modon (site web personnel) . En réponse au journal Debian Squeeze en février ?. Évalué à 5.
apt-get fait une chose et le fait bien.
[^] # Re: Syntaxe
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 2.
- SPIP
- Trac
- Ikiwiki (markdown pour moi)
- Mediawiki
Pour les utilisateurs, c'est pas idéal.
[^] # Re: Ca tombe bien
Posté par Sytoka Modon (site web personnel) . En réponse au journal Debian Squeeze en février ?. Évalué à 4.
[^] # Re: Syntaxe
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 3.
A noter qu'avec les wikis en abondance de nos jours, tout le monde va nous dire que sa syntaxe wiki est meilleure et tout et tout.
Moi je faisais du pod car à l'époque, les wikis n'existait pas et c'était déjà intégré dans Perl. C'est très très simple et pour faire des pages de man, c'est suffisant car je veux un affichage simple dans le terminal. En plus, tous mes modules Perl sont documentés ainsi. C'est vraiment important d'avoir la doc minimale dans le code source.
Après, les syntaxes wiki, c'est bien mais j'en utilise 36, du coup, il me faut presque toujours une doc sous la main pour avoir les spécificités de la syntaxe d'un wiki particulier. Et comme il n'y en pas une qui se dégage du lot et que j'en trouve aucune parfaite, c'est pas près de changer.
[^] # Re: Syntaxe
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 4.
Je faisais pas mal de man en pod (Perl). La commande pod2man transforme alors le fichier de roff que "man" sais lire. Cela permet de vite faire de la doc, propre et utilisable.
[^] # Re: Ant ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 1.
Il me semble qu'il y a deux systèmes simples pour voir si un fichier a été modifié, la date et un checksum. Tout autre système devient intrusif. Il faudrait pouvoir choisir selon le type de fichier. C'est un peu ce que propose cfengine dans ses règles de "copy".
[^] # Re: Y'en a déjà des kilos...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 7.
Il faut vraiment un outil qui à la base ne pense pas pour un langage.
[^] # Re: J'attends désespérément un moteur de production potable...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 2.
Une petite idée vient de me passer en tête et je pense qu'il faudrait un truc équivalent à cfengine mais dédié pour la compilation. cfengine est écrit en C, son fichier de config est humain, il s'adapte aux différentes architectures via des règles et des classes et on envoi facilement une commande, pas forcément du bash.
[^] # Re: Jusqu'où... et pourquoi
Posté par Sytoka Modon (site web personnel) . En réponse au journal boot en une seule seconde. Évalué à 4.
[^] # Re: cat H.264 > /dev/null ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Hudson devient Jenkins, Riak 0.14, Chrome abandonne H264. Évalué à 2.
# Riak
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Hudson devient Jenkins, Riak 0.14, Chrome abandonne H264. Évalué à 8.
Plus de noeud maître pour l'écriture... Pas de haute disponibilité à gérer... Riak gère tout cela en natif, tous les noeuds sont maîtres et c'est très bien.
[^] # Re: j'adore ce passage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche L'Union Européenne et le rapport « La nouvelle Renaissance ». Évalué à 5.
Pour s'assurer une rente sans rien faire, Disney (ses descendants) à fait rallonger les droits d'auteurs petits à petits. En gros aujourd'hui 70 ans après la mort de l'auteur.
http://fr.wikipedia.org/wiki/Dur%C3%A9e_du_droit_d%27auteur_(...)
C'est du n'importe quoi qui tue la créativité car beaucoup trop long et avantage les grosses multi-nationales qui verrouillent le marché de la culture (Disney par exemple). Bref, on ne peux plus créer sans se faire attaquer pour plagiat de x ou y...
L'UE ferait mieux de réduire les droits d'auteur à 30 ans après la mort de celui-ci comme avant en interne dans l'UE et d'imposer à l'export des règles de réciprocité !
Encore une fois, c'est un problème à l'origine américain que nous avons consciemment ramené sur le vieux continent. Laissons les USA avec leur soucis et ne les suivons pas bêtement avec toujours un train de retard.
[^] # Re: Le visionnaire du passé
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche L'Union Européenne et le rapport « La nouvelle Renaissance ». Évalué à 3.
[^] # Re: Google, space poneys and unicorns...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Encore un troll de moins .... Évalué à 4.
[^] # Re: Le visionnaire du passé
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche L'Union Européenne et le rapport « La nouvelle Renaissance ». Évalué à 6.
- tour -> en cas d'incendie, c'est une vrai torche. Pour des livres inestimable, on considère le livre plus important qu'un homme donc en cas d'incendie, on a 30s pour quitter la pièce sinon attention aux gaz...
- paroi en verre -> on a beau mettre des traitements, la lumière tue le papier sur le long terme, n'importe qui le sais !
- réalisé sur une zone dont la partie en sous sol est innondable. Et oui, la TGB est en zone innondable !
Au final, c'est absolument n'importe quoi et c'est encore une réalisation ratée de FM (comme l'opéra bastille et l'arche de la défense) qui sera à terme un gouffre pour nos impôts.
La TGB aurait très bien pu être en province qui ne manque pas de site bien plus adapté.
[^] # Re: Google, space poneys and unicorns...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Encore un troll de moins .... Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par Sytoka Modon (site web personnel) . En réponse au journal Encore un troll de moins .... Évalué à 8.
Sinon, on a fait du web pendant des années avec des images GIF et le PNG n'a jamais réussi à virer le GIF malgré sa supériorité. De nos jours, le GIF ne pose d'ailleurs plus de soucis.
Sinon, comme pour le GIF, les brevets logiciels ne fonctionnent pas en en Europe donc le H264 est libre ici. Il faut arrêter de mettre le droit américain chez nous et empiler notre droit et le leur. Aucune entreprise Française n'a été embêté par le GIF dans les années 90. Les fournisseurs de vidéo n'ont qu'a se mettre en Europe comme dailymotion ;-)
Sinon, la séparation de la spécification et de l'implémentation du WebM (VP8) n'était pas si claire que cela si je me souviens bien. De plus, il y avait pas mal de boulot à faire sur le code pour en tirer une bibliothèque propre, lisible et bien "programmé".
Tout cela conduit à de beau jour pour le H264 et par la même, on va encore avoir cette daube d'Adobe sur 99% des postes utilisateurs...
[^] # Re: Redmine rocks
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 5.
> crade pendant un bon moment, il y a pas mal de passages qui était carrément l'inverse
> de bonne pratiques recommendées habituellement. Cela a changé au fil du temps,
> doucement mais sûrement.
C'est marrant car ici les gens sont très pro ruby et python et très peu perl et on voit à ce commentaire que ces langages ont les mêmes défauts (avantages) que perl, ils évoluent et le vieux code est parfois crade ;-)
Vive le Perl Moderne !
[^] # Re: Pas vu
Posté par Sytoka Modon (site web personnel) . En réponse au journal Dépouillement de Firefox. Évalué à 2.
http://fr.wikipedia.org/wiki/Panneau_STOP_en_France
[^] # Re: Pas vu
Posté par Sytoka Modon (site web personnel) . En réponse au journal Dépouillement de Firefox. Évalué à 3.
On pourrait donc envisager un système meilleure, surtout qu'avec les LED, c'est plus facile. Par exemple vert=rond, orange=triangle, rouge=carré. De plus, on en profiterais pour faire le réglage qu'on trouve dans plein de pays et qui est bien mieux qu'en métropole :
vert -> orange -> rouge -> rouge+orange -> vert...
[^] # Re: firefox 4.08 est très bien
Posté par Sytoka Modon (site web personnel) . En réponse au journal Dépouillement de Firefox. Évalué à 3.
Le problème est que depuis quelques années les écrans diminuent... Depuis les années 90, les écrans augmentaient mais ce n'est plus le cas.
On a en ce moment des 22 ou des 24" qui n'ont même pas la définition verticale des écrans 4/3 d'il y a quelques années. Le format 16/9 très adapté à la vidéo n'est pas forcément le top pour le boulot ni le web je trouve. La lecture n'est as adapté à une trop grande largeur et le multi-colonne sur un système à ascenseur vertical ne fonctionne pas correctement. De plus, je trouve que c'est pas assez large pour avoir deux pages A4 cote à cote (par exemple le source TeX à gauche et le pdf à droite), sauf alors les très grand écrans.
Le 16/9 est parfait pour les portables puisque les claviers sont larges plus que profond ;-)
J'étais convaincu que les interfaces graphiques s'adapteraient à ce nouveau format 16/9. Je ne suis pas encore enchanté du résultat pour le moment. Il faudrait trouver comment utiliser judicieusement une bande verticale mais comme les européens écrivent de gauche à droite, c'est pas facile !
[^] # Re: Mme Michu, vraiment ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Dépouillement de Firefox. Évalué à 2.
Et encore, lorsque tu balances dedans un bout de message d'erreur ayant plein d'espace mais aussi un "deux points" :, ce couillon cherche une URL et ne fait pas une recherche par défaut comme c'est le cas s'il n'y a pas de : qui traine...
[^] # Re: Mme Michu, vraiment ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Dépouillement de Firefox. Évalué à 2.
Sachant que il y a une différence entre une URL interne et une URL externe a un site. Une URL interne n'a pas réellement besoin d'être vu facilement, c'est un calback interne à l'application qu'on utilise. Un lien externe, c'est tout autre chose.
[^] # Re: Mme Michu, vraiment ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Dépouillement de Firefox. Évalué à 3.
> seule qui me parait vraiment "intelligente" de tous les navigateurs du marché et qui colle
> parfaitement a ce que j'attends d'elle.
Et encore, lorsque tu balances dedans un bout de message d'erreur ayant plein d'espace mais aussi un espace, ce couillon cherche une URL et ne fait pas une recherche par défaut comme c'est le cas s'il n'y a pas de : qui traine...
Bref, en améliorant encore un peu la barre d'adresse, c'est la barre de recherche qui ne sers plus à rien.
Sinon, je suis d'accord qu'il faut un moyen simple de voir les URL complète. On ne peux pas se battre et essayer d'apprendre aux gens à ne pas suivre n'importe quelle URL et ne plus pouvoir les voir simplement.