Sytoka Modon a écrit 4544 commentaires

Merci pour la leçon de morale, je sais très bien ce qu'est le nazisme.

Désolé, j'avais pas l'impression ;-)

ou pas, la meilleure façon d'exorciser un traumatisme c'est d'en rire et d'aller de l'avant et pas de le refouler.

Je sais en rire et je ne refoule pas. Ta phrase n'est pas vraiment drôle et au final, cela rend l'utilisation de ce mot banal pour tout un tas de blague nulle... On a le droit d'en rire, certes, mais pour pour moi, autant éviter la banalité et l'usage complètement HS ;-)

Incroyable les conneries qu'on peux lire ici !

Réponse tardive... j'étais à 200% dans autre chose ces derniers temps.

Ce que tu proposes est exactement ce que je fais. Je suis sous WMII avec urxvt...

Comme éditeur, en plus de vi, j'utilise nedit car léger, souple et très rapide mais il ne supporte pas l'UTF8. Dommage car il gère les sélections carrées comme j'ai pas vu d'autres programmes le faire.

J'ai essayé d'autres éditeurs graphiques, par exemple gedit ou geany, ils sont absolument insupportable ! Même sous gnome, "geany nom_fichier" t'ouvre la fenêtre sous le bureau ou geany est déjà ouvert... nedit était vraiment rapide, on pouvait en ouvrir 30 sans problème et il a même un mode serveur si on en as besoin mais qui n'est pas le mode par défaut. C'est bien plus intelligent comme fonctionnement (un peu comme vi d'ailleurs)

Que viens faire ce mot "nazi" ici à par pour en détourné le sens pour faire de l'humour assez nul à vrai dire.

Petit rappel du nazisme ici : http://fr.wikipedia.org/wiki/Nazisme

Moque toi de debian, c'est de bonne guerre mais évite de participer à l'usage de ce mot pour des choses qui n'ont rien à voir avec le nazisme.

Je sais, de l'autre coté de l'atlantique, ils y en a qui se permettent... Ils sont de l'autre coté et pas en Europe et ont parfois perdus le sens de l'histoire.

Super, je vais mettre cela en place au boulot dès demain.

merci

Attention, pour un bi-coeur, les limites sont à 200% et non à 100%. Si tu as 6 coeurs, sous 600%, tu es en sous-charge...

Bref, pour nagios, c'est un peu chiant car les limites dépendent du nombre de coeur.

Il aurait été préférable de diviser à la source le loadaverage par le nombre de coeur pour dire que 100% = 100% d'utilisation de la machine mais ce n'est pas ce qui a été choisi.

Tu peux monter run sous /boot en tmpfs...

Par contre, comme il est dis ci-dessous, on peux avoir un système sans /boot et c'est effectivement le cas de mes machines virtuelles sous Xen, il n'y a pas de /boot car pas de noyau dessus !

Puisque cela concerne principalement le démarrage, on aurait pu faire un

/boot/run

Sachant que /boot est très rapidement monté...

Ensuite, /var/run et /boot/run aurait été identique.

Bref, juste une idée qui me passe par la tête pour éviter la prolifération dans /.

En recherche, au niveau des projets Européen, on a tendance à faire des fondations/associations Belge car j'ai cru que c'était avantageux par exemple par rapport à la même chose fait en France.

C'est un peu idiot car on est en Europe mais bon...

Bref, pourquoi une fondation britannique ?

Sous UNIX, la tradition est de mettre son grain de sel partout. Donc on n'utilise pas MD5 en pratique mais SMD5 qui est bien plus difficile d'attaquer par force brute !

Ceci dis, cette technique est connu depuis ... plus de 30 ans mais les ingénieurs Microsoft ne l'ont toujours pas comprise ;-)

OK, je -> []

Les applications doivent maintenant gérer les multi-fenêtre, un mode serveur... Tout cela parce que la plupart des gestionnaires de fenêtre ne savent pas gérer les onglets correctement. Au final, peu de gestionnaire de fenêtre ont repris les idées de PWM.

Je ne vois pas ou est le problème d'avoir n instance de la même application et qu'éventuellement, le gestionnaire de fenêtre les raccrochent toutes ensemble s'il le faut via les propriétés XWindow.

Bref, plutôt que de séparer les processus et rester dans la philosophie simple d'UNIX, on programme des usines à gaz qui intègre en interne une gestion de fenêtre (onglet) avec un beau mélange de paramètre de configuration et de variables d'état...

Je pense honnêtement qu'il faudrait redonner à UNIX et aux éléments de base leur fonction première et arrêter de suivre bêtement certain OS.

Il n'y a jamais d'écriture multiple... même avec une base de données !

Après, c'est une gestion de la file d'attente. Tu poses un verrous, écris et enlèves le verrous. Vu le temps pour écrire dans Firefox et vu le temps de réaction humain du click click, Firefox a largement d'écrire 100 fois le fichier entre deux actions humaines... On n'est pas ici sur une problématique de serveur de contenu avec des centaines d'accès concurrent.

Je dirais même plus, ce concept d'application globale a pour base le concept de variable globale très mauvais pour beaucoup de chose et bon pour très peu de chose...

Personnellement, j'en ai marre de ces applications qui refusent le multi-instance et les notions simples d'UNIX. Les bibliothèque et le format ELF sont là pour gérer la mémoire intelligemment.

Il y a pleins d'applications ou on ne change pas la configuration tous les quatre matins et ou avoir pas mal d'instance n'est pas génant. Je pense même qu'un navigateur comme Firefox devrait être par défaut multi-instance, il y aurait je pense bien moins de soucis s'il l'était vraiment (je ne parle pas du multi-profile qui est un truc qui ne sers à rien et qu'on devrait choisir via un drapeau -f au lancement par exemple).

100% d'accord avec toi.

Lorsqu'on est passé des stations IRIX au poste Debian, on a trouvé cela génial, les deux étant très proches dans la hiérarchie des fichiers et la clarté de leur position. Entre temps, on avait taté de Red-Hat (vers 96) et c'est bien plus fouillis.

D'ailleurs, il suffit de faire un "grep -r adresse_ip /etc" pour voir que les deux ont une approche assez différente.

On ne parlait pas de remonté upstream mais de développement upstream.

Sinon, les patch pour le multi-plateforme prenant du temps, il s'applique a une versin plus ancienne que l'upstream ne veut pas toujours prendre en compte...

Enfin, à noter que le nouveau format 'quilt' des paquetages a pour objectif de simplifier la gestion des patch et d'en faire une remontée plus aisée. Voir le boulot fait par Raphaël Hertzog sur dpkg sur le sujet.

En effet, le boulot de monter et de descente des patch entre l'upstream et les distributions n'est pas chose aussi facile qu'on peut le croire, surtout s'il y a des centaines de milliers d'entrée dans le système de suivis de bogue comme chez debian.

Ca avance dans la bonne direction ;-)

Si les développeurs amont compilaient toutes les nuits leurs logiciels sur plusieurs plate-formes, le travail de packageur Debian iraient plus vite ;-)

Debian participe énormément sur l'aspect multi-plateforme. Un partie des patch vient aussi de là, les logiciels ne compilant parfois même pas.

Debian participe énormément au libre avec ses règles de bonnes conduites. Avoir un noyau enfin libre était une épine qui traînait depuis longtemps...

Débian n'a pas de prétention commerciale directe.

Bref, il ne faut pas faire un parallèle trop rapide avec Ubuntu. Les deux distributions n'ont pas les mêmes objectifs ni les mêmes manières de faire.

Il y a plusieurs sessions en parallèle, pas besoin de sortir un mot que personne ne comprends ;-)

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