Sytoka Modon a écrit 4551 commentaires

Tu as une utilisation avancée du proxy et les programmes surchargent le paramétrage global. As-tu vraiment besoin de changer le proxy globalement pour toutes les applications à tout instant, car si elles ont toutes les mêmes proxy à un instant t, c'est bien un paramètre système.

Pour qui est du fond d'écran, je sais que sous gnome c'est nautilus qui fait cela ce qui a mon sens est idiot car n'a rien à voir avec un gestionnaire de fichier et fait dépendre un truc visuel global d'un gestionnaire de fichier particulier. Enfin, cela fait longtemps que j'ai quitté GNOME car je ne suis pas fanat de la direction qu'ils prennent.

Le soucis est que GNOME est conçu en suivant la trace des autres, Windows et MacOSX. Donc si tu veux copier les autres, tu risques de te retrouver dans les mêmes travers.

Rien n'empêche plusieurs programmes de lancer xsetroot ou un équivalent pour changer de fond d'écran, il n'y aucun besoin d'un gestionnaire d'évènement de type variable globale pour cette problématique. Le dernier programme qui paramètre gagne, point final.

Je pense personnellement qu'il y a d'autres voies possibles. Je ne dis pas qu'il ne faut absolument pas de bus de type d-bus couplé à gconf, je pense qu'il ne sers à rien d'en abuser et qu'au final, cela n'apporte pas grand chose si ce n'est de la complexité et beaucoup de dangerosité.

Le modèle de base d'UNIX des processus père fils et des variables d'environnements transmissibles permet de faire beaucoup. Dans les cas pointus, il est possible d'aller au delà de ce modèle simple. Ce n'est pas la peine non plus d'oublier ce modèle simple pour tout mettre en global !

Pour ce qui est du réveil, c'est comme pour un 'ReStart' d'environnement de bureau, tu peux très bien envoyer un signal CONT via kill ou équivalent aux applications pour prendre en compte un réveil.

On avait des choses simples qui marchait bien comme 'newgrp' qui ne sont quasiment plus utilisable dans ce paradigme global, idem avec un gestion de l'umask... On n'a plus cette notion de container et d'héritage de l'OS. Les applications ré-implémentent la gestion des onglets, du threading, du sandboxing... quand à avoir un comportement différent en fonction de la vie de l'application et de l'histoire de ses parents, ce n'est plus guère possible. Personnellement, j'aurais préféré que toute cette énergie soit mise dès le début dans le coeur de l'OS.

> Bref, c'est une notion récente

Tu plaisantes j'espère. Il y a 20 ans, LaTeX gérais déjà tout seul et comme un grand l'espace insécable devant les ponctuations double du Français...

Tu veux peut-être dire que le web rattrape petit à petit son retard.

C'est sur qu'au cours d'une session, le paramètre du proxy change tout le temps... Et puis, si le proxy dépend du type de la connexion, c'est bien un truc à régler en central ou à récupérer via dhcp qui peux très bien être gérer par une variable d'environnement (et en plus, cela marche très bien).

Quand au fond d'écran, il suffit de lancer un programme pour le changer. A une époque, on utilisais xsetroot. Bref, pas besoin de base de registre pour faire cela. Surtout, c'est bien un paramètre dont les applications tierce n'ont que faire.

Bref, tu donnes deux mauvais exemples

La pensée unique n'a jamais été une bonne solution. De plus une solution bonne à l'instant t s'avère souvent pas si bonne à t+1.

Il est très facile avec cfengine par exemple d'écrire quelques règles qui s'adaptent au différent cas.

Sinon, il y a un module Perl très amusant Config::Model qui a des petits dans sa suite.

http://sourceforge.net/apps/mediawiki/config-model/

Enfin, lorsque j'entends parler de configuration au format binaire, je fuis... En plus, il y a un service associé, l'objectif est vraiment de faire pire que Microsoft ?

La base de registre est une terrible daube ou on mélange paramètre de configuration et variable de programme.

Les paramètres de configuration n'ont absolument pas besoin de service (daemon) puisque chargés une seule fois au lancement de l'application et modifiés très rarement. Les anciens bureaux avait un bouton 'Restart' pour les relancer si on changeait la configuration, c'est moins sexy mais à mon sens tout aussi fonctionnel et bien moins dangereux que d'avoir des paramètres variables qui se propagent instantanément à toutes les applications.

Mais ou sont les principes d'UNIX de faire simple, par couche avec des applications pères fils bien séparées !

C'est un des problèmes des langages trop objet je trouve, cela finit par être trop rigide. Je me souviens de la difficultée qu'avait les personnes d'Effeil à faire évoluer leur arbre des classes, trop d'interaction. Je préférait l'approche de Sather bien plus simple au final et tout aussi puissante.

Il faut bien laisser un chance à Adobe de nous pourrir tout nos PC avec ses nouvelles versions de son virus Acrobat. Si le web devient trop beau et ne bouge pas assez, on n'aura plus de daube à nous mettre sous la dent ;-)

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...).

En plus, pas la peine d'avoir un outil qui fais du ncurses pour faire cela !

apt-get fait une chose et le fait bien.

Syntaxe que j'utilise presque tous les jours :

- SPIP
- Trac
- Ikiwiki (markdown pour moi)
- Mediawiki

Pour les utilisateurs, c'est pas idéal.

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.

Tout le monde sais que les voitures étrangères sont conçus avec les pieds.

mv H.264 placard/

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.

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.

Voir plus bas pourquoi avoir mis une bibliothèque dans des tours en verre est complètement idiot.

S'il n'y a pas de brevet, pourquoi payer une licence si on utilise une implémentation libre ?

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é.

En Europe, il n'y a pas /a priori/ de licence pour le H264. Donc, si cela peux faire réfléchir certain pour l'hébergement, tant mieux.

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...